[Openvas-devel] Need help with Concurrent Checks Bug
bchandra at secpod.com
Wed Apr 15 10:08:55 CEST 2009
We did more testing here. The problem doesn't seem to be with variable names
alone. It is with the returning of same socket descriptor when you call
open_sock_tcp(). If you set concurrent checks to more than 1 and run, both
plugins get the same value for open_sock_tcp(). And that's why it abruptly
ends while they are running depending on the status of the socket. Whoever
who gets the handle first will run successfully and the rest are time
We got to debug open_sock_tcp(). The variables name conflict is also an
issue, have filed a bug (#945) on that and we need to take care of this
while coding NASL's.
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Felix
Sent: Wednesday, April 15, 2009 1:26 PM
To: openvas-devel at wald.intevation.org
Subject: Re: [Openvas-devel] Need help with Concurrent Checks Bug
Wrap-up of yesterdays hypothesis for which there is strong evidence.
* Surface Problem: When "concurrent checks" is set >=2, scans lead to
different reports (compared to "concurrent checks" == 1). This is observed
for local checks only.
* Hypothized Deep Problem: In NASL, variables are assumed to be global
declared local. Local checks often employ variables with the same name
in unfortunate condition makes them the variable actually). At some point
NVTs seem to access variables declared by other NVTs or variables of
included 'nasl libraries' (e.g. .inc s).
* Solution: I do not yet see an easy solution to that problem. For new
scripts, authors should be careful with variable naming. I fear that any
solution will be tedious and long work, eventually changing a great portion
of the (10K!) NVTs and/or changing the NASL-Syntax or semantics (e.g.
variables are implicit local).
Any suggestions welcome, I will open a CR once a practicable idea surfaced.
I recommend hard-setting the number of concurrent checks to 1 until its
Eventually the limit could be conditioned on existance of a local check.
On Tuesday 14 April 2009 13:26:17 Felix Wolfsteller wrote:
> Some evidence for chandras guess that it might have something to do with
> variable naming:
> make tests as described below, than apply the attached patch against
> secpod_ms08-071.nasl in servers plugin dir, restart the server and redrive
> the tests.
> -- felix
> 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
> > think).
> > Dependency at runtime enabled, plus following checks (Family, Name,
> > * 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),
> > * 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,
> > On this setup reports from scans with concurrent checks == 1 and ==2
> > differ quite consequently.
> > hth
> > felix
> > 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
> > > 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
Openvas-devel mailing list
Openvas-devel at wald.intevation.org
More information about the Openvas-devel