Mozilla Firefox subjectAltName:dNSName Attribute Validation Flaw Lets Remote Users Spoof Certificates
|
|
SecurityTracker Alert ID: 1018979 |
|
SecurityTracker URL: http://securitytracker.com/id/1018979
|
|
CVE Reference:
CVE-2007-6590
(Links to External Site)
|
Updated: Jan 4 2008
|
Original Entry Date: Nov 19 2007
|
Impact:
Modification of authentication information
|
Exploit Included: Yes
|
Version(s): 2.0.0.9 and prior versions
|
Description:
A vulnerability was reported in Mozilla Firefox. A remote user can spoof certificates using domain wildcards.
A remote user can create a certificate with a specially crafted 'subjectAltName:dNSName' attribute that uses wildcard patterns in the attribute value. If the target user accepts the certificate as valid (when presented with the unknown Certificate Authority warning), the browser will consider the certificate to be valid for the hostnames specified in the 'subjectAltName:dNSName' attributes.
Nils Toedtmann reported this vulnerability.
The original advisory is available at:
http://nils.toedtmann.net/pub/subjectAltName.txt
|
Impact:
A remote user can spoof certificates in certain cases.
|
Solution:
No solution was available at the time of this entry.
|
Vendor URL: www.mozilla.org/ (Links to External Site)
|
Cause:
Authentication error
|
Underlying OS:
Linux (Any), UNIX (Any), Windows (Any)
|
|
Message History:
None.
|
Source Message Contents
|
Date: Sun, 18 Nov 2007 22:21:18 +0100
Subject: [Full-disclosure] Certificate spoofing issue with Mozilla, Konqueror,
|
Moin *
Mozilla based browsers (Firefox, Netscape, ...), Konqueror and Safari 2
do not bind a user-approved webserver certificate to the originating
domain name. This makes the user vulnerable to certificate spoofing by
"subjectAltName:dNSName" extensions.
I set up a demonstration at <http://test.eonis.net/>, check it out. For
details (vulnerable versions, vendor status, bug ids ...) see
<http://nils.toedtmann.net/pub/subjectAltName.txt>
Attack scenario:
(1) Assumed a phisher could redirect a user's browser to his prepared
https webserver spoofing "www.paypal.com" (by DNS spoofing or domain
hijacking or other MITM attack). But the user's browser would raise
an "unknown CA" warning because the phisher does not have a
certificate for "www.paypal.com" issued by a browser-trusted CA
(that's what X.509 and TLS is all about!). Thus, the phisher defers
this step.
(2) The phisher creates another website "www.example.com" (not spoofed)
and a home brewed X.509 cert:
DN="CN=www.example.com"
subjectAltName:dNSName=www.example.com
subjectAltName:dNSName=www.paypal.com
and lures the user to https://www.example.com/. The user gets an
"unknown CA" warning, but the "subjectAltName:dNSName" extensions
are not shown to him, so the cert looks ok. As he does not plan to
enter any private information, he accepts it (temporarily or
permanently) and proceeds.
(3) Any time later (if the cert got accepted temporarily this has to
happen within the same session), the phisher lures the user to his
spoofed https://www.paypal.com/, using the very same self-signed
certificate - NO WARNING!
In the end, the cert warning and the spoofing attempt get separated into
two events which appear to the user as being unrelated. I consider this
a severe cert-spoofing issue, aggravated by the fact that affected
browsers also match any hostname with "subjectAltName:dNSName=*".
For Mozilla, this issue is known for more than three years without being
fixed.
Regards, /nils.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
|
|
