Nmap Development mailing list archives
RE: Nmap Attack Scripting Language (NASL)
From: "Arun Vishwanathan" <arun.vishwanathan () nevisnetworks com>
Date: Tue, 23 May 2006 12:20:07 +0530
Hello Brandon, See my comments inline .... Regards, Arun -----Original Message----- From: Brandon Enright [mailto:bmenrigh () ucsd edu] Sent: Tuesday, May 23, 2006 12:05 PM To: Arun Vishwanathan Cc: bmenrigh () ucsd edu; nmap-dev () insecure org Subject: RE: Nmap Attack Scripting Language (NASL) I'm a fan of TCL/Expect and write a lot of very useful code in it. I don't think it is up to the Nmap/NASL job though. I recently went about writing a vulnerability checker for the "RealVNC Authentication Bypass" security hole in Expect and found it's handling of binary data very primitive. TCL can't handle/match NULL characters in strings at all. I re-wrote it in Perl and handled the NULLs just fine.
Arun <<< What I am proposing is writing TCL commands in C. This
would take care of handling all the above types of cases easily. The NASL language of choice has to be able to handle arbitrary binary data including NULLs without any extra work. It's totally feasible to need to send binary data and expect binary data back -- TCL/Expect really breaks down in this area.
Arun <<< Same comment as above. In addition, we would use only the
programming constructs of TCL and do all the core work within the NMAP Apis written in C and exported using TCL commands. The Nmap script framework should (and probably will) have some sort of send/expect API similar to TCL/Expect. There may also be a need to do asynchronous I/O and other non-blocking I/O tasks. Nmap already has PCRE and doesn't need the bloat of another RE engine.
Arun <<<< The RE engine in TCL will be used for doing non-nmap
related jobs. This I think is mandatory for a programming language. You also are suggesting Perl below which also has a regex engine. So this point is really not valid I guess. I've looked into LUA and have been pleasantly surprised. It compiles in 5 seconds and is meant to be integrated into another project rather than be standalone. It also sounds like LUA threads really well and is extremely portable. LUA should be the fastest to implement and cause the fewest integration headaches.
Arun <<< I think using a newer language will delay the adoption by
the wider community. I would prefer Python/TCL in this case esp. because they are proven. I have nothing against LUA but just that it may take some time to mature. We can port stuff to it later. I like TCL just fine but would rather see LUA or Perl or Ruby over TCL. Brandon -- Brandon Enright Network Security Analyst UCSD ACS/Network Operations bmenrigh () ucsd edu On Tue, 2006-05-23 at 11:36 +0530, Arun Vishwanathan wrote:
Fyodor, Why can't we use TCL as the scripting language? I say TCL because of the following reasons - TCL is easily extensible by writing custom commands in C and
exporting
them as TCL functions. - TCL provides a very decent syntax and provides all common
programming
constructs in addition to in-built commands for string handling/regex etc. - TCL is used by most networking companies and hence would be easy for companies to integrate NMAP commands into their existing frameworks
thus
making nmap an integral part of their test infrastructure (like we do
at
Nevis Networks :)). - TCL integrates easily with expect and which can be used to automate remote scanning. You could potentially launch nmaps from multiple
hosts
all controlled from a single controller script written using send/expect. This may make sense for scanning larger networks where an admin can logically divide his network and scan parallely. My 2 cents. Hope the above makes sense. Regards, Arun -----Original Message----- From: nmap-dev-bounces () insecure org [mailto:nmap-dev-bounces () insecure org] On Behalf Of Fyodor Sent: Tuesday, May 23, 2006 6:50 AM To: nmap-dev () insecure org Subject: Nmap Attack Scripting Language (NASL) One of the Google SoC projects that I'm most excited about is adding a scripting engine to Nmap. Don't worry Renaud, we won't really call it NASL :). And this doesn't mean Nmap is becoming a vulnerability scanner. Scripts can be used for all sorts of things. For example, KX's recent suggestion of looking up AS numbers and whois data. Or you could write a custom script to query your own proprietary applications on your network. Or vulnerability detection. Or maybe check for open proxies. There are tons of options. So I just wrote up a requirements doc for the project: http://www.insecure.org/nmap/SoC/Scripting.html Boy, SoC is a great program but it sure keeps me writing a lot of long text files :). The good news is that the final student selection should be announced within the next couple days and then we'll move toward writing code. But doing the initial design properly is obviously critical. So do reply if you have suggestions. For what it is worth, we're currently looking at LUA as the embedded scripting language of choice. Anyone have experience in this area? Cheers, -F
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- Nmap Attack Scripting Language (NASL) Fyodor (May 22)
- Re: Nmap Attack Scripting Language (NASL) doug (May 23)
- <Possible follow-ups>
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Brandon Enright (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- Re: Nmap Attack Scripting Language (NASL) David Warde-Farley (May 22)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- Re: Nmap Attack Scripting Language (NASL) Fyodor (May 23)
- Re: Nmap Attack Scripting Language (NASL) Paul Rigor (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 22)
- RE: Nmap Attack Scripting Language (NASL) Arun Vishwanathan (May 23)
- Re: Nmap Attack Scripting Language (NASL) Diman Todorov (May 23)