Mailing List Archive

Pavel Kankovsky <peak@argo.troja.mff.cuni.cz> writes:

> 1. local variables

Done.

> 2. null-character safety of all string operations

I have to double check.

> 3. a builtin function to extract a substring

Done: substr(s, start [,end])
See also insstr()

> 4. builtin functions to marshall and demarshall elementary binary
> values (i.e. 4 bytes as unsigned long endian integer), perhaps
> some high-level functions for complete binary structures too:
> something like configurable forge_*_packet and its (nonexistant)
> demarshalling counterpart, plus some utility functions to measure
> offsets and sizes within these structures in order to eliminate the
> need to count bytes manually (yes, I am lazy)

> 5. make it possible to terminate a plugin or a part of it when a runtime
> error (e.g. out-of-bound array access) occurs...too many plugins tend
> to enter an endless loop in such situations

The NASL2 interpreter could detect such condition but I hesitated...

> 6. identify offending plugins in their error output, esp. when written
> to nessusd.messages (perhaps a task for Nessus core?)

> 7. remove string + from the language because its behaviour is too magical
> (cf. the discussion about string concatenation several months
> ago)

I was re-reading the NASL2 code and I realized it need some fixing...

> 8. builtin functions to print diagnostic info (debugging info, warnings
> & errors)...yes, I know we have display() but I want something that
> can distinguish between "tracepoints" included for debugging purposes
> (sh -x like trace is a good thing but it can be too verbose) and
> error messages reporting real problems...

IIRC Renaud implemented a debug() function

> 9. something like BSD vis() to make it possible to include untrusted
> strings in reports and other outputs in a safe way

You mean "properly escaped"?

Michel Arboi wrote:

>Any special desire while we are working on a brand new NASL
>interpreter?
>e.g. new operators, syntax, variable types, features...
>
>
>
Well, not part of the programming, but of the way the information is
managed regarded to vulnerabilities:

- add 'script_bugtraq_id' since many plugins use Bugtraq references
inline in the description
- support for multiple CVE and Bugtraq ids.
- separate the 'risk' information from the description information
- add a 'script_external_reference' to add any url instead of inlining
it in the description. That way the reports can just add a "More info
available at:" and add the appropiate URLs.
- separate the 'Solution' information from the 'Description'
information. So you have both 'script_description' and 'script_solution'

Separating all this tidbits of information might make it easier both to
write reporting engines extracting relevant information and tools that
extract this information to do full audits of NASL provided information
(such as the one recently done by Erik Anderson). I am developing tools
to provide means to audit the NASL information so we can determine which
scripts need more information by comparing to the available information
in other security databases, separation of all the pieces of information
in distinct sections of the code (instead of allowing free text
everywhere) helps develop these tools.

Best regards

Javi

WILLIAM HEINBOCKEL wrote:

>(...)
>
>I have made a compilation of that feedback, along with some of my own
>suggestions on how to improve Nessus (inparticularly, the reporting).
>Due to the large nature of my wish list, I have put it on a website:
>http://www.rit.edu/~wjh3710/plugin_stats.html
>
How did you do the analysis, was it automated? I would like to check any
tools that digest the NASL scripts...

>There, I analyzed the current Nessus plugins for the type of vulnerability
>reported (Security Note/Warning/Hole) and there reported risk. The stats
>were surprising and lead me to believe that the vulnerability levels need
>defined.
>
Yes. The problem here is that each plugin writer has probably added the
level he felt like adding. I find no documentation in Nessus regarding
how risk levels should be added to the plugins.

>In addition, there are several other small things that can be added to
>NASL to produce better reports and results for the end-user. I have
>detailed some of the problems with NASL/plugins and some proposals for
>improvement.
>
Some of your findings have been discussed in the list previously and
it's great to see some backup statements for them.
(...)

>Free to forward me your opinions.
>
>

I believe, and this is open to discussion, that one of the major
drawbacks of Nessus versus other vulnerability scanners is that the
information included in the NASL scripts is not too detailed. I believe
the way to go here is to be able to correlate the Nessus plugins with
other sources of information. Having all plugins have CVE references is
a major asset for doing this. Even if CVE does not provide sufficient
information, CERT advisories as well vendor advisories do and so does
Bugtraq. And we can cross-reference back to them pretty easily (I have
now all the Bugtraq database in SQL format and there are about 480
plugins which could, directly, be updated with more information from
Bugtraq).

