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. 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. > Now, however, while "default" is still advertised as the > default value of "port_range" (see preferences.c:83), if > you actually try to use that default string, the daemon bails > with error hm, I guess that is a left-over because near to none people use openvassd directly and openvasmd will always overwrite that "default" setting. Meanwhile port_range is not even part of the openvassd_defaults[] in preferences.c. > 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". > 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. > 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. -- Dr. Jan-Oliver Wagner | +49-541-335084-0 | http://www.greenbone.net/ Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 202460 Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner _______________________________________________ Openvas-discuss mailing list [email protected] https://lists.wald.intevation.org/cgi-bin/mailman/listinfo/openvas-discuss
