On 23/07/14 04:27 AM, Jan-Oliver Wagner wrote:
On Dienstag, 22. Juli 2014, Thomas Reinke wrote:
The latest version of openvas has changed the logic used to
validate the "port_range" passed in. One of the values
advertised that can be used is the string "default", and if
you look at older daemons, they specifically support that
via the "getpts" call.
with "latest" you mean OpenVAS-6 here?
Note that OpenVAS-7 removed even more of that port_range
handling.
My bad...I missed openvas7, so yes, we were talking about
openvas6.
The rationale was that a term "default" is entirely intransparent
for the user. The touched ports should not be a matter
to decide by some tools at the end of the chain. It needs always
control from top level.
Well, yes and no...unless the top level decision is (as was in
this case) to trust the nmap services configuration file as a
key, optimal way of scanning for open ports. Not all "well
known services" reside in a specific port range.
Re impact:
FYI - I am seeing downstream impact, as amap.nasl and nmap.nasl
have explicit checks for the value "default" to control certain
behaviours. That might be a non-trivial impact in terms of
expected behaviour/performance of nmap itself...
hm, this is somewhat in conflict with the intransparency of what
is going on. A Nmap expert of course might know well what will
happen using "default".
That's, in my opinion, THE common way to run nmap (no port options).
It's the biggest bang for the buck from nmap. It's not really
an 'expert' thing - if you use nmap at ALL and know what it does,
you are using that mode.
The specific use case for us is that we use the 'default' value
of nmap to control nmap's scan to scan any port below 1024 and
all known service ports that nmap has, and to then feed that
back into openvas. It looks to me based on observations (haven't
run the actual tests yet), that this capability would now be
broken, as there would be no way of telling nmap to leverage this
default behaviour set.
right, you need now to express the ports explicitly.
Got it...not my preferred approach (I've always been a fan of all
the work that nmap did in identifying all the common services). To
have to grab all that out seems...redundant. Not a huge issue though,
and admittedly I like the idea of passing port list better than
the idea of patching back two versions of openvassd.
I am guessing based on a cursory reading of the code that backwards
compatibility could be re-instated by modifying the check for
a string of "-1" failure to be a check for failure of both
"-1" and "default"...
I.e. change in attack.c
if (strcmp (port_range, "-1") != 0)
to
if (strcmp(port_range, "-1")!=0) && strcmp(port_range, "default")!=0)
Anyone see any issues with what's been suggested?
I don't see one for OpenVAS-6 branch (OpenVAS Scanner 3.4).
If the patch works for you without flaws, you can commit or let us
know to do so.
It won't apply for OpenVAS-7 though as the conceptual change would not
allow to transfer a setting that is understood by some port scanner in some
way.
Probably would be good to understand and handle the logic in the nasl
scripts that still rely on the "default" values...
Thomas
_______________________________________________
Openvas-discuss mailing list
[email protected]
https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