So maybe we need to take some time, digest the information, and provide
patches to the current scripts in order to improve the information they
provide. This is an enormous job, however, since there are more than
1100 plugins currently in Nessus. Volunteers? :-)

Regards

Javi

Haroon Meer wrote:

>>So maybe we need to take some time, digest the information, and provide
>>patches to the current scripts in order to improve the information they
>>provide. This is an enormous job, however, since there are more than
>>1100 plugins currently in Nessus. Volunteers? :-)
>>
>>
>
>http://www.osvdb.org/
>
I'm already aware of their efforts. Problems:

1.- they don't have yet much information (838 vulnerabilities) available
2.- the full database is not yet available for download
3.- I'm more interested in having a meta-database
(CVE+CERT+ICAT+Bugtraq+SecurityTracker+OSVDB) than a single database
(which might lack vulnerabilities, information or whatever)

Yes, I can extract the full OSVDB and use it too for the audit, probably
better than some others (since they direct cross-references to Nessus
plugins), but I do have a limited time so I currently target those more
complete and those are CVE, Bugtraq, and CERT for the time being.

Regards

Javi

On Wednesday 08 January 2003 04:36, Javier Fernandez-Sanguino wrote:
> I'm already aware of their efforts. Problems:
>
> 1.- they don't have yet much information (838 vulnerabilities)

This is just filler data until the queuing/moderation system is finished,
there are still another 200-400 that have not been added since I did the
initial import and cross-reference.

> 2.- the full database is not yet available for download

If you would like a copy of what we have now, let me know. We need to
finish the first pass of those 838 for grammar/correctness before we
start merging in the new sources. The interface for doing the first pass
already exists, just the lead developer and the rest of us involved
haven't had the time to coordinate it yet. Once thats finished, we will
make the entire SQL dump available for download. Since it is a community
project, it can go only as fast as the members have free time.

> 3.- I'm more interested in having a meta-database
> (CVE+CERT+ICAT+Bugtraq+SecurityTracker+OSVDB) than a single database
> (which might lack vulnerabilities, information or whatever)

That still doesn't solve the problem of non-standardized descriptions and
solutions in the Nessus plugins. Building a mass cross-referencing table
is easy if you already have the vulnerability data and some external
references to start on.

> Yes, I can extract the full OSVDB and use it too for the audit,
> probably better than some others (since they direct cross-references to
> Nessus plugins), but I do have a limited time so I currently target
> those more complete and those are CVE, Bugtraq, and CERT for the time
> being.

CVE is not detailed enough to use in reports. The "Bugtraq" database is
*owned* by Symantec, commercial use of it to provide reports to your
customers is not legal (in the US) without obtaining a license, as for
CERT, I am not sure what their stance is, it appears that they retain
rights, but don't explicitly forbid redistribution.

The short-term goal of the OSVDB project was to provide a solid base of
data that others could contribute to, with the end result being a
high-quality database that can be used without penalty. The response we
have received indicates that the majority of the people who complain
about the lack of available data are not willing to put in any effort to
change the situation. As such, the entire project still rests on a couple
people finding time to work on it, knowing full well that 99% of the
people waiting to use it have no intention of contributing back. This is
hardly any encouragement to hurry up and release data ;)

Once the rest of the groundwork is finished (interface, processes, etc),
it should be easy to bring the content up to date and maintain it. The
real bottleneck has been volunteer developer time, if anyone is
interested in speeding things up and has experience with PHP, shoot me an
email and I can get you in touch with the rest of the dev team. You can
find the current API and the management front-end on the first page of
the osvdb.org site.

-HD

