294689 - document.cookie=null in circumstances involving signed.applets.codebase_principal_support

Status: RESOLVED FIXED

(Core :: Security: CAPS, defect)

Description

[Izaak B.]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

when signed.applets.codebase_principal_support is true,
document.cookie returns null in whatever domains the user has told firefox to
'remember' special privileges. however, the cookies are still sent to the web
server.


Reproducible: Always

Steps to Reproduce:
1. set 'signed.applets.codebase_principal_support' to 'true'
2. go to a domain that uses netscape.security.PrivilegeManager
3. ask firefox to 'remember' gained privileges
4. quit firefox and come back to the same domain

Actual Results:  
document.cookie always returns null in given domain

Expected Results:  
document.cookie should return cookies

Comment 1

[Izaak B.]

so far i've tested this in linux and mac os x.

Comment 2

[djpohly]

-> Cookies

Comment 3

[Boris Zbarsky [:bzbarsky]]

Worksforme on trunk....  Izaak, do you see this in a trunk build?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Never mind.  I've reproduced this.  The problem is that cookies (or more
precisely nsHTMLDocument::GetCookie) uses the URI in the principal as the URI
it's working with, and if you look at
nsScriptSecurityManager::GetCodebasePrincipal in the case when the principal
comes from the table we end up with a wrong URI (one that has no path on it, so
cookies fails the path security check and gives back no cookie).

So either cookies needs to use a different URI or the security manager needs to
always preserve the path in the codebase principal instead of sometimes
preserving it and sometimes not.  In fact, the latter should be fixed no matter
what; if we decide to never preserve the path instead, then we'll need to fix
GetCookie (and possibly other things) too.

Comment 5

[Boris Zbarsky [:bzbarsky]]

I think we should try to deal with this for 1.8; I'm not quite sure I can
exploit this yet, but I'll try to find a way.

Comment 6

[Daniel Veditz [:dveditz]]

principals are things we pass around for caps as a hook to the security policy
for that entity, they're really supposed to be mostly opaque to everyone else
(they're explicitly non-scriptable to keep unsavvy chrome author's hands off it).

Unfortunately having the codebase there is convenient, I bet there are a lot of
places that take advantage of this :-(

Comment 7

[Corinne Bordelon]

Doesn't appear to be a serious security issue - no known exploit.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Note that we need the codebase here for jar: channels, since using the document
URI there would be wrong.

Also note that the codebase is always "right" (includes path) for cert
principals; I just propose that codebase principals work the same way, cloning
the in-table cert as needed.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Note that we also use GetURI as the referrer in some cases...

Comment 10

[Boris Zbarsky [:bzbarsky]]

One other reason to fix this -- various callers modify principals (eg SetDomain, some do SetURI, etc).  So we _really_ don't want to be sharing a principal between two different documents.  Which is where we are right now...

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 269270.