Followup
| Message |
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.
Surface:
--------
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.
Setup:
------
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)
Technical:
----------
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'.
Solution:
---------
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
Chandra.
* 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.
|
|
