TUCoPS :: Web :: Apache

TUCoPS :: Web :: Apache :: web5698.htm
Remote detection of vulnerable OpenSSL versions
18th Sep 2002 [SBWID-5698]
COMMAND

	
		Remote detection of vulnerable OpenSSL versions
	
	

SYSTEMS AFFECTED

	
		This is the point :-)
	
	

PROBLEM

	
		Just a solution !
	
	

SOLUTION

	
		Remote detection of vulnerable OpenSSL versions
		

		   RUS-CERT has developed a tool to remotely detect vulnerable OpenSSL

		   implementations.

		

		Why is such a tool required?
		

		   While the "Slapper" worm is spreading, many system administrators ask

		   themselves whether their systems are vulnerable. Even if you apply

		   vendor patches regularly, there are some risks which are hard to deal

		   with:

		

		     * Vendors might use OpenSSL to implement SSL services, but do not

		       publicize it. Consequently, administrators might not know that

		       they need to update.

		     * Human error might leave systems vulnerable (e.g. people forget to

		       restart services after applying patches, or are distracted by

		       phone calls and miss a machine).

		     * Other SSL implementations might have similar bugs.

		     * Vendor upgrades often do not alter the version number, and their

		       is no easy way to check if a patched version is running.

		     * Vendor patches sometimes do not eliminate the vulnerability.

		

		   As a result, full disclosure is essential; it makes independent

		   regression testing possible.

		

		How does it work?
		

		   It is difficult to tell OpenSSL 0.9.6e from vulnerable versions

		   because the OpenSSL developers chose to terminate the process if a

		   buffer overflow attempt is detected. Over the network, a crash due to

		   a buffer overflow and an abrupt, but deliberate process termination

		   look the same: in both cases, the TCP connection breaks down. At first

		   glance, it appears that we are out of luck and cannot detect

		   vulnerable versions.

		

		   However, if we overrun the buffer by only a few bytes, the vulnerable

		   version (without check) does not crash. This way, we can tell 0.9.6e

		   from previous, vulnerable versions:

		

		                             small overflow large overflow

		                  pre-0.9.6e    no crash        crash

		                      0.9.6e     crash          crash

		                      0.9.6g     error          error

		

		   (0.9.6g signals an SSL error over the network, as one would expect.)

		

		   Other combinations are possible, of course, and this program tries to

		   flag them in a reasonable way. (We consider malformed responses an

		   indication of lack of care, and a potential security problem.)

		

		   This program performs a third connection attempt (actually the first

		   one), to test compatibility of the the SSL implementations.

		

		Obtaining and running the tool
		

		   You can download a copy of the C source code here:

		

		<http://CERT.Uni-Stuttgart.DE/advisories/openssl-sslv2-master/openssl-sslv2-master.c>

		

		   Compiling this program requires an OpenSSL development environment

		   (including header files). You have to link this program with OpenSSL's

		   "crypto" library (using "-lcrypto", not "-lcrypt"). On some systems,

		   you have to link with "-ldl", too.

		

		   After compilation, you can run this program using:

		

		$ ./openssl-sslv2-master [-s] host-IP [port]

		

		   Then a test is performed against host-IP (an IP address in dotted-quad

		   notation) and the TCP service running on port (a decimal number). port

		   can be omitted, then the default port 443 is assumed.

		

		   Note: You can use this program to test any SSL Version 2.0 server, not

		   just HTTPS servers. For some services, a STARTTLS message is required

		   to initiate the SSL handshake (e.g. SMTP, POP3, IMAP). This message is

		   sent if you supply the "-s" option.

		

		Risks and limitations
		

		   The server could crash (when the large buffer overflow is attempted),

		   and fail to restart automatically. The program detects this, but

		   obviously cannot undo any damage.

		

		   If the server which is being tested does not support SSLv2, it often

		   reacts in a strange way. The SSL protocol does not define a clear

		   rejection message, so no proper diagnosis is return by the tool in

		   such cases. To determine the cause of a handshake failure, you should

		   use a full SSL/TLS implementation, such as "openssl s_client".

		

		Credits
		

		   This program was inspired by the source code of the "Slapper" worm.

		

		   Thanks to Helmut Springer for testing and spotting a few bugs.

		

		About RUS-CERT
		

		   RUS-CERT <http://CERT.Uni-Stuttgart.DE/> is the Computer Emergency

		   Response Team located at the Computing Center (RUS) of the

		   University of Stuttgart, Germany.

		

		URL of the current version of this document:
		

		   <http://cert.uni-stuttgart.de/advisories/openssl-sslv2-master.php>

		

		-- 

		Florian Weimer 	                  Weimer@CERT.Uni-Stuttgart.DE

		University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/

		RUS-CERT                          fax +49-711-685-5898