Certificate name matching for non-FQDNs is insecure

VERIFIED FIXED in 3.9.2

Status

NSS
Libraries
P1
normal
VERIFIED FIXED
14 years ago
13 years ago

People

(Reporter: Tim Dierks, Assigned: Nelson Bolyard (seldom reads bugmail))

Tracking

({fixed1.4.3, relnote, verified1.7})

3.9.2
fixed1.4.3, relnote, verified1.7
Bug Flags:
blocking1.7 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix] fixed in NSS 3.10 and 3.9.2,fixed-aviary1.0, URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

We were wondering why we don't get cert warnings when going to a site with a
cert for
'blahblah.internal.company.com' with a URL of the form: http://blahblah/file.html :

A colleague found the code:
> Looks like some shadiness in mozilla/security/nss/lib/certdb/certdb.c,
> specifically in cert_TestHostName (hn is the host, cn is the common
> name in the cert):
>
> ------------------
>     if ((hndomain = PORT_Strchr(hn, '.')) == NULL) {
>         /* No domain in URI host name */
>         char * cndomain;
>         if ((cndomain = PORT_Strchr(cn, '.')) != NULL &&
>             (cndomain - cn) > 0) {
>             /* there is a domain in the cn string, so chop it off */
>             *cndomain = '\0';
>         }
>     }
> ------------------
>
> If the URI in the browser isn't fully qualified, it just checks it
> against the first part of the common name. Seems like this is
> intentional, which is weird.

This is a security vulnerability.

An attacker could get a cert issued by Verisign for www.badguys.com and
impersonate www.internal.company.com , assuming some users at company.com have
internal.company.com set as their default search domain and access their site
using the short name 'www'.

IMHO, the right way to do it would to expand the short name being accessed into
a FQDN and compare them. I don't have any idea how to do this in practice; it
might require a browser setting. Unfortunately, my first idea, resolving the
name from the cert and comparing IP addresses, is also insecure: it would just
require the attacker to modify their own DNS record for www.badguys.com to point
to the same ip address as www.internal.company.com.

This bug makes SSL security dependent on DNS security (which is bad).

However, being able to support the desired behavior is good: it's nice for
people to be able to use unqualified names, and the security infrastructure can
(and should) support them. It would be nice if NSS, rather than trimming the
qualification from the CN, added candidate qualifications to the non-qualified
host name until it got a match or ran out of candidates. The hard part is where
to get the candidate qualifications from.

Reproducible: Always
Steps to Reproduce:

Updated

14 years ago
Assignee: wchang0222 → MisterSSL
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 1

14 years ago
Tim, thanks for reporting this in bugzilla.

To eliminate the vulnerability, it is necessary to remove from NSS the code
quoted above.  That will immediately have the effect that https URLs featuring
non-FQDNs will all get host name mismatch errors.

To retain the desired functionality (that is, in order for URLs like
https://www/file.html to continue to work) some code must be added to 
NSS or the application that calls NSS's cert name matching function
(which, in mozilla, is PSM) that:

a) has a copy of the DNS search path for the system on which it is running,
   WITHOUT relying on the DNS protocol/servers for that information, and 
   WITHOUT relying on NIS/YP protocol/servers for that info.

and

b) constructs FQDNs from the simple hostname in the URL and the domain names
   in the DNS search path, and tests them with NSS's host name matching 
   function.  

There is, in general, no way for NSS to find this information.  So either

c) we add a new NSS function that allows the application to give NSS a copy
of the domain search list, and require the application to call it, or

d) we simply let the "application-supplied cert-chain validation callback" 
function do what I described in b above.  

Either way, to retain the desired functionality in mozilla, a change to 
PSM is required, and I suspect that will take longer than the NSS change.

The question I have now, is this:
Should we go ahead and remove the vulnerability now, even if we cannot then
restore the desired functionality for some time thereafter?

I'm adding John G Myers, who is presently working on PSM in his spare (?) 
time, to this list.  John, your thoughts on how to add back the relevant 
functionality to PSM are invited. 
OS: Linux → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → 3.10
Version: unspecified → 3.9
(Reporter)

Comment 2

14 years ago
FWIW, IE doesn't have similar code in it and warns on accessing such a site.
(Assignee)

Comment 3

