Mailinglist Archive: opensuse-security (375 mails)

< Previous Next >
Help for Remote detection of vulnerable OpenSSL versions
  • From: "Fred A. Miller" <fm@xxxxxxxxxxx>
  • Date: Wed, 18 Sep 2002 13:22:32 -0400
  • Message-id: <200209181322.33734.fm@xxxxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Remote detection of vulnerable OpenSSL versions

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>

- --
Fred A. Miller
Systems Administrator
Cornell Univ. Press Services
fm@xxxxxxxxxxx, www.cupserv.org
- --- SuSE Linux v8.0 Pro, KMail 1.4.3---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAj2ItlgACgkQB9vk4ichYXfIaQCgtRabpFtgk6YPij6e8rbV9Tj7
JMQAoKhzEdkI9YqBE9YlQkmfXR53+pjF
=MVqB
-----END PGP SIGNATURE-----


< Previous Next >
This Thread
  • No further messages