[Openvas-devel] Need help with Concurrent Checks Bug

Chandrashekhar B bchandra at secpod.com
Wed Apr 15 10:08:55 CEST 2009


Felix,

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
dependent. 

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.

Thanks,
Chandra.

-----Original Message-----
From: openvas-devel-bounces at wald.intevation.org
[mailto:openvas-devel-bounces at wald.intevation.org] On Behalf Of Felix
Wolfsteller
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
unless 
declared local. Local checks often employ variables with the same name
(which 
in unfortunate condition makes them the variable actually). At some point 
NVTs seem to access variables declared by other NVTs or variables of
commonly 
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
fixed.
Eventually the limit could be conditioned on existance of a local check.

-- felix

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,
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.
> >
> > 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
"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
_______________________________________________
Openvas-devel mailing list
Openvas-devel at wald.intevation.org
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel



More information about the Openvas-devel mailing list