Closed Bug 234058 Opened 16 years ago Closed 16 years ago

Certificate name matching for non-FQDNs is insecure

Categories

(NSS :: Libraries, defect, P1)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: tim, Assigned: nelson)

References

()

Details

(Keywords: fixed1.4.3, relnote, verified1.7, Whiteboard: [sg:fix] fixed in NSS 3.10 and 3.9.2,fixed-aviary1.0)

Attachments

(2 files)

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:
Assignee: wchang0222 → MisterSSL
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
FWIW, IE doesn't have similar code in it and warns on accessing such a site.
I'm removing the security sensitive flag, since the text of this bug
has been posted to netscape.public.mozilla.security.  :(
Group: security
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.
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?
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
Attachment #141379 - Flags: review?(wchang0222)
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+
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.
Thanks, Nelson.

Just curious: what is the second non-standard name matching
behavior (the one you described in comment 6) useful for?
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.
...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.
"for wildcard CAs" should be "for wildcard certs"
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.
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).
I consider the second nonstandard name matching behavior to be an acceptable
risk/benefit tradeoff.  I may well be overestimating the benefit, though.
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.


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
Closed: 16 years ago
Resolution: --- → FIXED
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.
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
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
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 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
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.
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.
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?
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.
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
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
Keywords: fixed1.7
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+
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
adding dave to verify on 1.7
I need a test case with steps to verify against the 1.7 branch. Does the fix
prevent some spoofing scenarios?
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
ok thanks. Verified on 1.7 branch. 
Keywords: fixed1.7verified1.7
Applied both patches on the 1.4.3 branch
Keywords: fixed1.4.3
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.