Closed Bug 240628 Opened 20 years ago Closed 20 years ago

Problem with showing origin of privilege request


(Core :: Security: CAPS, defect)

Not set





(Reporter: bzbarsky, Assigned: caillon)




(Keywords: fixed1.7)


(1 file)

Caillon, this may be fallout from your nsPrincipal landing.


1)  Load and accept the
    certificate.  Allow it to "identify software makers".
2)  Load jar:!/test.xul

EXPECTED RESULTS: Dialog requesting UniversalXPConnect shows useful site name

ACTUAL RESULTS: Said dialog shows "" as the site name.

I've traced the code that does this.  The relevant code is in 
nsScriptSecurityManager::CheckConfirmDialog where we check whether the principal
has a cert and then call GetCommonName if it does, and GetOrigin otherwise.

Now the problem is that GetCommonName seems to be returning the empty string,
suggesting that nsNSSComponent::VerifySignature was never called or didn't do
the right thing...

Marking critical, since not giving the user an idea of who's requesting
priveleges is totally uncool.
We should figure out the cause of this for 1.7, in my opinion.  The current
situation is unacceptable from a security standpoint.
Flags: blocking1.7?
Summary: Problem with showing origin of privelege request → Problem with showing origin of privilege request
Attached patch FixSplinter Review
OK, NSS is doing the right thing.  But we're cloning a cert, and we're not
doing a very good job of it.  This fixes the bug (as in, I get ""
instead of "").

Caillon, it really would be nice if the GetCertificatePrincipal() required a
common name... people would be a lot less likely to misuse it then, no?
Attachment #146229 - Flags: superreview?(darin)
Attachment #146229 - Flags: review?(caillon)
Comment on attachment 146229 [details] [diff] [review]

patch makes sense to me, but i don't know the caps code that well.

sr=darin assuming caillon is happy.
Attachment #146229 - Flags: superreview?(darin) → superreview+
Hold your horses!  

We don't change mozilla's cert handling every time we come across a cert 
with which it doens't work.  9 times out of 10, the problem is caused by a
cert that doesn't conform to the requirements for a cert for the intended
usage.  In those cases the correct thing is for mozilla to continue to 
expect certs to conform, and for certs that don't conform to be replaced 
with ones that do.  

Nelson, have you read the patch?  The problem is not with cert-handling. The
problem is that the nsIPrincipal object (which is what the browser uses to keep
track of things like permissions) associated with the jar: uri is gotten by
taking the nsIPrincipal associated with the data channel that loaded the jar
(which is the nsIPrincipal that NSS created), cloning it, and replacing the
https: URI in the object with the jar: URI.

The cloning process was implemented incorrectly, though (or made incorrect by
the nsIPrincipal changes that happened a while ago).  It didn't copy over all
the member variables that the principal NSS created had.  In particular, it did
not copy over the member variable that is used as the "for human consumption"
identifier of the issuer of the certificate associated with the principal.

There is absolutely no cert in the world that our current code could possibly
work with, as long as you stick to signed jars served over HTTP.
OK, release the horses!  

Yes, I had read the patch, and was confused by the term "CommonName" in it,
since your previous post had mentioned organization name.

PSM's certificatePrincipal object uses the term "CommonName" to mean the 
object's name string.  The value for it is taken from the underlying cert's
Subject name's Organization attribute.  

But the term "CommonName" is a term of art, referring to an attribute of a 
cert's DistinguishedNames (a.k.a. directoryName), and is defined in an ISO

Now that I know that a principal object's "CommonName" is really the cert's
"Organization" name, I'm ok with this patch.  I'd really like it if the 
principal object's name property could be renamed to something less confusing
like, say, "PrincipalName".  

Thanks for reviewing this with me, Borris.
I've filed bug 240661 on the naming issue.
Attachment #146229 - Flags: review?(caillon) → review+
Comment on attachment 146229 [details] [diff] [review]

Could this please be approved for 1.7?	See comment 0 and comment 1 for the

This change is very safe.
Attachment #146229 - Flags: approval1.7?
Patch checked into trunk.  Now what, if anything, do we want to do to prevent
this happening again?  Could we make the pretty name an arg to
Comment on attachment 146229 [details] [diff] [review]

Shouldn't the real fix be in GetCertificatePrincipal?

GetCertificatePrincipal follows two paths, did you test with and without a URI
passed in?
(In reply to comment #10)
> Shouldn't the real fix be in GetCertificatePrincipal?

That's what I keep asking; see comment 2 and comment 9.  Waiting on the owner of
this code to respond, so far.  For 1.7, though, I think that would be too
dangerous a change at this point.  A localized change to fix this specific
problem is better for the branch, in my opinion.

> GetCertificatePrincipal follows two paths, did you test with and without a URI
> passed in?

The code I changed will _always_ pass in a URI.  But yes, the total pageload on
this page tests both codepaths (first PSM gets a principal without a URI when
verifying the jar signature, then the jar channel gets a principal with a URI
when asked for its owner).
Comment on attachment 146229 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #146229 - Flags: approval1.7? → approval1.7+
Checked in to 1.7.  I think I'll resolve the GetCertificatePrincipal issue in
bug 240661.  It's a pretty scary change that's totally not 1.7 material.
Closed: 20 years ago
Keywords: fixed1.7
Resolution: --- → FIXED
Flags: blocking1.7?
You need to log in before you can comment on or make changes to this bug.