Mailing List Archive

H D Moore <hdm@digitaloffense.net> writes:

> Rewriting (or even hooking into) those functions is a significant amount
> of work.

It is still possible. But adding new *operators* to TCL is impossible
(unless you want to deliver a non standard language, of course).

BTW, I've fixed the grammar so that ++ can be used in loops, and have
implemented array affectations.

I was thinking of adding a "make_list" function. e.g. :

url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
dir = make_list("/cgi-bin", "/scripts", "/cgi");
for (i=0; dir[i]; i ++)
for (j=0; url[j]; j++)
{
u = dir[i]+url[j];
# Test if installed...
}


Making a function is simpler that adding a new () operator to the
language. Like url = ("bad1.cgi", "bad2.cdi", "bad3.cgi");

On Fri, Jan 10, 2003 at 11:44:01AM +0100, Michel Arboi wrote:
> H D Moore <hdm@digitaloffense.net> writes:
>
> > Rewriting (or even hooking into) those functions is a significant amount
> > of work.
>
> It is still possible. But adding new *operators* to TCL is impossible
> (unless you want to deliver a non standard language, of course).
>
> BTW, I've fixed the grammar so that ++ can be used in loops, and have
> implemented array affectations.
>
> I was thinking of adding a "make_list" function. e.g. :
>
> url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");

I'd prefer it to be called array(), so that the following are valid :

dir = array("/cgi-bin", "/scripts", "/cgi");
url = array("/foo.html");
if(is_cgi_installed("/foobar.html"))
url[max_index(url)] = "/foobar.html";
^^^^^^^^^^^^^

Would be good too




-- Renaud

Hi,

Don't want to make a big issue of this, but do just want to repond to
your points. I'm not trying to disrespect NASL or anything, just
throwing some ideas around.

>function library in a another language is possible, but it would take
>quite a bit of time to write and could potentially create a whole new set
>of dependencies for the code to compile. NASL doesn't need to be a fully
>
I'd do it is make the library dependent on libnasl/nessus, not rewrite
all that functionality from scratch. The dependencies would be mostly
the same.

>(damn, the SSL module doesnt compile on this platform), and the poor guy
>trying to understand what the plugins do (theres more than one way to do
>
I think NASL is harder to read than perl/python, because people jump
through hoops to do simple string operations. Besides should we be
forcing people to learn a new language to write plugins?

>it... you can be people will use their own). While both Perl and Python
>have sandboxed modes, vulnerabilities have been found in them and will
>
As NASL sometimes crashes you can be sure the vulnerabilities are there
also. The perl/python ones have been (mostly) discovered because of
their widespread use and now fixed. I don't see why your trust the NASL
sandbox so much.

>probably continue to be found in them. Are you going to force every
>Nessus user to have a billion little python/perl module instaled just to
>get SSL or XML support?
>
No, just libnasl.py, libnessus.py

>plugins. It has a great API of functions explicitly written to test for
>security vulnerabilties.
>
>also supports some really cool things like transparent protocol
>negotiation for SSL wrapped ports, an integrated (if one-way) knowledge
>base, and built-in support for both pcap and raw packet generation.
>
>
Absolutely. Great API which we can take with us to another language. Not
so great language that we can leave behind.

>If there was a single software package whose name I have cursed above all
>others in the last 3 years, it has got to be NASL. It wasn't until I went
>
:-)

>mode, the fact that your plugins aren't compatible with the standard
>Nessus (without --enable-python-plugins and a whole bunch of support
>libaries) will probably keep 99% of the people from using them. Since
>
If it got to that point I think I would fork the whole of Nessus and
start a rival project!!!!!!

Paul

--
Paul Johnston
Security Specialist
Westpoint Limited
Albion Wharf, 19 Albion Street,
Manchester, M1 5LN
England
Tel: +44 (0)161 237 1028
Fax: +44 (0)161 237 1031
email: paul@westpoint.ltd.uk
web: www.westpoint.ltd.uk

Paul Johnston <paul@westpoint.ltd.uk> writes:

> I think NASL is harder to read than perl/python, because

Because you are used to Perl/Python.

> Besides should we be forcing people to learn a new language to write
> plugins?

Why not? Learning NASL is very easy.

> As NASL sometimes crashes

When?

> you can be sure the vulnerabilities are there also.

Hardly. NASL have been designed from scratch without any option to run
external commands or connect to any machine.
There is no "sandbox" in fact. Or there is nothing but a big sandbox.

> If it got to that point I think I would fork the whole of Nessus and
> start a rival project!!!!!!

