<!DOCTYPE> ignores contentaccessible, leaks DTD strings and therefore browser UI locale




10 years ago
3 months ago


(Reporter: neil, Unassigned)


(Depends on: 1 bug, Blocks: 1 bug, {sec-low, testcase})

sec-low, testcase
Dependency tree / graph
Bug Flags:
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:low], URL)


(1 attachment)



10 years ago
A webpage can include an invisible <iframe> whose source tries to read an entity from an extension's locale. This could be used to determine whether a particular extension is installed. The chrome package does not need to be marked as contentaccessible for this information leak to occur. The URL demonstrates reading an entity from the mozapps package which should not be contentaccessible.

Comment 1

10 years ago
[sg:low] -- disclosure of information that is unlikely to be sensitive.  (But strings from a private extension could be confidential.)
Whiteboard: [sg:low]
Flags: wanted1.9.0.x+
Comment hidden (obsolete)
Comment hidden (obsolete)
(In reply to Jonas Sicking (:sicking) No longer reading bugmail consistently from comment #2)
> Does this still work? We've added a bunch of restrictions to chrome URLs
> since 2008 and the attached URL renders blank for me.

Yes, the testcase was supposed to render blank, the <title> is what was important.

(In reply to RNicoletto from comment #3)
> Is there any testcase URL in order to verify this?

It's in the URL field but didn't explain what was expected. I'll attach a better test case.
Keywords: testcase
Summary: <!DOCTYPE> ignores contentaccessible, leaks information about installed extensions → <!DOCTYPE> ignores contentaccessible, leaks DTD strings and therefore browser UI locale
Created attachment 8961207 [details]
Test case showing the &homepage.label; UI string

I confirmed that I get the French string in a French build even with privacy.resistFingerprinting=true:

> A string from your language: Visiter la page web
At first glance, knowing nothing about this code, I would guess this can be fixed in nsExpatDriver::OpenInputStreamFromExternalDTD to not allow web content to use DTDs. Some resource URIs do want at least global.dtd though so I think we would need an exception for some internal pages depending on flags…

Looks like we tried to close this hole in bug 1182546 but then had to revert it in bug 1228116 due to addon-compat.

Looks like we would start with reverting https://hg.mozilla.org/mozilla-central/rev/7ace0805c2d3 and the test commit but would also want to plug the leak for even contentaccessible DTD to get rid of all locale fingerprinting options.
You need to log in before you can comment on or make changes to this bug.