Closed Bug 310119 Opened 19 years ago Closed 19 years ago

firefox has intermediate signing authority vulnerability

Categories

(NSS :: Libraries, defect)

Product:
NSS
Component:
Libraries
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: b.degeeter, Assigned: wtc)

Details

(Whiteboard: [sg:needinfo]) 

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

It appears firefox is susceptible to the intermediate signing authority
vulnerability as describe in CAN-2002-0862.

http://nvd.nist.gov/nvd.cfm?cvename=CAN-2002-0862

If you configure a web server to advertise an ssl certificate and chain, Firefox
ignores the purpose of the intermediate certificates.  This will allow an
attacker to spoof a trusted web site.


Reproducible: Always

Steps to Reproduce:
1. Configure apache with 
SSLCertificateFile /etc/httpd/conf/ssl.crt/https-chain.dig.net.crt
SSLCertificateKeyFile /etc/httpd/conf/ssl.key/https-chain.dig.net.key
SSLCertificateChainFile /etc/httpd/conf/ssl.crt/mustard-chain.dig.net.crt

2. Ensure ChainFile is configure without proper purpose:
[root@zeppo ssl]# openssl x509 -in /root/ssl/mustard-chain.dig.net.crt -purpose
Certificate purposes:
SSL client : Yes
SSL client CA : No
SSL server : Yes
SSL server CA : No
Netscape SSL server : Yes
Netscape SSL server CA : No
S/MIME signing : Yes
S/MIME signing CA : No
S/MIME encryption : Yes
S/MIME encryption CA : No
CRL signing : Yes
CRL signing CA : No
Any Purpose : Yes
Any Purpose CA : Yes
OCSP helper : Yes
OCSP helper CA : No

  

Actual Results:  
IE will not allow you to trust the site,  Firefox will.

Expected Results:  
Firefox should not trust the site.
Assignee: nobody → wtchang
Component: Security → Libraries
Product: Firefox → NSS
QA Contact: firefox → jason.m.reid
I remember this vulnerability.  It was a big deal.
We even constructed an S/MIME test case for Outlook.
We didn't find the same bugs in NSS.

Brian: could you elaborate on how Firefox allows
you to trust the SSL site?  Does it report that
something is wrong with the SSL server cert, but
still give you the option to trust the server (just
for the session or permanently)?  Do you have a web
server that we can test with?
Hi Brian,
Could you attach the chain which Firefox incorrectly trusts>

The CAN-2002-0862 listed in this bug is about trusting certs which does not have
Basic Constraints set to indidicate that the cert is a CA. NSS (and products
that use NSS) have checked the Basic Constraints or Netscape equivalence since
they started handling certificate chains.

Back in 2002, when this bug surfaced, we verified the NSS did indeed properly
check these extensions before chaining trust to an intermediate certificate. I'd
be highly surprised if that has changes, but it's worth another look.

If you could attach the certificates, we can verify if there has been a regression.

Thanks,

bob
Whiteboard: [sg:needinfo]
First off, let me state that I hope I’m wrong about this.  I test Big-IP, a
product by F5 Networks, which does ssl termination for web servers.  I’ve been
working with a developer on an issue which we though to be in our ssl stack. 
I’m seeing different behaviors between IE, Firefox, and openssl s_client.

It turns out there is a bit more to the issue than I originally described.  I’ve
got a number of different web servers configured with a chain files and certs.

If I connect to one address which has the cert and chain configured, Firefox
prompts me with the “Web site Certified by and Unknown Authority”.  I accept
this cert temporarily for this session.  Now any tab or new Firefox process I
start up will allow me to connect to my original address or any other IP address
configured with a web server with the same chain/cert.

Originally I didn’t report that I accepted the cert temporary, because I didn’t
realize I had.  I’ve probably been running an instance of firefox started from a
previous instance for weeks now.  Maybe I just don’t understand how you define a
session, but however you look at it IE 6 doesn’t even let me connect to a web
server configure this way.

I need to sign off for the evening, but if you let me know where to send them I
can get to copies of my certs tonight.  It appears the chains I’ve been using
are lacking the v3 extensions, which may also be part of the problem. 
It’probably worth taking a look at them.

Cheers,

-Brian
> Now any tab or new Firefox process I start up will allow me to connect

I think you're assuming that each firefox window is a process, and that 
isn't so.  When you accept a cert "temporarily for this session", it 
means for the lifetime of the process.  It will remain trusted in that 
process (and only in that process) until that process is terminated.  
If you open another FF window while that process is alive, odds are good 
that the new window is simply another window in the same FF process.  

So, based on what I've read here, it doesn't seem like there is any bug,
just a misunderstanding of the relationship between windows and processes,
and perhaps of the definition of a "session" as that term is used in that
particular dialog.  