Well, if you really want it, I will not stop you, but it will be a
waste of time & energy IMHO.

There are more interesting things to do in this domain: local scanner,
database scanner, PEN-TEST toolkit / automation,etc.

If you really want to write plugins in Perl, Python or whatever, all
you have to do is write a Perl to NASL compiler.

Quoting Michel Arboi <arboi@noos.fr>:

> H D Moore <hdm@digitaloffense.net> writes:
> BTW, I've fixed the grammar so that ++ can be used in loops, and have
> implemented array affectations.
>
> I was thinking of adding a "make_list" function. e.g. :
>
> url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
> dir = make_list("/cgi-bin", "/scripts", "/cgi");

Were you thinking that if you call it twice it adds to the array or starts over?
url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
url = make_list("bad4.cgi");

does url now equal bad4.cgi only or all four values? or perhaps add_list?

--
http://www.cirt.net/

On Fri, 2003-01-10 at 14:00, sullo@cirt.net wrote:
> Were you thinking that if you call it twice it adds to the array or starts over?

Start over.

> url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
> url = make_list("bad4.cgi");

url = make_list(url, "bad4.cgi");
or maybe:
url += "bad4.cgi";
Or another (new) operator... ".=" maybe?

On Fri, Jan 10, 2003 at 12:43:16PM +0000, Paul Johnston wrote:


[...]
> >function library in a another language is possible, but it would take
> >quite a bit of time to write and could potentially create a whole new set
> >of dependencies for the code to compile. NASL doesn't need to be a fully
> >
> I'd do it is make the library dependent on libnasl/nessus, not rewrite
> all that functionality from scratch. The dependencies would be mostly
> the same.

So you'd need everything Nessus requires PLUS the interpretor the fancy
language you want to use. Knowing how fun the compilation of perl is,
I'm sure you'd make a lot of persons _very_ happy.

What ? You think perl is installed on every OS ? Well, this is starting
to be true (except for Windows, then you'd kill "easy" portability), but
which version of perl ? 4.x ? 5.00503 ? 5.8 ? the upcoming/mythical 6.x ?
How do you force your users to have the version of perl/python you want
them to use, while they may need to have a another one for another
sotfware package ?

Or do you want to add the source of the interpretor of your choice with
Nessus ? Then you have to maintain a big, furry, hairy source tree you
don't really have control on. Now _that_ is elegant.


> >(damn, the SSL module doesnt compile on this platform), and the poor guy >
> >trying to understand what the plugins do (theres more than one way to do
> >
> I think NASL is harder to read than perl/python, because people jump
> through hoops to do simple string operations.

Then you're just missing some string manipulation functions. We can add
that to NASL2 with no problem. I hate PCREs, but if there's user support
for it, then we can easily add it in NASL2 while we're in the /unstable/
stable.

> Besides should we be
> forcing people to learn a new language to write plugins?

Most plugins are just a couple of lines long, so
all the complexity of the language does not need to be grasped to start
writing something. The problem is that you seem to consider that the
code of a plugin will take more than +12k lines of code.

I mean, you don't need to have graduated from computer skool to do :

soc = open_sock_tcp(1234);
buffer = recv_line(socket:soc, length:255);
if("Foobar" >< buffer)security_hole(port);



It's not like the language is rocket science. If you can't
really do a simple transposition from <insert your language here> to
nasl which is less complex by nature, then you should seriously start
wondering if you're working in the right field.

> >it... you can be people will use their own). While both Perl and Python
> >have sandboxed modes, vulnerabilities have been found in them and will
> >
> As NASL sometimes crashes you can be sure the vulnerabilities are there
> also.

Probably, but again, maybe not. NASL crashes sometimes because of the
way the script is written. A remote server can not really crash the
interpretor as it can not change the running script, or you'll have to
show me a demonstration.

While porting all the NASL1 functions to NASL2, I noticed _one_ condition o
where the script could deliberately crash the nasl interpretor, by requesting
an out of bound index in a non-writeable array (hint: scanner_get_port(99999)).

>The perl/python ones have been (mostly) discovered because of
> their widespread use and now fixed. I don't see why your trust the NASL
> sandbox so much.

The sandbox is not much in the interpretor itself rather than in its
functions which are purposely limited : you can't open a local file, you
can't send packets to a third party host, and so on... Very limited,
very little risks of having a script destroying your local hard drive or
publishing your $HOME on a newsgroup. A script can't even send the
result of the scan of the other hosts to the host being tested.

> >probably continue to be found in them. Are you going to force every
> >Nessus user to have a billion little python/perl module instaled just to
> >get SSL or XML support?
> >
> No, just libnasl.py, libnessus.py

Brilliant ! So in the end, you have the same functionnalities as NASL,
but with a different syntax. What do you really gain here, if you
prevent the use of third-party modules and functions ?

"I have the operators I like in my language, for easy string
manipulation" I hear you say. Well, guess what - there's a thread called
"NASL2 wish list" (not "Should we use NASL ?") which has been created
to requests specific things that you think are missing in nasl1. It
would be more constructive to send a detailed list rather than whining
about the lack of use of python, perl, ruby, whatever.


[...]
> Absolutely. Great API which we can take with us to another language. Not
> so great language that we can leave behind.


"great language" is a matter of taste. I personally hate perl and
python, and at the opposite of what you imply, I consider perl code to
be unreadable. Note that I'm not a big pusher of NASL itself - I'm just
trying to be reasonable, that's all, and take everything into account.

I know the language has its shorcomings and all, but it did the job so far with
NASL1, albeit slowly and a little tricky on the parsing, but it did well
and proved to be a good solution over the last three years, at least for
me who wrote over 700 over the nearly 1200 security checks.

Also, sometimes the API is closely tied to the language. At first, the
function send() was just a call to the libc function of the same name.
Had we used perl for Nessus, then we'd probably have used perl's send()
to do this job. But it turned out that when Michel added SSL support, we
could change the inners of the function without changing any of the nasl
script (transparent SSL negociation).

If you say that all the functions called from a NASL script ought to be
part of libnasl.{py,pl}, then you're cheating. How do you draw the line
then ? Should we use nasl_split() or perl's split() ? If we use
nasl_split(), then why do we use perl at all ? If we use perl's split(),
how do you know it won't change at all from one perl version to
another ?


> >If there was a single software package whose name I have cursed above all
> >others in the last 3 years, it has got to be NASL. It wasn't until I went
> >
> :-)

