Closed Bug 818014 (CVE-2012-6291) Opened 7 years ago Closed 7 years ago

null byte in document.title allows spoofing window title (e.g. can emulate "Private Browsing")

Categories

(Firefox :: Tabbed Browser, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 22

People

(Reporter: nicolas.derouet, Assigned: Gavin)

Details

(Keywords: sec-low, Whiteboard: UI spoof)

Attachments

(2 files, 3 obsolete files)

Attached file Fun & Fake (obsolete) —
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0
Build ID: 20121128204232

Steps to reproduce:

Browser Title Poisoning Vulnerability with a null byte to the window.document.title.

Tested on: WinXP SP3 // Firefox 17.0.1
UserAgent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20100101 Firefox/17.0


Actual results:

Fake "Browser" and Fake "Private Browsing".
Please see the attachment file


Expected results:

Ignore the null byte
Attachment #688226 - Attachment mime type: text/plain → text/html
The title is no secured area and the real Private browsing is indicated by the changed Firefox button color.

I don't think that this bug is valid but other should decide.
Component: Untriaged → Security
Attached image Private Browsing (normal) (obsolete) —
Attached image Private Browsing (fake) (obsolete) —
The title is no secured area and the real Private browsing is indicated by the changed Firefox button color.

=> No button color on WinXP (please see the screenshots)
I think this boils down to the individual widget implementations passing the value from document.title to functions that take null-terminated strings. All platforms seem to have this problem. Maybe we should just not allow document.title to contain null characters?
Component: Security → DOM
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Browser Title Poisoning - Fake "Private Browsing" → null byte in document.title allows spoofing window title (e.g. can emulate "Private Browsing")
New proof of concept (open in popup) => impact many OS
Attachment #688971 - Attachment description: Proof of Concept with popup (All Plateform) → Proof of Concept with popup (All Platform)
> Maybe we should just not allow document.title to contain null characters?

That would be a spec violation....  The DOM behavior of this getter is pretty clear, and it can contain anything you want, including codepoints that aren't characters at all.
Basically, anything that wants to treat document.title as actual text needs to sanitize it in various ways...
Component: DOM → Tabbed Browser
Product: Core → Firefox
(In reply to Boris Zbarsky (:bz) from comment #9)
> Basically, anything that wants to treat document.title as actual text needs
> to sanitize it in various ways...

The code that can't handle the null byte is the widget SetTitle() implementations. I guess the front-end can filter when it transfers the content document title to the XUL window title, but maybe it'd make sense to have the widget SetTitle() implementations do that instead?
Flags: sec-bounty?
Comment on attachment 688971 [details]
Proof of Concept with popup (All Platform)

<script type='text/javascript'>
function poc()
{
  document.title = 'My WebSite - Mozilla Firefox (Private Browsing)\x00';
  var nav_pb = window.open('about:blank','not_private_browsing','menubar=no, status=no, scrollbars=no, width=400, height=200');  
  nav_pb.document.write("<" + "script>document.title = 'My WebSite - Mozilla Firefox (Private Browsing)\\x00';</" + "script>Not a Private Browsing");
}
</script>
<button onclick="poc()">Proof of Concept</button>
Attachment #688971 - Attachment mime type: text/plain → text/html
CVE-ID: CVE-2012-6291
Some platforms don't show (Private Browsing) in the title bar (Firefox on Win7 doesn't seem to show the title at all!). The point of the null seems to be to chop off the extra "Mozilla Firefox" at the end, but Mac, for instance, doesn't even have that, and you could just make a really long title if you wanted.

What's the value of fooling a user into thinking they're in private browsing mode? Surely they'd remember if they turned it on or not. And if they browse to some other site the spoof goes away.
Alias: CVE-2012-6291
Flags: sec-bounty? → sec-bounty-
Keywords: sec-low
Whiteboard: UI spoof
I still think it would be nice to do this stripping at the widget layer, but here's a front-end patch that should work (haven't tested).
Attachment #688226 - Attachment is obsolete: true
Attachment #688657 - Attachment is obsolete: true
Attachment #688658 - Attachment is obsolete: true
(In reply to Daniel Veditz [:dveditz] from comment #13)
> Some platforms don't show (Private Browsing) in the title bar (Firefox on
> Win7 doesn't seem to show the title at all!).

We show the title in the popup.
Comment on attachment 689905 [details] [diff] [review]
untested front-end patch

Sure, let's go with this.
Attachment #689905 - Flags: review+
Assignee: nobody → gavin.sharp
OS: Windows XP → All
Hardware: x86 → All
Version: 17 Branch → Trunk
https://hg.mozilla.org/mozilla-central/rev/23d42f6e56b4
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Why not just strip null bytes in the toolkit <browser>::contentTitle getter.
(In reply to Gavin Sharp from comment #14)
> I still think it would be nice to do this stripping at the widget layer
Unfortunately the nulls never reach the widget layer because nsIBaseWindow's title is a wstring, not an AString.
(In reply to Philip Chee from comment #19)
> Why not just strip null bytes in the toolkit <browser>::contentTitle getter.

That seems too broadly-scoped for something that is kind of a hack to begin with. I chose to stick the stripping nearest to the specific setting that was problematic (there are other potential uses of contentTitle which aren't susceptible to this particular problem).

Neil points out that I forgot a "g":
https://hg.mozilla.org/integration/mozilla-inbound/rev/73658fed05eb
You need to log in before you can comment on or make changes to this bug.