* One of the cooler features of the OSVDB is that the references shown may
actually be "indirect". For each vulnerability, we try to obtain at least
one external reference. We then search the entire database for all other
vulnerabilities that include that reference and see what references they
have.. recursively. Many of the indirect references are found by seeing
what Snort rule a vulnerability is associated with, then finding all
other vulnerabiltiies which are detected the same way. AFAIK this is the
first database which is able to show relationships between
vulnerabilities this way. A good example is the Apache chunked encoding
vulnerabilitiy, it was automatically cross-referenced with the iPlanet
and IIS chunked encoding plugins and Snort signatures. The next iteration
of the interface will actually break down the references into direct and
indirect, so you can quickly see how class of vulnerabilties affects
multiple products.

http://www.osvdb.org/displayvuln.php?osvdb_id=838

hi..

> So maybe we need to take some time, digest the information, and provide
> patches to the current scripts in order to improve the information they
> provide. This is an enormous job, however, since there are more than
> 1100 plugins currently in Nessus. Volunteers? :-)

http://www.osvdb.org/

H D Moore wrote:

>On Wednesday 08 January 2003 04:36, Javier Fernandez-Sanguino wrote:
>
>
>>I'm already aware of their efforts. Problems:
>>
>>1.- they don't have yet much information (838 vulnerabilities)
>>
>>
>This is just filler data until the queuing/moderation system is finished,
>there are still another 200-400 that have not been added since I did the
>initial import and cross-reference.
>
>
That's good news.

>
>
>>2.- the full database is not yet available for download
>>
>>
>
>If you would like a copy of what we have now, let me know. We need to
>finish the first pass of those 838 for grammar/correctness before we
>start merging in the new sources. The interface for doing the first pass
>already exists, just the lead developer and the rest of us involved
>haven't had the time to coordinate it yet. Once thats finished, we will
>make the entire SQL dump available for download. Since it is a community
>project, it can go only as fast as the members have free time.
>
>
Yes, I am aware of this. I have slightly tested the interface but cannot
help in the API programming since I'm not PHP knowledgeable. However, I
will probably try to help in the translation arena once the interface is
up for mass-consumption.

>>3.- I'm more interested in having a meta-database
>>(CVE+CERT+ICAT+Bugtraq+SecurityTracker+OSVDB) than a single database
>>(which might lack vulnerabilities, information or whatever)
>>
>>
>
>That still doesn't solve the problem of non-standardized descriptions and
>solutions in the Nessus plugins. Building a mass cross-referencing table
>is easy if you already have the vulnerability data and some external
>references to start on.
>
The point is. With enough information available I can still see if
descriptions are appropiate or incomplete, if references are OK, etc.
Building this mass cross-referencing table is not easy since I'm not
just linking to external sites, I'm downloading it all to a single
database. The problem is, since everyone pretty much uses his own
format, one has to write stubs for every single information source in
order to integrate it into the database. Since this was intented to be
useful for Nessus I started with, obviously, the Nessus plugins, CVE is
pretty easy to change into a database (due to the CSV format being
inmediately available), Bugtraq was trickier (but I have it now
included), ISCAT is already provided in a database format (which can be
exported to an SQL database). I'm now targeting vendor advisories' and CERT.

(The reason for including vendor's information is that I want this to be
useful also for some free software OS, at least help out a bit the
Security Team at Debian)

>>Yes, I can extract the full OSVDB and use it too for the audit,
>>probably better than some others (since they direct cross-references to
>>Nessus plugins), but I do have a limited time so I currently target
>>those more complete and those are CVE, Bugtraq, and CERT for the time
>>being.
>>
>>
>
>CVE is not detailed enough to use in reports.
>
Agreed. It still is useful to determine when CVE references have not
been added and thus is not available. Since almost all databases
provided CVE references it is also useful to link between them and make
the cross references fairly easy.

>The "Bugtraq" database is
>*owned* by Symantec, commercial use of it to provide reports to your
>customers is not legal (in the US) without obtaining a license,
>
I'm not going to copy & paste Bugtraq. However, information in the
Bugtraq database was made through public disclosure in a _public_
mailing list. If I can get to the point of being able to track down a
bugtraq id to a single post (not copyrighted by Symantec and free to
use) I _can_ use this information as I see fit. So, the database
contents are not fully owned by Symantec since some (most?) have been
provided by other people.

>as for
>CERT, I am not sure what their stance is, it appears that they retain
>rights, but don't explicitly forbid redistribution.
>
Redistribution is permited. Commercial use is not. See
http://www.cert.org/legal_stuff/legal_stuff.html