You tend to curse the tools you use. Had I chosen any other language
instead of nasl, I'm sure people would have cursed it and/or the API,
and/or me, or whatever else.


I'd also like to point out that the source code of nessusd, that I'm
sure you've studied to a great extent, allows you to use multiple
languages - we support .nes (C) and .nasl (NASL) plugins, but it's very
very easy to add support for a new language - see what H D Moore started
to do with perl. I'd have been happy to see your contributions in that
regard, but grepping through all my mailboxes show no contribution on
this matter from you. So I'm not sure you've chosen the most
constructive way to complain.

> >mode, the fact that your plugins aren't compatible with the standard
> >Nessus (without --enable-python-plugins and a whole bunch of support
> >libaries) will probably keep 99% of the people from using them. Since
> >
> If it got to that point I think I would fork the whole of Nessus and
> start a rival project!!!!!!

Do so. Then you'll have to start considering things such as portability,
memory size (very important, at the opposite of what a lot of people
think) user support, contradiction between users requests, maintainability,
version conflicts, independance of your program (you don't want
Nessus to stop working when your avg. FreeBSD user types "use.perl
port", do you ?) and at the same time, write and test new security checks.
And find the time to have a job so you can pay the bills.

Maybe then you'll start to understand why using a 100% proprietary language is
a neat solution, why it solves most of the problems you encounter with your
users, and why this fuckhead of Renaud was not completely wrong.


-- Renaud

Quoting Michel Arboi <arboi@noos.fr>:

> On Fri, 2003-01-10 at 14:00, sullo@cirt.net wrote:
> > Were you thinking that if you call it twice it adds to the array or starts
> over?
>
> Start over.
>
> > url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
> > url = make_list("bad4.cgi");
>
> url = make_list(url, "bad4.cgi");
> or maybe:
> url += "bad4.cgi";
> Or another (new) operator... ".=" maybe?

How would not be as important, I would think, as much as the ability to do so.
it could make life easier to do dynamic arrays based on other NASL code, etc, as
well as save the time to recreate an array if you just need to add something to it.

the first additional call to make_list(url, "bad4.cgi") would then be very much
like perl's push()...



--
http://www.cirt.net/

> > I also recognize that a very small number of people have been
> > contributing, relatively speaking. A standard language could welcome a
> > lot more people to the project.
>
> I don't believe the language is the issue that prevents people
> from contributing.
>
> Thomas
>

It certainly doesn't help. I have about 5 nasls I would have finished if I
could use one of the following languages:

TCL PERL PHP C/C++ VBA

I would be finished writing them now. As it stands, I them on the back
burner until I have time to read through enough other NASLs to figure out
how to use the dammed language to do what I need it to do properly without
yeilding false positives.


P.S Just kidding about VBA

> -----Original Message-----
> From: owner-nessus-devel@list.nessus.org
> [mailto:owner-nessus-devel@list.nessus.org]On Behalf Of sullo@cirt.net
> Sent: Friday, January 10, 2003 8:18 AM
> To: Michel Arboi
> Cc: Nessus Devel
> Subject: Re: Replacing NASL (was Re: NASL2 wish list)
>
>
> Quoting Michel Arboi <arboi@noos.fr>:
>
> > On Fri, 2003-01-10 at 14:00, sullo@cirt.net wrote:
> > > Were you thinking that if you call it twice it adds to the
> array or starts
> > over?
> >
> > Start over.
> >
> > > url = make_list("bad1.cgi", "bad2.cdi", "bad3.cgi");
> > > url = make_list("bad4.cgi");
> >
> > url = make_list(url, "bad4.cgi");
> > or maybe:
> > url += "bad4.cgi";
> > Or another (new) operator... ".=" maybe?
>
> How would not be as important, I would think, as much as the
> ability to do so.
> it could make life easier to do dynamic arrays based on other
> NASL code, etc, as
> well as save the time to recreate an array if you just need to
> add something to it.
>
> the first additional call to make_list(url, "bad4.cgi") would
> then be very much
> like perl's push()...

Could do something like this:

array_new($urls, "bad1.cgi", "bad2.cgi");

array_push($urls, "bad3.cgi");

so that you could be sure that you started with a clean array. Or just
something like this if you are not so concerned:

array_push($urls, "bad1.cgi");
array_push($urls, "bad2.cgi");
array_push($urls, "bad3.cgi");

>Using a custom language for the majority of the plugins means that there
>is actually some sort of a standard for the way tests are done. CGI
>checks are cookie-cooker and very small, due to most of the
>intelligence/integration happening behind the libraries. Duplicating the
>function library in a another language is possible, but it would take
>quite a bit of time to write and could potentially create a whole new set
>of dependencies for the code to compile. NASL doesn't need to be a fully
>functional scripting language to simply test for various vulnerabilities.

That intelligence and integration are what Nessus is. If we were to rebuild
and drop in Python then we'd have to duplicate that effort. No question
it would take a lot of time and effort but it's a better place to be.
Simply adding hooks to write scripts in Python or Perl wouldn't offer much.
Replacing NASL with Python or Perl would be awesome though.

>Trying to replace it with another language would make things much more
>complicated for the code maintainer (Renaud et all), the plugin writer
>(damn, the SSL module doesnt compile on this platform), and the poor guy
>trying to understand what the plugins do (theres more than one way to do
>it... you can be people will use their own). While both Perl and Python
>have sandboxed modes, vulnerabilities have been found in them and will
>probably continue to be found in them. Are you going to force every
>Nessus user to have a billion little python/perl module instaled just to
>get SSL or XML support?

This is a bad argument. Perl and Python are successful, they are used.
That problem is being solved. I won't deny that I've pulled my hair out
installing 50 CPAN modules to make some stupid script work but over time the
situation has improved dramatically and as I said above those 50 modules is
essentially part of Nessus at that point. This stuff is all open licensed,
we draw a line in the sand, pick out the base line and then work with it.
If our choice CGI module is dropped from Python then we supply it with
Nessus until we can find a better solution. Plus what's the reality of it
right now? We need pcap access, we need some good HTTP support and raw
sockets. Much else than that for basic functionality? We're not talking
about using every far flung perl or python module out there.

I also wouldn't advocate generic "plug-in language" support like GIMP has
done. That's when the dependency issue kills you.

>Bleh, this is just me ranting at 4 in the morning, maybe most of the
>plugin developers would be ecstatic at using Python and will gladly
>donate the time it takes to rewrite and *test* 1000+ plugins ;)

