exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Multiple Browser Wildcard Cerficate Validation Weakness

Multiple Browser Wildcard Cerficate Validation Weakness
Posted Aug 28, 2010
Authored by Richard Moore

It appears that many browsers will gladly accept wildcard certificates for IP addresses versus expecting proper domain names for the CN. This is,.. well, very interesting and violates RFC 2818.

tags | advisory
SHA-256 | 469285a2d833d9b4bcd7b10c8a68f5c5ca09223404f03c1675b62b8780642ca2

Multiple Browser Wildcard Cerficate Validation Weakness

Change Mirror Download
Westpoint Security Advisory
---------------------------

Title: Multiple Browser Wildcard Cerficate Validation Weakness
Risk Rating: Low
Author: Richard Moore <rich@westpoint.ltd.uk>
Test Cases: Simon Ward <simon@westpoint.ltd.uk>
Date: 14 July 2010
Advisory ID#: wp-10-0001
URL: http://www.westpoint.ltd.uk/advisories/wp-10-0001.txt
CVE: not yet assigned

Details
-------

RFC 2818 covers the requirements for matching CNs and subjectAltNames
in order to establish valid SSL connections. It first discusses CNs
that are for hostnames, and the rules for wildcards in this case.
The next paragraph in the RFC then discusses CNs that are IP
addresses:

'In some cases, the URI is specified as an IP address rather than a
hostname. In this case, the iPAddress subjectAltName must be present
in the certificate and must exactly match the IP in the URI.'

The intention of the RFC is clearly that you should not be able to use
wildcards with IP addresses (in order to avoid the ability to perform
man-in-the-middle attacks). Unfortunately our testing showed that this
rule is not adhered to by some browsers.

We created a certificate with the CN '*.168.3.48' this meets the various
rules for wildcards in CNs, but should be treated as invalid since it is
not a hostname. We then observed the errors reported by browsers when
connecting to an https server using this certificate run on IP address
192.168.3.48.

We imported the test CA used to sign the certifcate in order to perform
the test.

The results we saw were as follows:

IE6
Regarded the IP address as matching the CN (VULNERABLE)

IE7
Regarded the IP address as matching the CN (VULNERABLE)

Firefox 3.6.6
Regarded the IP address as matching the CN (VULNERABLE)

Chrome
Regarded the IP address as matching the CN (VULNERABLE)

Opera
Reported the IP address did not match the CN (NOT VULNERABLE)

Safari 5 (win32)
Reported the IP address did not match the CN (NOT VULNERABLE)

Qt (4.7 git development branch)
Regarded the IP address as matching the CN (VULNERABLE)

Mitigating Factors
------------------

Obviously a good CA should refuse to issue a certificate with the CN as
indicated, however there only need be one CA to issue one in error for
this issue to result in the user getting no warning at all and being
vulnerable to MITM.

The rules for hostname matching mean that only the first octet of the
IP address can contain a wildcard. This means that you must be able to
control a server that matches the remainder of the IP address of your
target which reduces the risk of this attack being used dramatically.

Impact
------

If exploited then a MITM attack can be performed allowing the guarantees
SSL provides to be circumvented.

Timeline
--------

14 July 2010 Limited disclosure to browser developers.
14 July 2010 Added Safari result.
15 July 2010 Disclosure to official browser security contacts.
15 July 2010 Microsoft confirm receipt.
15 July 2010 Mozilla fix ready.
18 July 2010 Google confirm that Chrome will be fixed by the fix to
NSS on linux, and any fix provided by Microsoft on
Windows. They will therefore not be adding a
work-around to the Chrome code.
4 August 2010 Microsoft confirm the issue will be fixed in a future
service pack, and that the issue is low enough risk
that they are not asking the information to be withheld.
10 August 2010 Patch sent to Nokia for Qt.
27 August 2010 At the time of writing the NSS (Firefox) and Qt
repositories both contain fixes for this issue that
will be included in their releases.

--
Richard Moore, Principal Software Engineer,
Westpoint Ltd,
Albion Wharf, 19 Albion Street, Manchester, M1 5LN, England
Tel: +44 161 237 1028
Fax: +44 161 237 1031
Login or Register to add favorites

File Archive:

June 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    0 Files
  • 2
    Jun 2nd
    0 Files
  • 3
    Jun 3rd
    18 Files
  • 4
    Jun 4th
    21 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    57 Files
  • 7
    Jun 7th
    6 Files
  • 8
    Jun 8th
    0 Files
  • 9
    Jun 9th
    0 Files
  • 10
    Jun 10th
    12 Files
  • 11
    Jun 11th
    27 Files
  • 12
    Jun 12th
    38 Files
  • 13
    Jun 13th
    16 Files
  • 14
    Jun 14th
    14 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    16 Files
  • 18
    Jun 18th
    26 Files
  • 19
    Jun 19th
    15 Files
  • 20
    Jun 20th
    18 Files
  • 21
    Jun 21st
    8 Files
  • 22
    Jun 22nd
    0 Files
  • 23
    Jun 23rd
    0 Files
  • 24
    Jun 24th
    19 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close