In any case, I'm not going to copy and paste CERT either to NASL
description/solution, but use it to determine if links are appropiate
and if the solutions proposed are correct.

>The short-term goal of the OSVDB project was to provide a solid base of
>data that others could contribute to, with the end result being a
>high-quality database that can be used without penalty. The response we
>have received indicates that the majority of the people who complain
>about the lack of available data are not willing to put in any effort to
>change the situation.
>
Unfortunately there was not that much I could contribute (besides
translating the database or adding new vulnerabilities to it). I'm not
PHP knowledgeable (yet).

(...)

>email and I can get you in touch with the rest of the dev team. You can
>find the current API and the management front-end on the first page of
>the osvdb.org site.
>
Already downloaded and in my TODO list.

>
>-HD
>
>* One of the cooler features of the OSVDB is that the references shown may
>actually be "indirect". For each vulnerability, we try to obtain at least
>one external reference. We then search the entire database for all other
>vulnerabilities that include that reference and see what references they
>have.. recursively.
>
That is pretty nice. I believe this is not done through the interface,
or is it?

Regards

Javi

A complete audit of all Nessus NASL scripts is nearly completed (well
over a month of work so far). I have audited over 1000 NASL scripts and
I have about 100 left. I have found and submitted to Renaud over 100+
updated scripts to provide more BugtraqID's and CVE/CAN's.

For those CVE/CAN/Nasl Scripts for which SecurityFocus is missing a
vulnerability entry I have submitted those to the VulnDB personnel at
SecurityFocus. SecurityFocus is a bit behind but they are entering all
of the missing vulnerabilities onto their VulnDB system.

For those that do not have vulnerabilities in the SecurityFocus system I
have searched their Advisory and Message archive and provided Reference
links directly in the NASL scripts. A few I could not find messages for
in SecurityFocus and I thus found in other vulnerability systems (Such
as www.kb.cert.org, Cisco sites, and Oracle Sites).

By the end of this weekend nearly every vulnerability that Nessus is
scanning for will have source reference links, BugtraqID's, CVE's, or CAN's.

Since Renaud, Mike, and Nessus community has put so much great work into
this scanner my company decided to submit all of our improvements, audit
results, and such back to Nessus.

I am sure the results will be to everyones liking.

Erik Anderson
Carmichael Security

Javier Fernandez-Sanguino wrote:

> Haroon Meer wrote:
>
>>> So maybe we need to take some time, digest the information, and provide
>>> patches to the current scripts in order to improve the information they
>>> provide. This is an enormous job, however, since there are more than
>>> 1100 plugins currently in Nessus. Volunteers? :-)
>>>
>>
>>
>> http://www.osvdb.org/
>>
> I'm already aware of their efforts. Problems:
>
> 1.- they don't have yet much information (838 vulnerabilities) available
> 2.- the full database is not yet available for download
> 3.- I'm more interested in having a meta-database
> (CVE+CERT+ICAT+Bugtraq+SecurityTracker+OSVDB) than a single database
> (which might lack vulnerabilities, information or whatever)
>
> Yes, I can extract the full OSVDB and use it too for the audit,
> probably better than some others (since they direct cross-references
> to Nessus plugins), but I do have a limited time so I currently target
> those more complete and those are CVE, Bugtraq, and CERT for the time
> being.
>
> Regards
>
> Javi
>
>
>
>

Erik Anderson wrote:
(...)

> By the end of this weekend nearly every vulnerability that Nessus is
> scanning for will have source reference links, BugtraqID's, CVE's, or
> CAN's.

That's great news. I thought that you were finished doing these audit.

> Since Renaud, Mike, and Nessus community has put so much great work
> into this scanner my company decided to submit all of our
> improvements, audit results, and such back to Nessus.

That's also great news.

> I am sure the results will be to everyones liking.

At least for me they will be. I'm interested in making this easier the
next time around (when Nessus has over 2000 checks in version 2.0 :)
That's why I'm comitting the scripts that extract this into a metadabase
which can be easily updated to do cross-reference checks in a continous
way. This should make audits much more easy to do since the burden of
normalising the information and correlating it would be reduced. Also,
if NASL2 included a tid-bit more separation in the NASL
vulnerability-related information it might be easier to detect some more
issues (such as abnormally high Risks for vulnerabilities not
considered risky by others).