I, for one, would be on board in a second. I think Python in particular
offers some interesting possibilities. I've looked at a lot of Nessus
scripts that are very similar and it begs for a nice object oriented model
with lot's of code reuse. Maybe my coffee hasn't taken hold yet but after
some hard up front work I think it would be a lot easer to add stuff to
Nessus if it were based on Python and I know a lot of scripts would be
trivial modifications to others.

Will

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
http://join.msn.com/?page=features/junkmail

>[...]
> > >function library in a another language is possible, but it would take
> > >quite a bit of time to write and could potentially create a whole new
>set
> > >of dependencies for the code to compile. NASL doesn't need to be a
>fully
> > >
> > I'd do it is make the library dependent on libnasl/nessus, not rewrite
> > all that functionality from scratch. The dependencies would be mostly
> > the same.
>
>So you'd need everything Nessus requires PLUS the interpretor the fancy
>language you want to use. Knowing how fun the compilation of perl is,
>I'm sure you'd make a lot of persons _very_ happy.
>
>What ? You think perl is installed on every OS ? Well, this is starting
>to be true (except for Windows, then you'd kill "easy" portability), but
>which version of perl ? 4.x ? 5.00503 ? 5.8 ? the upcoming/mythical 6.x ?
>How do you force your users to have the version of perl/python you want
>them to use, while they may need to have a another one for another
>sotfware package ?

Stuff is written in Perl and Python. A lot of it. Somehow this problem
manages to get solved, quite often. Likewise, you can't just put Nessus on
an arbitrary machine and build it. You need certain libraries, you need a
compiler, you need certain POSIX APIs and all of those problems have been
addressed and they are solved quite often. Were just changing the problem
space. It's not like this problem isn't solved all the time by other
projects.

>Or do you want to add the source of the interpretor of your choice with
>Nessus ? Then you have to maintain a big, furry, hairy source tree you
>don't really have control on. Now _that_ is elegant.

If it makes people feel better we could do that. That's what is done now.
The Python source would be a bit bigger but it does a lot more also.

>Then you're just missing some string manipulation functions. We can add
>that to NASL2 with no problem. I hate PCREs, but if there's user support
>for it, then we can easily add it in NASL2 while we're in the /unstable/
>stable.

That's kind of the heart of the issue. Do we want plugins not to be written
until the next version of Nessus comes out? That doesn't seem good to me.

> > Besides should we be
> > forcing people to learn a new language to write plugins?
>
>Most plugins are just a couple of lines long, so
>all the complexity of the language does not need to be grasped to start
>writing something. The problem is that you seem to consider that the
>code of a plugin will take more than +12k lines of code.

That can be read as an argument for changing to something else. If most of
the scripts are so simple then why not change? They aren't going to be
dependent on specific version of Perl or Python, they aren't going to use
the 10000 different Perl modules in CPAN.

> > >it... you can be people will use their own). While both Perl and Python
> > >have sandboxed modes, vulnerabilities have been found in them and will
> > >
> > As NASL sometimes crashes you can be sure the vulnerabilities are there
> > also.
>
>Probably, but again, maybe not. NASL crashes sometimes because of the
>way the script is written. A remote server can not really crash the
>interpretor as it can not change the running script, or you'll have to
>show me a demonstration.

