May 16, 2008
SSL Vulnerabilities
|
Alexander Klink has been looking into ways X.509 certificates can be abused. |
Sean Comeau: X.509 infrastructure is quite mature. You'd think widely deployed systems have implemented it correctly by now. How are browsers and mail clients still getting it wrong?
Alexander Klink: X.509 is indeed quite mature, but there are some reasons why implementers still get it wrong.
First of all, X.509 with all its extensions and bells and whistles is incredibly complex. This means that most implementations have only implemented a subset of all the features. As they now strive to implement more and more of it, they run into problems that no one has experienced before and into actual bugs within the standard (as in the "HTTP over X.509" case, where Microsoft has implemented more of the standard than the rest of the world and got bitten by it).
Secondly, people sometimes assume that certificates have to do with trust and are thus only issued by trusted parties which won't mess with the certificate contents. I assume this is what happened to Opera in the heap buffer overflow I recently discovered.
Third of all, implementers have traded convenience against security in some cases, sometimes ignoring the standard. For example, Firefox has only recently changed the setting to not automatically use a TLS client certificate whenever a server asks for one. The old setting was quite convenient for the user, but had privacy implications, especially when combined with an unnoticed installation of such a client certificate. Similarly, most browsers allow wildcard DNS names that are much more flexible than allowed by the standard, some even allow "*" to match all possible hostnames. This is of course very convenient for a system administrator, who can then get a wildcard certificate for his system, but can be a security problem - if you (even temporarily) trust me for "*", you also trust me for https://www.yourbank.com.
Sean Comeau: Has the Opera heap overflow been patched yet?
Alexander Klink XIt has been patched for the desktop version and they are currently fixing it for some other version (probably "Devices") - they said they would have it fixed by next Thursday - finally :-)
Sean Comeau: What does the standard say about use of wildcards?
Alexander Klink: RFC 3280 says the following:
| Finally, the semantics of subject alternative names that include | wildcard characters (e.g., as a placeholder for a set of names) are | not addressed by this specification. Applications with specific | requirements MAY use such names, but they must define the semantics.
and RFC 2818 (HTTP Over TLS) defines that for HTTPS:
| Names may contain the wildcard | character * which is considered to match any single domain name | component or component fragment. E.g., *.a.com matches foo.a.com but | not bar.foo.a.com. f*.com matches foo.com but not bar.com.
Sean Comeau: Are all SSL capable clients affected?
Alexander Klink: I'll be talking about several issues in which different clients are affected. Luckily, some of the issues have been fixed and others are only present in certain clients - they were mostly lucky because they did not implement the complete standard.
Sean Comeau: What is cross domain user-tracking?
Alexander Klink: Cross domain user-tracking using TLS client certificates is a bug that has recently (with version 2.0.0.13) been fixed in Firefox and is still present in Safari on Mac OS X. Both Firefox and Safari allow for an easy key generation and certificate installation in the browser that can be done (nearly) unnoticed by the user. Firefox < 2.0.0.13 and Safari then proceed to automatically use this client certificate whenever a server asks for it.
To use this for user tracking, one could generate a certificate with the username as certificate subject, install it in the clients browser and read it from anywhere - contrary to cookies, TLS client certificates are then not limited to the issuing server/domain. I guess seeing for yourself is the easiest way - there is a PoC available at http://0x90.eu/ff_tls_poc.html
Sean Comeau: You say broken implementations can be forced to trigger unwanted HTTP requests. Can this be used to perform XSRF attacks?
Alexander Klink: "Broken" may be the wrong word here - we are actually talking about implementations that implement the standard correctly - actually the standard seems to be broken in this case. The only implementation that I currently know of is the one in Microsoft's CryptoAPI, which is used by Outlook and Office 2007, for example. XSRF attacks are not possible using certificates as they would typically require access to a cookie, but the HTTP request is not send via Internet Explorer in this case. The attack allows to access internal hosts, though, so anything where you would not need to see the result is fair game.
Sean Comeau: Do the major browser and mail client developers consider this a threat? Have they or are they planning to fix this?
Alexander Klink: I have been in contact with Microsoft about this issue and they have opened a case for it. They did some testing using an example e-mail I sent them but have otherwise been quite unresponsive, which led to the public disclosure of the issue. Since the disclosure, I haven't had contact with them, so I can't say if they actually consider this a threat.
I have talked to one of the NSS (the Mozilla crypto library) developers, and they are currently in the process of implementing the feature that would lead to the problem (the authorityInformationAccess extension), and I know that they are looking into this - I haven't heard an idea on how to fix this, though.
The problem with fixing this is that they would have to disable a feature that might actually be used by some people, so there is no "easy" way to fix this - one might actually have to think about implementing a GUI for whitelist/blacklists, etc.
Sean Comeau: Is there anything else you can think of that people might need to be advised of regarding X.509 problems?
Alexander Klink: As of today: don't use Debian for your keymaterial. Kidding aside, we're looking at the impact of the recent Debian OpenSSL weak key bug at the moment, let's see who got bitten by that ...
Sean Comeau: Thanks Alexander.
Alexander Klink will speak on the topic of SSL/X.509 bugs in browsers and mail clients at EUSecWest 2008.