Also notice that I feel that having all the plugins in a database,
together with means of converting the nessus reports (either NSR, NBE or
XML) into another database could allow for new ways to manage reporting
in Nessus and to do vulnerability managenemt.

Sample:
Maintain a database of scanned hosts and their reports in the database
together with the plugins. Whenever a new plugin is added, a new scan
can be programmed for those hosts that were not tested with this plugin
before. Also, this could be linked with a ticket-based system so that
when system administrators reported to it they have added the
patch/fixed the configuration that made this vulnerability surface,
automatically, the system could re-scan the host with the supposedly
(sp?) fixed vulnerabilities to determine if they persist.

This is kind of putting the knowledge base of Nessus into a database for
use it in the long-run. Of course, it is also something I have in mind,
not someting that could be made with/around Nessus at the moment. On
second thought, maybe someone has already done this. Anyone?

In any case, congratulations on your great work, Erik.

Javi

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

> 1) Some way to return the contents of brackets from regular
> expressions

Like the $1, $2 in Perl I suppose. I'll have a look at the
ereg_replace function and see if we can do something from it.

> 2) Able to expand arrays into variables, like (a, b, c) = array

Mmmmhhhh... You really like Perl, don't you? :-)
This needs some kind of "reference to variable" type, and it is not
implemented (yet?).
Currently, NASL2 doesn't even accept this kind of thing:
s = "abc";
s[0] = "z"; # s = "zbc"

> 3) split
> 4) foreach

I'll work on this one day.

> 5) some library function to help with version number checks

Any idea or example?

Richard Moore <rich@westpoint.ltd.uk> writes:

> I wonder if you have considered embedding a Javascript interpreter in
> nessus rather than implementing your own interpreter?

I did not. When I discovered Nessus, NASL already existed.

> It is very easy to add custom functions (e.g.. forge_ip_packet) to the
> interpreter

Well, adding custom functions to the NASL interpreter is really easy
too. The problem is not here.

> so there would be no change in the ease with which
> scripts could be written. Using Javascript would also solve problems
> like the lack of power of the existing regexp engine

What's the problem with the regex engine?

> and the ability to use tools such as a debugger would help script
> writers.

nasl -T tracefile -t target your_script.nasl

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

> This may be stupid, but it would really turn me on if NASL worked a lot more
> like expect.

Well, I know expect (I've written Dejagnu tests) and I never missed
its function for security tests.
Anyway, if we really need this, we'd better use a TCL interpretor
rather than rewrite this for NASL

> It would be grand also if NASL2 used TCL.

TCL cannot parse the existing NASL scripts.
I agree that what is done in NASL could be done in TCL. In a future
version maybe?

> Additionally, while I have some attention, this is more a Nessus feature
> than a NASL2 feature, another thought of mine is to do some platform
> detection. My vision is that any NASLs that depend on a particular platform
> would identify the platform name in the KB and other NASLs could check for
> it. This would drastically reduce the time required in a scan and reduce
> false positives.

Currently, click on "optimize the test".
However, I think there should be several option for this, e.g.:
1- need ports
2- need KB keys
3- reject KB keys

(1) is almost always useful and cannot trigger false negative.
(2) and (3) can.

Hi,

>5) some library function to help with version number check
>
It's quite a lot of typing to do somethime like this:

if(major < req_major || major == req_major && (minor < req_minor ||
minor == req_minor && point < req_point))

And although it's relatively striaght forward to write this, it's very
hard to read it. The situation is worse if you're checking versions are
between some values.

So it would be nice to have a compate_ver(j,n,p, rj,rn,rp)

Hmmm... one way to do this would be like version_number = 1000000 *
major + 1000 * minor + point, could then do normal compares using the
version number, provided no number was >= 1000.

Not sure exactly what I want, but combined with the ability to grab
regex contents, I think version number checking could be made more
realiable and MUCH more legible.