>The sandbox is not much in the interpretor itself rather than in its
>functions which are purposely limited : you can't open a local file, you
>can't send packets to a third party host, and so on... Very limited,
>very little risks of having a script destroying your local hard drive or
>publishing your $HOME on a newsgroup. A script can't even send the
>result of the scan of the other hosts to the host being tested.

Isn't Nessus running on a trusted machine? I think the effort would be
better spent making sure that we don't have people contributing malicous
scripts rather than trying to build a bullet proof sandbox where the harm
caused by a script can be limited. Especially if most of them at only a few
lines long. I understand the issue and I know the problem that is being
solved, I just don't think it's a very common one and I think there could be
a lot more bang-for-the-buck if energies were focused on other problems.

I also recognize that a very small number of people have been contributing,
relatively speaking. A standard language could welcome a lot more people to
the project.

Will

_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail

William Smith wrote:

>
> Isn't Nessus running on a trusted machine? I think the effort would be
> better spent making sure that we don't have people contributing malicous
> scripts rather than trying to build a bullet proof sandbox where the
> harm caused by a script can be limited. Especially if most of them at

One flaw with this argument is the fact that Nessus provides
the facility for users to be

a) restricted in what they can scan, and
b) upload their own scripts.

Vetting scripts as a process to limit potential holes is imho not
the best long term solution, not to mention that it would breach
the security model in certain modes of operation that Nessus currently
supports (because by definition not all scripts can be vetted).

> I also recognize that a very small number of people have been
> contributing, relatively speaking. A standard language could welcome a
> lot more people to the project.

I don't believe the language is the issue that prevents people
from contributing.

Thomas

"Douglas Minderhout" <dminderhout@layer3com.com> writes:

> It certainly doesn't help. I have about 5 nasls I would have finished if I
> could use one of the following languages:
> TCL PERL PHP C/C++ VBA