I agree that that dialog could use some clarification of what it means to
accept a certificate, and what "this session" means.  When you "accept"
an SSL server certificate whose validity could not be determined by 
verifying its signature from a known and trusted CA, you actually choose to
trust that SSL server certificate as if it had been issued by a CA that you 
trust (for SSL server purposes).  You trust it for all the DNSnames that
it bears, just as you would if it had really been issued by a trusted CA.
I'm going to keep investigating a little bit.  I still don't understand why IE
and Firefox behave so differently when it comes to this.  Maybe the problem is
with IE?  I put up a site that has the chain, if you're interested. 
https://hiddenhouse.net.  Here's the root CA:

-----BEGIN CERTIFICATE-----
MIICpjCCAg+gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBmDELMAkGA1UEBhMCVVMx
CzAJBgNVBAgTAldBMRAwDgYDVQQHEwdTZWF0dGxlMRAwDgYDVQQKEwdGNSBUZXN0
MRwwGgYDVQQLExNCcmlhbnMgVGVzdCBSb290IENBMRgwFgYDVQQDEw9tdXN0YXJk
LmRldi5uZXQxIDAeBgkqhkiG9w0BCQEWEWIuZGVnZWV0ZXJAZjUuY29tMB4XDTA0
MDcxNTE4NTczNVoXDTA2MDcxNTE4NTczNVowgZgxCzAJBgNVBAYTAlVTMQswCQYD
VQQIEwJXQTEQMA4GA1UEBxMHU2VhdHRsZTEQMA4GA1UEChMHRjUgVGVzdDEcMBoG
A1UECxMTQnJpYW5zIFRlc3QgUm9vdCBDQTEYMBYGA1UEAxMPbXVzdGFyZC5kZXYu
bmV0MSAwHgYJKoZIhvcNAQkBFhFiLmRlZ2VldGVyQGY1LmNvbTCBnzANBgkqhkiG
9w0BAQEFAAOBjQAwgYkCgYEAnSD55dacn3EEihCarmFtJxofQpH33Wczq84nd8Us
B1P1DnswGzMy8SC/tCxJ7qxSn3wqVqiyMXN5JnjC4e0H/PYro0U+9HYI4qeVxYnI
bQOxXFXs1SJyAjBHBk/h5rUm3oWRJFnaR0O/2Ever0gC387lhcyCMInCR8qJIPyE
Xh0CAwEAATANBgkqhkiG9w0BAQQFAAOBgQA2q3jHmSFR5Mgzk2YMZc+AHtkcLSLn
zwUXXwRZYX8IaDTrF0n5J6zgPk6WEnm8dSt8l8PoUZFuihj9AwGb5js6VHUvVOsd
5oGRq+2Y1ho/xAPX5JwgWbZqJ/oSJ/1tr5kMlLkV3LkgqYBYs+WSSvVzWa3gbKmO
9fQUigMxRxp4XQ==
-----END CERTIFICATE-----

Brian,

The root CA you attached does not match the certificate at
https://hiddenhouse.net . The server cert has an issuer of 

"E=b.degeeter@f5.com,CN=chain-two.dig.net,OU=Chain Two,O=F5
Test,L=Seattle,ST=WA,C=US"

The root CA you attached has a subject of :

"E=b.degeeter@f5.com,CN=mustard.dev.net,OU=Brians Test Root CA,O=F5
Test,L=Seattle,ST=WA,C=US"

Please provide a complete cert chain. 

The web server is sending the chain.  You can get all other certs with s_client:

[root@zeppo root]#  printf "GET / HTTP/1.1\r\nAccept-Encoding: gzip,
deflate\r\nHost: yadda\r\nConnection: close\r\n\r\n" |
/root/openssl97g/openssl-0.9.7g/apps/openssl s_client -ign_eof -connect
hiddenhouse.net:443  -CAfile /root/ssl/mustard.dev.net.crt -showcerts

Sorry, I was only displaying the cert at which the NSS cert verification failed,
using the vfyserv tool.

My debugging session shows that the server is sending 3 certs, in the following
order :