>>2) Able to expand arrays into variables, like (a, b, c) = array
>>
>>
>Mmmmhhhh... You really like Perl, don't you? :-)
>
Yep I sure do :-) Not to mention Python and ML.

BTW, someone else mentions MD5 for NASL2 and I just wanted to reiterate
that, would be very useful for the plugin I'm currently working on.

Thanks for your feedback Michel. I think the new NASL could be good. I
hope to be able to familiarise myself with the internals over the coming
months.

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

Michel Arboi wrote:
> Richard Moore <rich@westpoint.ltd.uk> writes:
>
>>I wonder if you have considered embedding a Javascript interpreter in
>>nessus rather than implementing your own interpreter?
>
> I did not. When I discovered Nessus, NASL already existed.

Sure, I guess what I'm suggesting though is that rather than writing a
new interpreter (NASL2), this might be a good time to switch to an
existing language.

>>It is very easy to add custom functions (e.g.. forge_ip_packet) to the
>>interpreter
>
> Well, adding custom functions to the NASL interpreter is really easy
> too. The problem is not here.

I referred that facility becuase it is mentioned in the NASL
documentation as being a reason why a standard language wasn't used in
the first place. It illustrates why I think it would be easy to make
javascript compatible with existing scripts.

>>so there would be no change in the ease with which
>>scripts could be written. Using Javascript would also solve problems
>>like the lack of power of the existing regexp engine
>
> What's the problem with the regex engine?

As mentioned by others, there is no support for paren references also,
as far as I'm aware, there is no way to see how long a match was. Both
features make working with more complex patterns much easier.

>
>>and the ability to use tools such as a debugger would help script
>>writers.
>
> nasl -T tracefile -t target your_script.nasl
>

That's useful, but doesn't really compare with tools like these:

http://www.hacksrus.com/~ginda/venkman/screenshots/venkman-20020726.png
http://www.xs4all.nl/~jjvrieze/snapshot2.png

Cheers

Rich.

Richard Moore <rich@westpoint.ltd.uk> writes:

> Sure, I guess what I'm suggesting though is that rather than writing a
> new interpreter (NASL2), this might be a good time to switch to an
> existing language.

Waiting for the release of the new interpreter is not the good time to
suggest to trash it, IMHO.
And who will rewrite the 1149 existing NASL plugins?

> As mentioned by others, there is no support for paren references also,
> as far as I'm aware, there is no way to see how long a match was. Both
> features make working with more complex patterns much easier.

I'll have a look at it.

> That's useful, but doesn't really compare with tools like these:
> http://www.hacksrus.com/~ginda/venkman/screenshots/venkman-20020726.png
> http://www.xs4all.nl/~jjvrieze/snapshot2.png

Honestly, I never feel the need of a complex debugger for NASL
scripts. We are just writing security tests, not full scale programs.

On Thu, Jan 09, 2003 at 12:10:15PM +0100, Michel Arboi wrote:
> Waiting for the release of the new interpreter is not the good time to
> suggest to trash it, IMHO.
> And who will rewrite the 1149 existing NASL plugins?

The problem is not really to test the 1149 existing scripts rather than
to *test* them. People often tend to forget that all (ok, "most of") the
scripts have been tested and have proved to work against the targetted
flow. If we play the rewrite game, then stuff might be silently missed.



-- Renaud

On Thu, Jan 09, 2003 at 06:07:36PM +0100, Renaud Deraison wrote:
> On Thu, Jan 09, 2003 at 12:10:15PM +0100, Michel Arboi wrote:
> > Waiting for the release of the new interpreter is not the good time to
> > suggest to trash it, IMHO.
> > And who will rewrite the 1149 existing NASL plugins?
>
> The problem is not really to test the 1149 existing scripts rather than
^^^
"rewrite". Typo, sorry.

> to *test* them. People often tend to forget that all (ok, "most of") the
> scripts have been tested and have proved to work against the targetted
> flow. If we play the rewrite game, then stuff might be silently missed.
>
>
>
> -- Renaud

--
Renaud Deraison
The Nessus Project
http://www.nessus.org

> Any special desire while we are working on a brand new NASL
> interpreter?
> e.g. new operators, syntax, variable types, features...

Maybe it's a strange wish.
Could NASL2 generate the reports with multi-language?