Then write them in whatever language you want and we'll convert them.
But please stop pissing me off with such bullshits.

I've programmed in miscellaneous dialects of Pascal, Fortran, C, C++,
Perl, TCL, Forth, Basic, several assembly languages... I've learnt
(but never practiced) Lisp, Prolog, Python and Ada. And I have *never*
met a language that forbid me from doing what I wanted.
A Turing machine is a Turing machine.

> I would be finished writing them now. As it stands, I them on the back
> burner until I have time to read through enough other NASLs to figure out
> how to use the dammed language to do what I need it to do properly without
> yeilding false positives.

Odd. If you said "without yielding syntax errors", I would have
understood, as the old interpreter was sometimes very surprising. But
I can hardly understand the relation between the language itself and
the logic of your test.

--
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, all "Nice to haves"

6 of one, 1/2 dozen of another. A computer language is a tool. A
tool to provide a means to an end.

New interpreter:
1) Time to argue which language is best
2) Time to integrate a new interpreter
3) Time to rewrite 1100+ NASL scripts
4) Time to test all of these changes. TEST! TEST! TEST! I know for
a fact Mike and Renaud do not have all of the OS's/Servers/Programs
for which Nessus tests. The entire Nessus community would need to
test. Is every Nessus user capable of determining if the Script
correctly worked for the said service/test. I doubt it.

I have met few programmers that estimate Unit/Functional/System
testing into their estimates.

I, like Michael, have programmed in most languages. I have even been
in 4 Engineering/Scientific Industries outside of computers. Never
once in my career have I lacked a tool to do the job. I have used
what is there first before necessitating a full reengineering of a
tool. NASL or any other language is just that, a tool.

Even though I am not 100% familiar with NASL I can follow it, write
it, and debug it. NASL meets those needs.

Adding a new language interpreter is a major step back on a timeline.
Certainly a nice to have for programmers familiar with other
scripting languages but to what end? Time, even in an open source
project, is money.

NASL currently does the job for which it is designed. Why fix
something that is not broken? I am certainly not going to rush out
and put a new engine in my Minivan just because I want too.

I am all for keeping what is there and focusing on enhancing NASL to
NASL2 (as per the original RFC email)

Sure, I would love to see a Java/C/C++ based scripting language but I
would rather see features that compete with commercial vulnerability
scanners.

Based on time as a consideration versus "nice to haves", where should
time be spent?

Erik

- -----Original Message-----
From: owner-nessus-devel@list.nessus.org
[mailto:owner-nessus-devel@list.nessus.org]On Behalf Of Michel Arboi
Sent: Friday, January 10, 2003 2:32 PM
To: Douglas Minderhout
Cc: nessus-devel@list.nessus.org
Subject: Re: Replacing NASL (was Re: NASL2 wish list)


"Douglas Minderhout" <dminderhout@layer3com.com> writes:

> It certainly doesn't help. I have about 5 nasls I would have
> finished if I could use one of the following languages:
> TCL PERL PHP C/C++ VBA

Then write them in whatever language you want and we'll convert them.
But please stop pissing me off with such bullshits.

I've programmed in miscellaneous dialects of Pascal, Fortran, C, C++,
Perl, TCL, Forth, Basic, several assembly languages... I've learnt
(but never practiced) Lisp, Prolog, Python and Ada. And I have
*never*
met a language that forbid me from doing what I wanted.
A Turing machine is a Turing machine.

> I would be finished writing them now. As it stands, I them on the
> back burner until I have time to read through enough other NASLs to
> figure out how to use the dammed language to do what I need it to
> do properly without yeilding false positives.

Odd. If you said "without yielding syntax errors", I would have
understood, as the old interpreter was sometimes very surprising. But
I can hardly understand the relation between the language itself and
the logic of your test.

- --
mailto:arboi@bigfoot.com
GPG Public keys: http://michel.arboi.free.fr/pubkey.txt
http://michel.arboi.free.fr/ http://arboi.da.ru/
FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Security 7.0.3

iQA/AwUBPh9HNmBNrGASwj07EQI/dACbBI1bI6R/sRDs7ONoLi1qyt8l4MwAnisV
O6kTCR6Hq7fU0xi91dcVnfLr
=ipj5
-----END PGP SIGNATURE-----

