The default bug view has changed. See this FAQ.
Bug 425046 (CVE-2008-5508)

URLs containing 0x01 are interpreted very oddly - possible overflow bug?

RESOLVED FIXED

Status

()

Core
Networking
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: Chip Salzenberg, Unassigned)

Tracking

({fixed1.9.1, verified1.8.1.19, verified1.9.0.5})

unspecified
x86
Linux
fixed1.9.1, verified1.8.1.19, verified1.9.0.5
Points:
---
Bug Flags:
wanted1.9.0.x +
wanted1.8.1.x +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:investigate])

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2)

This tag:
    <a href=&#1;http://yahoo.com/space&#32;space&#32;here>linky</a>
genrates this link text:
    htt:///yahoo.co/m/space%20space%20her
there's a ^A at the beginning of that, if you can't see it here.

What is wrong with this?  Let me count the ways:

    htt: instead of http:
    three slashes instead of two before "yahoo"
    slash in the middle of "com"
    missing "e" at the very end

I'm a C programmer and this smells like the kind of result that could spring from a potential buffer overflow bug.  However I have no evidence that an overflow is actually happening.  I tag this bug "Security" out of caution.

BTW this link works in Outlook - not that I would suggest for a second that you imitate Outlook!  But that's why I was testing it.

Reproducible: Always

Steps to Reproduce:
1. Paste the above link tag into HTML
2. View it
3. "Copy link location" from link
Actual Results:  
htt:///yahoo.co/m/space%20space%20her  (note leading ^A)

Expected Results:  
http://yahoo.com/space%20space%20here  (possibly with leading ^A)
This looks like it might be related to bug 415034?

Chip: could you attach a HTML test file, rather than inline HTML code? I'm not able to get your example code to act like a normal link...
Component: General → General
Product: Firefox → Core
QA Contact: general → general
(Reporter)

Comment 2

9 years ago
Created attachment 311646 [details]
Sample file to trigger bug
(Reporter)

Comment 3

9 years ago
It's not a "normal" link at all - the first char of the URL is a ^A.  But it is a URL that can be copied with "Copy link location".

Updated

9 years ago
Component: General → Networking
QA Contact: general → networking
(adjusting summary. quotes don't matter)
Summary: Unquoted URLs in tags are interpreted very oddly - possible overflow bug? → URLs containing 0x01 are interpreted very oddly - possible overflow bug?
Ugh.

We first decide this is a relative URL because we're unable to extract a valid scheme (nsIOService::NewURI calls ExtractScheme). ExtractScheme fails because of the invalid scheme character. If you replace the x01 with '_' you see something like https://bugzilla.mozilla.org/_http://yahoo.com/space%20space%20here which is fine (probably not what the author intended, but not an unreasonable guess).

So given the base, nsHttpsHandler::NewURI is called, which creates a nsStandardURL and for some reason calls resolve on the purely "relative" part. 

nsBaseURLParser::ParseURL looks for a scheme, but skips initial space and all control characters, not just the limited whitespace set used earlier. We now think the scheme is a valid "http" instead of bailing out at this point. We now remember scheme starts at 0 and has a length of 4. This is true relative to our modified spec string which we incremented when skipping initial chars, but the caller never gets told we changed the start so all the offsets from that point on are off one.

This bit should have used net_FilterURIString() like the original scheme extraction.

At this point because the scheme doesn't match what it thought the original base scheme was it assumes it must be an absolute URI, regardless of the fact that it was convinced it was relative earlier.

When it puts the URI back together from its component pieces in BuildNormalizedSpec all the offsets are off by one (or more, if there were more leading control characters) which explains the odd result. The scheme length is 4, so the 'p' gets dropped. The host is "/yahoo.co" instead of "yahoo.com", and of course it puts "://" between the scheme and host thus the three slashes, and so on.

Because BuildNormalizedSpec uses our string classes to handle potential expansion of percent encoding and IDN conversion to punycode there's no danger of overflowing any buffers.

The code is clearly broken, but I don't think there's a security problem since the URL in question was broken to begin with (invalid characters). On the other hand any time we get confused when parsing URIs I get nervous.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
Whiteboard: [sg:investigate]
Flags: wanted1.8.1.x+
Yeah, seems to me like ParseURL() should do exactly what ExtractScheme does...  Darin, is there a reason this code skips control chars?
Flags: wanted1.9.0.x? → wanted1.9.0.x+
Depends on: 451613
This is fixed in bug 451613, checked into the 1.8 and 1.9.0 branches.
Keywords: fixed1.8.1.19, fixed1.9.0.5
Verified for 1.9.0.5 with  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5pre) Gecko/2008112505 GranParadiso/3.0.5pre.

Verified for 1.8.1.19 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.19pre) Gecko/2008112503 BonEcho/2.0.0.19pre.
Keywords: fixed1.8.1.19, fixed1.9.0.5 → verified1.8.1.19, verified1.9.0.5
Alias: CVE-2008-5508
Group: core-security
Since this bug is "fixed" (per Daniel Veditz, comment #7), should we close it?
Jason: Bug 451613 hasn't landed on the trunk yet, so this bug can't be FIXED. 

(Additionally, it hasn't landed on 1.9.1, but that'd be tracked with the fixed1.9.1 keyword.)
jst just landed this for me
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.