Connecting to host hiddenhouse.net (addr 24.19.40.13) on port 443
t@2 (l@2) stopped in nssDecodedPKIXCertificate_Create at line 470 in file
"pki3hack.c"
  470       if (cert) {
cert->subjectName = 0x80c26a8
"E=b.degeeter@f5.com,CN=https-chain.dig.net,OU=Test,O=F5
Networks,L=Seattle,ST=WA,C=US"
cert->issuerName = 0x80c2700 "E=b.degeeter@f5.com,CN=chain-two.dig.net,OU=Chain
Two,O=F5 Test,L=Seattle,ST=WA,C=US"
(dbx) c
t@2 (l@2) stopped in nssDecodedPKIXCertificate_Create at line 470 in file
"pki3hack.c"
  470       if (cert) {
cert->subjectName = 0x80c53f8 "E=b.degeeter@f5.com,CN=chain-one.dig.net,OU=Chain
One,O=F5 Test,L=Seattle,ST=WA,C=US"
cert->issuerName = 0x80c5450 "E=b.degeeter@f5.com,CN=mustard.dev.net,OU=Brians
Test Root CA,O=F5 Test,L=Seattle,ST=WA,C=US"
(dbx) c
t@2 (l@2) stopped in nssDecodedPKIXCertificate_Create at line 470 in file
"pki3hack.c"
  470       if (cert) {
cert->subjectName = 0x80c7f58 "E=b.degeeter@f5.com,CN=chain-two.dig.net,OU=Chain
Two,O=F5 Test,L=Seattle,ST=WA,C=US"
cert->issuerName = 0x80c7fb0 "E=b.degeeter@f5.com,CN=chain-one.dig.net,OU=Chain
One,O=F5 Test,L=Seattle,ST=WA,C=US"

So the chain is 
https-chain.dig.net -> chain-two.dig.net -> chain-one.dig.net -> mustard.dev.net .
But at this point our verification algorithm cannot match the chain-one as the
issuer for chain-two . I have more debugging to do to figure out why that is.

The verification fails because chain-two fails the CERT_IsCACert test.
The reason is that this cert is not trusted, doesn't have the Netscape cert type
extension, and doesn't have the basic constraints extension.

The cert was not trusted . It seems to me there is no vulnerability here. Do you
agree ?

I Agree.  The fact that IE is just more aggressively denying the connection does
not make this vulnerability.

I appreciate everyone looking into it.

Julien: the bug is in the different ways IE and Firefox
respond to this SSL server cert chain.

After you have imported the root CA cert (see comment 5)
into Firefox and your Windows system cert store, IE displays
an error page "Cannot find server: The page cannot be displayed"
when connecting to https://hiddenhouse.net, but Firefox
pops up the "Web Site Certified by an Unknown Authority"
dialog, which allows you to connect to the web site anyway.
I believe Firefox's action is because NSS or PSM considers the
server's cert chain as stopping at the server cert (because NSS
doesn't chain it to chain-two.dig.net, which is not a CA), so
it becomes indistinguishable from a misconfigured SSL server
that only sends us its server cert.

One thing we could do is to set a certain error code when we
detect that the issuer of a cert is not a CA, and do not give
the user an option to connect to the server if we get that
error code.  I'm not sure if this can be done easily in NSS.

Brian: could you generate a new SSL server cert whose Common
Name matches the hostname in the URL?  The current cert's
Common Name is https-chain.dig.net, but the hostname in the
URL is hiddenhouse.net.
I put a new cert out on https://hiddenhouse.net.  I had to replace the entire
chain.  It seems I lost one of the keys I needed to make sign a new cert.  
Brian, could you paste the new root CA cert (rootCA.dig.net)?
Thanks.

Wan-Teh, are you saying we should treat chaining to a non-root cert different
than chaining to an untrusted or no root cert?

On the one hand I don't know how chaining to a non-root cert could ever happen
by accident, so it looks like it's clearly an attack (plus on for not giving the
user an option to continue).

On the other hand, the same attack could be carried out by removing the non-root
cert and letting the dialog happen, so we aren't preventing any attacks which
dup the user into clicking 'OK' in the box.

bob
My bad.  I based the new chain on the wrong CA.  I've set it up with
mustard.dev.net as the CA.
Bob, I am saying that we should treat chaining to a non-CA
cert different than chaining to an untrusted or no CA cert.
(Note that I changed "root" to "CA" when I interpreted your
comment 14.)

The reason is that NSS has the cert chain but in the
"Web Site Certified by an Unknown Authority" dialog, that
information is thrown away; if you click on the
"Examine Certificate..." button in the dialog, only the
server cert is shown in the Certificate Hierarchy box.
It seems that we should do something different given the
additional information.

But you are right that this doesn't prevent any attacks which
dupe the user into clicking "OK" in the dialog.
I think it has nwo been clearly established that there is no security
vulnerability here, and that this bug is invalid.  In that case,
the security sensitive flag should be removed and the bug marked invalid.
Wan-Teh, if you agree, please make those changes to this bug.
Regarding the idea of chaining to a non-CA cert, IIRC, in the Stan code,
we changed the implementation of the function that finds a cert's issuer
to collect all the certs that meet the selection criteria (e.g. have a 
subject name matching our issuer name, have the right subject key ID 
if the issued cert has an authority key ID, and is a CA cert.  Then we
pick the "best" one from that list.  In the case where the intended 
cert is not marked as a CA cert, it doesn't get included in that list
of potential candidate issuer certs.  In order to be able to "chain to 
a non-CA cert", we'd have to put non-CA certs into the list of potential
issuers.  And IMO that's a bad idea.  

I think we're right to say that we did not find the issuer cert.  
A non-CA cert cannot be an issuer, and we are right not to chain to it.

Now having said that, there is another school of thought that says that
we should take the list of certs we receive from the server, and use it
as is for the chain.  In that paradigm, we do not have to search for 
the issuer of each cert in the chain, do not have to reconstruct the 
chain, because the (partial) chain was given to us, and all we need to do
is follow it (as far as it goes).  IFF we were to change NSS's cert chain
validating algorithm to work that way, then it might make sense to 
"chain to a non-CA cert", if the next cert in the chain was a non-CA cert.
But we'd have to be very careful not to repeat IE's mistake.  
Marked the bug invalid.
Group: security
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Target Milestone: --- → 3.11
You need to log in before you can comment on or make changes to this bug.