>I have met few programmers that estimate Unit/Functional/System
>testing into their estimates.
>
>I, like Michael, have programmed in most languages. I have even been
>in 4 Engineering/Scientific Industries outside of computers. Never
>once in my career have I lacked a tool to do the job. I have used
>what is there first before necessitating a full reengineering of a
>tool. NASL or any other language is just that, a tool.
>
>Even though I am not 100% familiar with NASL I can follow it, write
>it, and debug it. NASL meets those needs.

Nobody is saying that we lack a tool to do the job. Just is it the best
tool for the job. Machine code is a perfectly good tool for programming
computers as is assembly but we still build better tools for programming
computers. By that logic, why do NASL2? NASL worked just fine.

>Adding a new language interpreter is a major step back on a timeline.
> Certainly a nice to have for programmers familiar with other
>scripting languages but to what end? Time, even in an open source
>project, is money.

It's just a matter of how and when you pay. Pay up front and position
yourself in a place to engineer from or gradually digging out of holes.
I've not heard anybody say that NASL2 is going to be the end and there is no
reason to believe that this discussion won't happen again in 2 years when we
have to switch to NASL3.

>NASL currently does the job for which it is designed. Why fix
>something that is not broken? I am certainly not going to rush out
>and put a new engine in my Minivan just because I want too.
>
>I am all for keeping what is there and focusing on enhancing NASL to
>NASL2 (as per the original RFC email)
>
>Sure, I would love to see a Java/C/C++ based scripting language but I
>would rather see features that compete with commercial vulnerability
>scanners.
>
>Based on time as a consideration versus "nice to haves", where should
>time be spent?

Let me clarify my position. I'm an engineer and I'll always argue for what
I think is the most elegent solution as an engineer. I intend no disrespect
to Michael or NASL2. I just think that letting someone else focus on that
aspect makes for a more elegent product. Perl and Python have lot's of
documentation, lot's of eyes on them, and lot's of tools for us to exploit.

It's not simply a matter of changing it because we want to, we're changing
it now because the current implementation has limitations we want to fix.
Why not fix it for good and switch to something we won't have to switch
from? I'm asserting that we'd be in a more powerful position by changing it
and if we do so intelligently the tool will be much better. These kinds of
changes are painful, a 1000+ scripts may need to be rewritten. Are you sure
we won't have to do it again? I'm not a language designer, I don't know.
I do know that people have written perl and python years ago that still runs
just fine with newer implementations and language designers are working on
those.


Will

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

On Fri, Jan 10, 2003 at 09:06:12AM -0600, Douglas Minderhout wrote:
> It certainly doesn't help. I have about 5 nasls I would have finished if I
> could use one of the following languages:
>
> TCL PERL PHP C/C++ VBA


Write them in PERL/PHP, and I'll show you how to convert them in NASL.


-- Renaud

On Fri, Jan 10, 2003 at 04:33:39PM -0700, William Smith wrote:
> Nobody is saying that we lack a tool to do the job. Just is it the best
> tool for the job. Machine code is a perfectly good tool for programming
> computers as is assembly but we still build better tools for programming
> computers. By that logic, why do NASL2? NASL worked just fine.

Mkkkay, you missed an episode : NASL2 is a rewrite of the "old" nasl
interpretor. The syntax is the same and the engine is finished. Good old
NASL1 worked but was slow and would not parse all files correctly (being
too sloppy at some times and too strict at others). The point behind the
rewrite was just to have a new engine that goes 16x times faster, while
NOT rewriting the scripts.

Once NASL2 is out there, some newly written scripts might not work with
nasl1, as there were bugs in the old interpretor (read the archives of
plugins-writers@ to see what I mean), so we'll declare an
incompatibility. And since there's an incompatibility, we suggest to
improve the API. Note that the problem would be the same if we were
using python or whatever - at some point, you need to extend the API,
and we think it's a good time to do so..

Now everyone who "knows better than anybody else" takes that as a proof
that NASL is just not good for the job.

[..]
> It's just a matter of how and when you pay. Pay up front and position
> yourself in a place to engineer from or gradually digging out of holes.
> I've not heard anybody say that NASL2 is going to be the end and there is
> no reason to believe that this discussion won't happen again in 2 years
> when we have to switch to NASL3.

Same thing with whatever language when you set up an API. That's all.


[...]
> Let me clarify my position. I'm an engineer and I'll always argue for what
> I think is the most elegent solution as an engineer. I intend no
> disrespect to Michael or NASL2. I just think that letting someone else
> focus on that aspect makes for a more elegent product. Perl and Python
> have lot's of documentation, lot's of eyes on them, and lot's of tools for
> us to exploit.

