99422 - serialNumber+derIssuer as certificate database key maybe be dangerous!

Status: RESOLVED DUPLICATE of bug 172247

(NSS :: Libraries, defect, P2)

Description

[liqi]

for example:
      browser accessed two server with same 
serialNumber+derIssuer'scertificate  early or late ,certainly ,one is fake.if 
we enter fake server primatly,we must access good server fault.
      we try change to serialNumber+der(signeddata),but many many plance need 
motify!

Comment 1

[Wan-Teh Chang]

Assigned the bug to Ian.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

NSS is intended for real ecommoerce purposes, meaning it is intended to 
work with real correctly-behaving CAs. A correctly behaving CA will not 
issue two certs with the same serial number and issuer name.  Toy 
home-grown CAs often use the same serial number over and over.  
If NSS doesn't work with certs from toy-CAs, tough.  

Our cert server development group used to run into this problem a lot 
because their individual test servers all used the same issuer name, and 
each test server started with serial number 1.  They eventually started 
using unique issuer names and the problem went away.

There are two potential problems with certs with duplicate issuer/serials
that might warrant fixing, if the problems can be demonstrated.

1. False positive grant of service.  A "fake" cert contains a duplicate
issuer and serial number as a real cert.  The signature on the fake cert
is not verifiable, but because of the duplicated issuer/serial, the real
cert gets substituted for this one, and somehow access is granted when it
should not have been.   It's not immediately apparent, however, how 
that would happen, unless the holder of the fake cert also possessed
the private key that accompanied the good cert.  

2. Denial of service.  You receive a "fake" cert whose issuer/serial 
duplicates that of a known good cert, say as part of an email signature, and 
the fake cert is placed in your perm cert DB (token).  Thereafter, you are
unable to visit a website whose legitimate cert's issuer/SN matches the 
fake cert because the fake cert is always used by NSS instead of the server's
real cert.  

Submittor, Can either of these problems be demonstrated?  If so, how?

Comment 3

[Robert Relyea]

OK, I've taken a look at what is presumably the problem here. The issue is not
with the high level issuer/serial number code, which is pervasive, but only
really used in the case of S/MIME (SSL either looks certs up by the raw DER
cert, or by the Subject of the cert). In this case there isn't an opportunity
for the fake cert server cert to get involved -- only fake CA's, and only if the
user has explicitly loaded them.

It seems like the problem is if you do manage to get two certs different certs
with the same issuer serial number loaded into your database. This can only
happen if you entice the user to load these certificates permanently (getting
the user to click 'trust this cert forever').

So I have two observations: 1) it does not seem to be a security compromise
issue: the security was already compromised the moment the user decided to trust
the fake server. 2) Even though this is the case, it would be good to have a way
of recovering from this error without resorting to scrubbing the whole database
[can the certs be deleted one by one?] 3) fixing the underlying database code is
relatively easy (it's only one function where all the database keys are
generated) but it is not likely we will fix this in a point release of NSS
because it would require a database update.

So liqi, is my characterization of your issue correct?

bob

Comment 4

[liqi]

thanks!
 so,I think what your said is correct.there is security compromise
issue,someone that programming (up level )with nss deal with it and user use 
that maybe discommodiousness,in other words,it is troublesome that deal with 
user's incorrect manipulation .
 in addition,if modify database keys ,this fuction:

CERTCertificate *CERT_CreateCertificate (unsigned long serialNumber, CERTName 
*issuer,	CERTValidity *validity, CERTCertificateRequest *req);
pk11_searchCerts(PK11Slot *slot, CK_ATTRIBUTE *pTemplate, CK_LONG ulCount)
CK_OBJECT_HANDLE pk11_FindObjectByTemplate(PK11SlotInfo *slot,CK_ATTRIBUTE 
*theTemplate,int tsize)
                                liqi

Comment 5

[Robert Relyea]

No, those are the high level functions I was talking about.

The only functions you would modify are those dealing with dbkeys for
certificates (mostly found in pcertdb.c)

Comment 6

[Keyser Sose]

Marking these all WORKSFORME sorry about lack of response but were very
overloaded here. Only reopen the bug if you can reproduce with the following steps:

1) Download the latest nightly (or 0.9.6 which should be out RSN)
2) Create a new profile
3) test the bug again

If it still occurs go ahead and reopen the bug. Again sorry about no response
were quite overloaded here and understaffed.

Comment 7

[Grey Hodge (jX)]

Accidentally marked WFM, correcting

Comment 8

[Boris Zbarsky [:bzbarsky]]

Is there still an issue here?

Comment 9

[Wan-Teh Chang]

Target 4.0, priority P2.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

IMO, in the future, it should be impossible to load a second cert with 
the same issuer+serial into the DB by any means, thereby obviating code
to deal with the problem.

Comment 11

[Wan-Teh Chang]

Changed the QA contact to Bishakha.

Comment 12

[Julien Pierre]

We might want to look at this bug for 3.7 since we are fixing a related import
bug too with duplicate issuer & SN.

Comment 13

[Wan-Teh Chang]

OK, targeting NSS 3.7.

Comment 14

[Robert Relyea]

The real fix for this is not to import a cert with the same issuer/SN if one
cert already exists in the database. Ian has already checked this code into NSS 3.7.

NOTE: we do not want to allow multiple certs with the same issuer/SN to exist in
our system. PKIX disallows this, so the only cases where such certs exist would
be incorrectly configured PKIs and malicious attacks. In both cases we want to
detect and reject these conditions.

bob

Comment 15

[Nelson Bolyard (seldom reads bugmail)]

Bob,  I think you're saying that you believe that the fix for bug 172247 
also addresses the issue in this bug report.  Is that indeed what you're
saying?  If so, please mark this bug as a duplicate of 172247.

Comment 16

[Robert Relyea]

Yup, that's what I'm saying.

Resolved dup

*** This bug has been marked as a duplicate of 172247 ***