I mean, in Nessus 1.2.x, when we add a language option like ["chinese"]
that uses traditional Chinese(big5, it's a Double Byte Character Set) words
in plugins,
the chinese words can present right in NessusWX 1.4.2.
But they present wrong in the result reports(the .html format).

On Thu, Jan 09, 2003 at 10:10:51AM +0000, Paul Johnston wrote:
> So it would be nice to have a compate_ver(j,n,p, rj,rn,rp)

Why note "compare_ver(str1, str2)" in that case. Once you've split the
version number, you've done half of the job already, so let's have the
library do everything.

-- Renaud

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

> * var++, var--, --var, and ++var operators
> * a reference type would allow functions to return array references, so
> user created functions could have multiple return values
> * NULL value - "0" should not the return value for an error response

All this is OK

> * defined() function to test for a NULL value

We have is_null() which give the opposite result.

> * array_pop(), array_push(), array_shift(), array_count() functions

I have a proble with this: NASL array accepts arbitrary indexes, so
they are hash sets in fact => Not ordered.

> * assign numerical indexes to each array entry keyed by a string, ex:
> test["bob"] == test[0]

Currently you can mix text and numerical indexes, so x['a'] and x[0]
and two differents array cells

> * a select(fd, timeout) function for sockets, to test for pending data
>
> * MD5 function that returns the 32 byte hex string
>
> * Base64 encode and decode functions
>
> ... sure there are more, just need a few minutes to look over some code
> and see what would have made things less painful ;)

--
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/

On 7 Jan 2003, Michel Arboi wrote:

> > 5. make it possible to terminate a plugin or a part of it when a runtime
> > error (e.g. out-of-bound array access) occurs...too many plugins tend
> > to enter an endless loop in such situations
>
> The NASL2 interpreter could detect such condition but I hesitated...

It can be an optional feature.

> > 9. something like BSD vis() to make it possible to include untrusted
> > strings in reports and other outputs in a safe way
>
> You mean "properly escaped"?

Yes, sort of. I would like to do

some_data = raw_string(..., 0xab, ..., 0xfe, ...);
report = string("...blah ", vis(some_data), " blah...");

and get something like

...blah ``hggjf[ab]sdfhgfqe[fe]xx'' blah...
^^^^^^^^^^^^^^^^^^^^^^^^^^^
in the report. The exact text representation of chr(0x0a) etc. might
be different but it should 1. prevent raw binary crap from being included
in the output (in particular, it should be safe to cat the report
without risking that my terminal will be messed up), 2. make it easy to
distinguish the escaped part from other text. In a fully XML-ized output,
this might produce something like

...blah <rawdata>hggjf&#xab;sdfhgfqe&#xfe;xx</rawdata> blah...

and the engine displaying it would know that special characters within
<rawdata> has to be displayed in a special way.

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

"Felix Huber" <huberfelix@webtopia.de> writes:

> is
> test[] = "nextvalue" also supported?

I changed the way arrays are implemented. We could support it
now... but I really think that this syntax is ugly.
Can't you write something like:
i = 0;
test[i++] = "value";
test[i++] = "something";
test[i++] = 42;

OK, I should implement a max_index function...

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

> * a reference type would allow functions to return array references, so
> user created functions could have multiple return values

A function should be able to return an array as soon as I remove the
free() which should not be here...

> * a dereferencing and reference test function to see if a variable
> contains a refernece and what type it is

Something like this?
---------------------------------
v[0] = "UN"; v[1] = 'DEUX';
x = 1; z= 3;
display("x = ", typeof(x), "\ny = ", typeof(y), "\nv = ", typeof(v),
"\nv0= ", typeof(v[0]), "\nv1= ", typeof(v[1]), "\n");
---------------------------------
$ nasl /tmp/d.nasl
x = int
y = undef
v = array
v0= string
v1= data
$
---------------------------------

On Sunday 26 January 2003 17:50, Michel Arboi wrote:
> H D Moore <hdm@digitaloffense.net> writes:
> > * a dereferencing and reference test function to see if a variable
> > contains a refernece and what type it is
>
> Something like this?

Yeah, that works great, I will check it from CVS in a second ;)