14 years ago
I'm removing the security sensitive flag, since the text of this bug
has been posted to netscape.public.mozilla.security.  :(
Group: security

Comment 4

14 years ago
Mozilla does DNS lookups through NSPR, so for NSS to get this information NSPR
would have to add a new function for returning the domain search list.  After
that is done, PSM could then call into NSPR to get the information to give to
NSS, or NSS could assume its calling applications have the same search list as
NSPR and directly call into NSPR to get the information.
(Assignee)

Comment 5

14 years ago
John,  

Do most, or any, systems have a standard or common API by which an 
application can fetch the local system's DNS search path?

Is there an API that works on windows 9x, Win2K and WinXP?

And, what about systems that use NIS/YP in host->IP address resolution ?  
How can we simulate the behavior of that in the construction of FQDNs?
(Assignee)

Comment 6

14 years ago
Created attachment 141379 [details] [diff] [review]
proposed patch v1

This patch also removes another non-standard name matching behavior.
The old code treated a simple host name in the cert, e.g. CN=foo.bar.com
as if is also matched [^.]*.foo.bar.com
(Assignee)

Updated

14 years ago
Attachment #141379 - Flags: review?(wchang0222)

Comment 7

14 years ago
Comment on attachment 141379 [details] [diff] [review]
proposed patch v1

r=wtc.

Nelson, I verified that this patch removes the two
non-standard name matching behaviors.  But I'd like to
know whether you plan to implement the safe versions
of the two non-standard name matching behaviors.  If
not, we break backward compatibility.  I just wanted
to make sure that's what you want to do.
Attachment #141379 - Flags: review?(wchang0222) → review+
(Assignee)

Comment 8

14 years ago
In answer to comment 7: 
Yes, I think our first obligation is to remove the vulnerability.
If we are able to reinstate the desired behavior in a non-vulnerable way at
some point, then that is fine, but I am not convinced there is such a way
in general, especially in the presence of NIS.  
I would not delay ther removal of the vulnerability while we look for a 
non-vulnerable way to reinstate the desired behavior.

Comment 9

14 years ago
Thanks, Nelson.

Just curious: what is the second non-standard name matching
behavior (the one you described in comment 6) useful for?
(Assignee)

Comment 10

14 years ago
It allowed a company to get one cert that matched all servers in their 
outermost domain, e.g. one cert that said (e.g.) CN=netscape.com 
could be used on www.netscape.com, imaps.netscape.com, 
secnews.netscape.com, etc.

Comment 11

14 years ago
...which was made necessary because CAs historically charged extortionate rates
for wildcard CAs.  The "subdomains not allowed" restriction generally benefits
CAs, not server operators or end users.  The restriction requires domaines to
buy more certs from the CA.  I don't know if competition in CAs has changed this
much.

There could conceivably be a domain where the top-level web server has lower
security requirements than some subdomain, but this is a stretch.

Comment 12

14 years ago
"for wildcard CAs" should be "for wildcard certs"

Comment 13

14 years ago
Is the second non-standard name matching behavior
a security vulnerability, too?  It seems that its
security risk is the same as that of wildcard certs.
(Assignee)

Comment 14

14 years ago
This behavior turns ANY single-named-server cert into a subdomain server cert.  
E.g. if you have a cert that names, e.g. CN=www.domain.TLD, then it may be used
with *.www.domain.TLD.  

The security risk is certainly very similar as that of wildcard certs.
Any additional risk comes about because the wildcard is invisible,
and thus unlikly to be spotted by the vigilant user or admin.

John, do you think we should preserve this behavior?  (I don't).

Comment 15

14 years ago
I consider the second nonstandard name matching behavior to be an acceptable
risk/benefit tradeoff.  I may well be overestimating the benefit, though.
(Assignee)

Comment 16

14 years ago
These two features go back to at least the Netscape Navigator 3.x sources.
They may have made sense way back then. 

I think today this second feature has no real benefit.  Today mozilla and
browsers derived from it are "alternative" products, and no enterprise will
setup its business infrastucture to depend on features that are not found 
in IE.  I am told that neither of these features is in IE, so I think it's
time to drop 'em.  I surely don't want to be asked to defend them ever again.


(Assignee)

Comment 17

14 years ago
Patch checked in.  

/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.65; previous revision: 1.64

fix will be in NSS 3.10.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Comment 18

14 years ago
Created attachment 145667 [details] [diff] [review]
supplemental patch for ssl.sh QA test script

The ssl.sh qa test script and the ecc SSL test script (ecssl.sh) were both
dependent on the old behavior.	This patch changes them to always use FQDNs.
(Assignee)

Comment 19

14 years ago
test scripts checked in.  

/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.2; previous revision: 1.1

/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.56; previous revision: 1.55

Comment 20

14 years ago
As our backward compatibility tests correctly shown,
this fix broke backward compatibility.  Since this bug
is a security vulnerability we can break backward
compatibility to fix it but we need to remember to
document this in the NSS 3.10 release notes.

We should update the ssl.sh QA test script used in
our backward compatibility tests so that they pass.
Bishakha, could you take care of this?
Keywords: relnote
(Assignee)

Comment 21

14 years ago
I'm beginning to think that our QA script named "all.sh" should be renamed 
to "lessthanall.sh".  I continue to desire that the checked-in QA scripts
used by developers be ALL-inclusive, so that they accurately predict the
outcome of nightly QA testing.  

Comment 22

14 years ago
Comment on attachment 145667 [details] [diff] [review]
supplemental patch for ssl.sh QA test script

To backport this patch to older NSS branches (to
which this patch cannot be applied cleanly), you
just need to edit ssl.sh (and ecssl.sh, if it exists)
and make sure that the argument to the -h option of
all tstclnt commands (including those in the echo
commands) is ${HOSTADDR} instead of ${HOST}.
Whiteboard: [sg:needinfo] fixed in NSS 3.10
Flags: blocking1.7?
Whiteboard: [sg:needinfo] fixed in NSS 3.10 → [sg:fix] fixed in NSS 3.10

Comment 23

13 years ago
wtc,  do you know if the mozilla 1.7 branch has this fix/NSS 3.10?
I talked to Nelson earlier, it is not fixed in the 3.9.1 that the mozilla 1.7
branch is using.

Comment 25

13 years ago
Chris, the Mozilla 1.7 branch doesn't have this fix.
I'll be happy to check it in if you invite me to join
the gmail beta club.

Julien, I'll need to check this fix in on the NSS 3.9
branch as well.  This fix breaks backward compatibility,
so you need to tell your NSS 3.9.2 customers to watch
out for this.
(Assignee)

Comment 26

13 years ago
This bug fix requires that https URLs always contain FQDNs.  

That's not going to be a problem for public Internet use (e.g. banks, merchants),
but could be a BIG problem for "intranet" (corporate) users who often tend 
to be sloppy and use simple hostnames in their web page links.  

Previously, it was decided not to impose this change, with its potential
incompatibility, on moz users at the very last minute before moz 1.7 RTM.

mozilla.org is free to change its mind about that, but should do so with its
eyes wide open to the potential consequences.
doesn't comment 16 indicate that such links would not work in IE, anyway?

Comment 28

13 years ago
Wan-Teh, we already recommended to our customers to use wildcard certs or
multiple hostnames in the cert. I don't think we ever documented the behavior
that is being corrected here. So it shouldn't be a problem hopefully. Since we
are doing a 3.9.2 beta drop to our internal customers in the next couple days,
it would be good if this got checked in before so we are certain it didn't break
anything before the 3.9.2 rtm later this month.

Comment 29

13 years ago
I checked in the two patches on the NSS_3_9_BRANCH
(NSS 3.9.2).

mozilla.org drivers: please set the approval1.7+
flags on the two patches if you'd like me to check
them in on the MOZILLA_1_7_BRANCH.

Checking in lib/certdb/certdb.c;
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.61.2.3; previous revision: 1.61.2.2
done
Checking in tests/ssl/ecssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.1.18.1; previous revision: 1.1
done
Checking in tests/ssl/ssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.55.16.1; previous revision: 1.55
done
Target Milestone: 3.10 → 3.9.2
Comment on attachment 141379 [details] [diff] [review]
proposed patch v1

a=dveditz for 1.7
Attachment #141379 - Flags: approval1.7+
Comment on attachment 145667 [details] [diff] [review]
supplemental patch for ssl.sh QA test script

a=dveditz for 1.7
Attachment #145667 - Flags: approval1.7+
And we'll want it on the AVIARY_1_0_20040515_BRANCH.
Whiteboard: [sg:fix] fixed in NSS 3.10 → [sg:fix] fixed in NSS 3.10 and 3.9.2

Comment 33

13 years ago
I checked in the patches on the MOZILLA_1_7_BRANCH
for Mozilla 1.7.

Checking in lib/certdb/certdb.c;
/cvsroot/mozilla/security/nss/lib/certdb/certdb.c,v  <--  certdb.c
new revision: 1.61.4.1; previous revision: 1.61
done
Checking in tests/ssl/ecssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ecssl.sh,v  <--  ecssl.sh
new revision: 1.1.20.1; previous revision: 1.1
done
Checking in tests/ssl/ssl.sh;
/cvsroot/mozilla/security/nss/tests/ssl/ssl.sh,v  <--  ssl.sh
new revision: 1.55.18.1; previous revision: 1.55
done

Updated

13 years ago
Keywords: fixed1.7

Updated

13 years ago
Whiteboard: [sg:fix] fixed in NSS 3.10 and 3.9.2 → [sg:fix] fixed in NSS 3.10 and 3.9.2 needed-aviary1.0
Flags: blocking1.7? → blocking1.7+

Updated

13 years ago
Whiteboard: [sg:fix] fixed in NSS 3.10 and 3.9.2 needed-aviary1.0 → [sg:fix] fixed in NSS 3.10 and 3.9.2,fixed-aviary1.0
Adding Jon Granrose to CC list to help round up QA resources for verification

Comment 35

13 years ago
adding dave to verify on 1.7

Comment 36

13 years ago
I need a test case with steps to verify against the 1.7 branch. Does the fix
prevent some spoofing scenarios?

Comment 37

13 years ago
I verified this fix using Mozilla 1.7 on Windows.

My test case is aka.mcom.com, an internal server
at AOL's Mountain View network.  I can no longer
get there using the URL https://aka/ without
triggering the "Security Error: Domain Name Mismatch"
dialog.
Status: RESOLVED → VERIFIED

Comment 38

13 years ago
ok thanks. Verified on 1.7 branch. 
Keywords: fixed1.7 → verified1.7
Applied both patches on the 1.4.3 branch
Keywords: fixed1.4.3

Comment 40

13 years ago
Note: The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2004-0765 to this issue.
You need to log in before you can comment on or make changes to this bug.