Hacking Linux Exposed





previous article
next article
An SSL Vulnerability for the Masses
By Bri Hatch.

Summary: The latest SSL bug affecting Internet Explorer presents an equally dangerous threat to other, non-Microsoft browsers as well.

Those of you following the news have probably heard about a recent SSL authentication bug [1] in Internet Explorer discovered by Mike Benham. This would be an excellent time to laugh at yet another Windows bug if it weren't for the fact that this same bug is found in Konqueror, the KDE browser. To understand the bug, let's take a look at how a browser correctly authenticates a Web server.

The Web server has a public and private key installed that it uses for encryption and authentication. When the browser connects, the Web server presents it's public key. Certificate Authority -- an overpaid entity such as VeriSign that says, "Yes, this key belongs to this site" -- signs this public key. (For more details about what SSL does and does not protect, even when implemented properly, see [2].)

The browser has a hard-coded list of acceptable Certificate Authorities. It will check the CA signature that is part of the server's certificate and verify that it is signed by one of these trusted CAs. If it is not, either the connection is dropped or you are assaulted with a series of warning dialogs.

Some site certificates are not signed directly by a CA key, but by intermediary CAs as part of a certificate chain. For example if you have a trusted Certificate Authority, "Foo Security, Inc.", and that CA has signed an Intermediate Certificate Authority for "Bar None Security", then Bar is allowed to sign server certificates such as www.example.com. This certificate chain would look something like this:

Certificate Type Trust Level
www.example.com server cert Signed by Bar None Security
Bar None Security Intermediate CA Signed by Foo Security, Inc
Foo Security, Inc Root CA Implicit trust - installed in browser

The problem with IE and Konqueror is that they simply verified that cert Foo signed cert Bar, which signed www.example.com. They did not verify that Bar was an Intermediate Certificate Authority. What does this mean? If I had a valid certificate for some domain, say www.my_domain.com, I can use it to sign any server certificate I want. For example:

Certificate Type Trust Level
www.big_bank.net server cert Signed by www.my_domain.com
www.my_domain.com server cert Signed by Foo Security, Inc
Foo Security, Inc Root CA Implicit trust - installed in browser

So, what to do? Well Konqueror had a fix available in an hour and a half. If you're using the CVS version of KDE, recompile Konqueror and you'll be all set. The fix is part of KDE 3.0.3, which is being released pretty soon. Most Linux distributions either have or are preparing updated packages.

If you're using IE then you have a longer wait in front of you. Microsoft says that the bug is in the OS, not in IE. The certificate checking code is not part of the CryptoAPI, a cryptography library used by several other Microsoft programs, so the bug only affects IE. Why the code isn't in the CrytoAPI, I can't imagine. And why the broken code - which is in the OS, not in IE -- would only affect IE, I'll leave to your imagination. But expect to wait a while. Microsoft doesn't see broken SSL as a pressing security problem.

To read more about this vulnerability, see Benham's original BugTraq post [1]. He also provides a proof-of-concept tool, sslsniff [3] that can transparently perform man-in-the-middle attacks on SSL sessions. This tool differs from the webmitm [4] tool that is part of Dug Song's dsniff package, which uses a randomly generated SSL certificate and thus sets off many warning dialog boxes on most browsers.


[1] http://www.thoughtcrime.org/ie.html
[2] http://www.hackinglinuxexposed.com/articles/20020423.html
[3] http://www.thoughtcrime.org/ie-ssl-chain.txt
[4] http://www.monkey.org/~dugsong/dsniff/

Bri Hatch is Chief Hacker at Onsight, Inc., and author of Hacking Linux Exposed and Building Linux VPNs. Perhaps he loves crypto a bit too much. Bri can be reached at bri@hackinglinuxexposed.com.

Copyright Bri Hatch, 2002.

This article was first published here in ITworld.com Inc., 118 Turnpike Rd., Southborough, MA 01772  on 20-Aug-2002.

previous article
next article