[Openvas-devel] Need help with Concurrent Checks Bug
felix.wolfsteller at intevation.de
Wed Apr 15 13:53:26 CEST 2009
It equally works well with just two nvts enabled (+depends):
Both are in the 'Windows Bulletins' family.
* secpod_ms09-001.nasl, OID 900069 : Vulnerabilities in SMB Could Allow Remote
Code Execution (958687)
* secpod_ms08-071.nasl, OID 900059 : Vulnerabilities in GDI Could Allow Remote
Code Execution (956802)
Running authorized against a WinXP, create different reports with concurrent
checks ==1 and == 2.
Renaming the variable share in secpod_ms09-001.nasl: ll96 and ll100 fixes this
That is very interesting because the variable name 'share' does not occur in
any included files, but is handed as parameter to GetVer in secpod_smb_func.
My first geuss was that it could have something to do with the named
parameters ('share:share'), but when I renamed 'share' in
secpod_ms08-071.nasl to match the new name from the second NVT, the problem
occurs again, meaning that it is really the variable name that matters.
On Tuesday 14 April 2009 13:06:59 Felix Wolfsteller wrote:
> I found a rather small setup that might allow inspections:
> Setup: openvas-server on debian, target is a win xp machine (w/sp2 i
> Dependency at runtime enabled, plus following checks (Family, Name, OID):
> * Microsoft Bulletins, SMB Could Allow Remote Code Execution Vulnerability
> (957097), 900057
> * Microsoft Bulletins, Unchecked Buffer in PPTP Implementation Could Enable
> DOS Attacks (Q3298349), 11178
> * Microsoft Bulletins, Unchecked Buffer in XP Redirector (Q810577), 11231
> * Microsoft Bulletins, Vulnerabilities in GDI Could Allow Remote Code
> Execution (956802), 900059
> * Microsoft Bulletins, Windows Kernel Elevation of Privilege Vulnerability
> (954211), 900051
> * Windows, Microsoft Windows NSlookup.exe Remote Code Execution
> Vulnerability, 900108
> * . Windows, .NET JIT Compiler Vulnerability, 90010
> * Windows, Windows Vulnerability in Microsoft Jet Database Engine, 90024
> On this setup reports from scans with concurrent checks == 1 and ==2 differ
> quite consequently.
> On Tuesday 07 April 2009 12:32:17 Felix Wolfsteller wrote:
> > Time has come to get rid of the concurrent checks problem.
> > Some bug prevents checks to result in a deterministic report if "Checks
> > to perform concurrently" is set != 1.
> > The proposed solution (set "Checks to perform concurrently" != 1) is a
> > workaround at best.
> > Therefore it is now time to find and eliminate this bug. I am calling for
> > help.
> > The main bug report is
> > http://bugs.openvas/779
> > but I feel that http://bugs.openvas/788 and http://bugs.openvas/886 might
> > be connected to it.
> > It seems that the bug appears only when local checks are employed.
> > Any help (logs, openvasrcs, tons of lines of code, words of
> > encouragement, insights) would be greatly appreciated.
> > felix
Felix Wolfsteller | ++49-541-335 08 3451 | http://www.intevation.de/
PGP Key: 39DE0100
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
More information about the Openvas-devel