Then be an engineer and PROVE that python/perl are just better for
writing vulnerability checks launched by Nessus. It's not because
everyone and their sister is using these languages to write logs
analyzers and smaller security tools that they're better to do
everything.

> It's not simply a matter of changing it because we want to, we're changing
> it now because the current implementation has limitations we want to fix.
> Why not fix it for good and switch to something we won't have to switch
> from? I'm asserting that we'd be in a more powerful position by changing
> it and if we do so intelligently the tool will be much better. These kinds
> of changes are painful, a 1000+ scripts may need to be rewritten. Are you
> sure we won't have to do it again? I'm not a language designer, I don't
> know. I do know that people have written perl and python years ago that
> still runs just fine with newer implementations and language designers are
> working on those.

What was written in NASLv1 a while ago works perfectly well with NASL2,
thank you very much.


-- Renaud

On Fri, Jan 10, 2003 at 09:43:52AM -0700, William Smith wrote:
> Stuff is written in Perl and Python. A lot of it. Somehow this problem
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

SARA and SAINT are written in python. I don't want to launch a troll
or whatever, but I don't consider them half as good as Nessus is.

That's dumb logic, but these two are the only security scanners I know
which are written in this language, and they're not good. So why should
we use python or perl ? BTW, what is the overhead of perl/python ?
Which amount of ram do they take ? I ask, because when you launch
more than one hundred instances of the interpretor in parallel, this
kind of thing starts to count.

[...]
> >Or do you want to add the source of the interpretor of your choice with
> >Nessus ? Then you have to maintain a big, furry, hairy source tree you
> >don't really have control on. Now _that_ is elegant.
>
> If it makes people feel better we could do that. That's what is done now.
> The Python source would be a bit bigger but it does a lot more also.

That's plainly stupid then. What do you gain apart from switching from a
small code base you understand (NASL) to a big one you don't ?

>
> >Then you're just missing some string manipulation functions. We can add
> >that to NASL2 with no problem. I hate PCREs, but if there's user support
> >for it, then we can easily add it in NASL2 while we're in the /unstable/
> >stable.
>
> That's kind of the heart of the issue. Do we want plugins not to be
> written until the next version of Nessus comes out? That doesn't seem good
> to me.

??? Who said ot plugins would not be written ? heck, I continue to maintain
Nessus 1.0 even though it's not 100% compatible with Nessus 1.2, so why
would I freeze everything until I release a new stable version ? How
stupid do you think I am ?

What makes you think that a plugin which uses PCREs can't be rewritten
in NASLv1 ?

[...]
> That can be read as an argument for changing to something else. If most of
> the scripts are so simple then why not change?

Because the rewriting needs to be supervised by a human being, human
beings tend to be faulty, and scripts need to be tested.

(...)
> I also recognize that a very small number of people have been contributing,
> relatively speaking.

Yes, and I can see you're one of the person who prefer to talk rather
than contribute.



-- Renaud

> Mkkkay, you missed an episode : NASL2 is a rewrite of the "old" nasl
> interpretor.
>
> Once NASL2 is out there, some newly written scripts might not work with
> nasl1, as there were bugs in the old interpretor
>
> What was written in NASLv1 a while ago works perfectly well with NASL2,

So... let's move on without re-inventing old arguments about the best
Comp Sci language; there were/are many. (Or... don't ask a question in
such a way that leads to an answer that one may not want to hear.
Whichever happens to fit from an _architectural_ perspective.)

Given 100 engineers in a room there will be 98 different answers, and
the 98 engineers will argue about the best way; when in reality, the
arguments make little material difference.

On Friday 10 January 2003 20:04, Rich Adamson wrote:
> Given 100 engineers in a room there will be 98 different answers, and
> the 98 engineers will argue about the best way; when in reality, the
> arguments make little material difference.

And the other two engineers will be actually getting work done.

I am really really sorry I brought up this topic ;)

-HD

Quoting Michel Arboi <arboi@noos.fr>:
> There are more interesting things to do in this domain: local scanner,
> database scanner, PEN-TEST toolkit / automation,etc.

I'd agree with Michel here - NASL might not be the best tool (though I quite
like it) but it does the job - and with a bit of tuning will do it better... As
a perl and lisp hater I'd rather not see everything go perl/lisp :-)

On the other hand since there are a lot of good open source tools missing from
the security professional's armoury - I have been thinking strongly about
starting an enterprise wide local scanner (mainly because the open source ones
don't allow proper enterprise scanning and the commercial ones are - in a word -
crap.)

There are much better things to do with ones time than argue about whether to
replace a tool which does the job...

dave