My Page

[#779] "checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report

2008-10-08 07:19
Submitted by:
Chandrashekhar B (chandra)
Assigned to:
Nobody (None)
Operating System:
"checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report

Detailed description
The issue occurs when multiple plugins are selected for scanning. But, when only one plugin is selected, it reports appropriately.

Example scenario:

(Quoting from Carsten)

Test is running gb_vmware_prdts_mult_vuln_win.nasl and gb_thunderbird_mult_vuln_july08_win.nasl against a host which has installed vmwareplayer 2.0.1 and Thunderbird 1.5.12. Only a warning for the vmware player is shown. Disabling the vmware check and running only the thunderbird test will bring up the Thunderbird warning.

Running Firefox and Thunderbird test against a host with both vunerable versions brings sometimes zero, one or two warnings only by running the test a few times without any changes.

Observing the logs and the saved KB items, it looks like some of the plugins are failing to launch or they exit intermittently without traversing the entire code.

Work around:

When "checks to perform concurrently" is set to 1, all plugins report appropriately.


Date: 2009-08-04 09:25
Sender: Felix Wolfsteller

Closing this issue.

All known 'problematic' checks have been fixed.

Testing took place on two different instances of Windows XP.

With a server that lists at least ports 139 and 445 in the 'non_simult_ports' configuration (openvasd.conf), parallel checks do not lead to inconsistent reports anymore.

Big thanks to Chandrashekhar B (did the main work), Michael Wiegand and Thomas Reinke.
Date: 2009-07-17 07:57
Sender: Chandrashekhar B

The bug is fixed.

There is a non_simult_ports parameter to indicate not to launch multiple plugins simultaneously on selected ports. This behavior wasn't working appropriately. The fix is committed by Felix to svn.

Tested with multiple Windows plugins with this parameter set and included script_require_ports(139,445) in those Windows plugins, and it all works fine.

Next Step:
Update all Windows plugins to include script_require_ports(139, 445) and then test will all Windows plugins.
Date: 2009-04-29 07:01
Sender: Felix Wolfsteller

Wrap- up of discussions via irc and the mailinglist:

Bugged scan results for SMB-dependend NVTs when concurrent checks is set to > 1

Chandra, michael (mwiegand) and me (felix) spent quite some time hunting this
bug, chandra was most successfull and provided most of these information.

When "Concurrent Checks" is set to more than 1, scan results differ.
More concrete, some issues are not reported when this option is set to more than 1.

Latest openvas-server, openvas-libraries, openvas-libnasl installed on
OpenVAS- Server machine.
NVT Feed sync'ed.
Latest openvas-client installed on OpenVAS Client machine (might be the same).
Target machine runs a WinXP with SP2, known user.
SMB- related NVTs selected (e.g. see next section), SMB credentials provided.

Exemplary NVT set:
These NVTs (+dependencies) enabled ('Windows Bulletins' family):
[script filename, OID, script name]

* 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)

When Local Checks are done using a SSH- Connection, this connection is shared
between multiple NVTs. This is implemented through shared_socket_acuire() and
shared_socket_release() as in ssh_login_or_reuse_connection() in ssh_func.inc.
For individual NVTs this behaviour of the server is hidden - they get served
through a ~virtual socket that gets used as if it would be a normal socket. When
open_sock_tcp() is called multiple times, underneath, there's only one socket
opened but served through multiple virtual sockets

For Local Checks that utilize SMB (ports 139/445) this behaviour is not really
implemented. Instead a different approach is used. Therefore the server has to be
configured to open sockets to port 139/449 'non-simultanously' (openvasd.conf 'non_simult_ports').
This should cause scripts that require this port to have to wait for each other,
which however seems to never happen and so the socket access 'clashes'.

If the suspect described in the previous section is indeed the culprit, there
are in principle two possible solutions:
1) Make the smb plugins use a socket sharing mechanism in the way done for
ssh connections. smb_nt.inc can be updated to perform socket register, acquire
and release procedures. But, this would impact thousands of Windows related plugins.
2) Repair the non_simult_ports issue.
The second approach is preferred, as the first one requires a lot of changes to
NVTs and individual result checking.

Related issues:
* A similar (surface) problem was observed with Local Checks using SSH, but was fixed by

* Variable name collisions: When NVTs use the same names for variables that are
not declared local, they collide. With the second proposed solution (let them
wait for each other) this problem should not occur for SMB checks anymore.

* On a Debian etch, the maximum number of sockets that NVTs could open was 192.
Date: 2009-04-17 11:55
Sender: Chandrashekhar B

Upon more testing, it was discovered that the issue was only with Windows related plugins that are using smb_nt.inc.

1. This can be confirmed by only selecting Linux based Local Checks setting concurrency to more than 1 - Works normally.
2. Select only remote checks and increase the concurrency - Works normally.

Only when Windows plugins are selected, the reports are different each time we run when concurrency is more than 1.

The reason being smb_nt.inc doesn't implement the shared socket acquire and release behavior as implemented in ssh_func.inc.

Next Step:
Need to modify smb_nt.inc and do more testing.

Attached Files:


Field Old Value Date By
ResolutionNone2009-08-04 09:25felix
close_date2009-08-04 09:252009-08-04 09:25felix
summary"checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report2009-08-04 09:25felix
status_idOpen2009-08-04 09:25felix
summary"checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report2009-07-17 07:57chandra
summary"checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report2009-04-29 07:01felix
summary"checks to perform concurrently" is set to default value of 4, some Windows plugins fails to report2009-04-17 11:55chandra

This site is hosted by Intevation GmbH