256316 - non-ascii char in URL lead to heap overrun

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Daniel Veditz [:dveditz]]

The SBB FAQ says :
"However as a special exception we will also consider paying rewards
for bugs found in the most recent releases from designated stable
branches (e.g., from the Mozilla 1.7 branch after 1.8 is released) if
the bugs are not present in the most recent version but were never
recognized and fixed as security bugs."

So I thought you would be interested to know about bugs that were
fixed as standard bugs, but which are actually critical security
bugs.

So I investigated some reported Mozilla crashes and actually found
something very interesting in bug #254671.
After some hours spent in finding the actual cause of the bug, and
finding that it is exploitable, I realised the bug has been discussed
and (should have been) fixed in bug #250900. So I am not going to give
detailed technical details about the bug, you can see the discussion
there.

This bug has a very critical security impact which has been missed by
Mozilla developpers. Here is the reason why:
- put a non-ascii character in a long hostname in an url. Ex:
  http://AAAAAAAAAAAAAAèAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
- the UTF8 conversion of the hostname is called and fails, but returns
  a SUCCESS error code. So the variable  approxLen is incremented by
  0 instead of strlen(mHost)  (this is the bug)
- a buffer is allocated with length  approxLen + 32 (which is
  too short)
- then mHost is copied into this buffer --> BUFFER OVERFLOW ON THE HEAP
  WITH ARBITRARY DATA SUPPLIED IN THE HOSTNAME BY THE ATTACKER


The bug exists on Mozilla 1.7.2 (Linux and Windows), at least
in the version I downloaded from your website 10 days ago.

I verified that on Windows systems, the bug leads to MOV [EAX], ECX
where we control EAX and ECX (0x41414141), which is the common 
situation in exploitable heap overflows.

I think all OSes are vulnerable, and that this bug can be exploited
when viewing a website or when clicking on a link in an email.

Cheers

Gael Delalleau

Comment 1

[Daniel Veditz [:dveditz]]

(this was received Wed, 18 Aug 2004 06:35:44 -0700 (PDT))

Comment 2

[Daniel Veditz [:dveditz]]

The root cause was identified as a buffer overflow by Mats Palmgren in bug
250900 comment 13, but Mats' patch was rejected by Darin and ultimately not
addressed in the final patch.

Why?

Comment 3

[Darin Fisher]

In a nutshell, the function in question expects a UTF-8 string.  If it is given
garbage that is not UTF-8, then it should not be expected to work.  The eventual
patch for bug 250900 fixes the callsite to ensure that UTF-8 is always passed. 
That patch should be ported to the 1.7 and aviary branches.

That said, I am not against adding some protective measures to either
nsStandardURL or the IDN code.  I would prefer to have the IDN code generate a
proper error code in this case.  It may also be wise to fix XPConnect so that it
ensures that any data passed through |string| is ASCII.  This problem will
continue to come up so long as XPConnect allows non-zero 8-th bit when passing
data through |string| parameters.

Comment 4

[Darin Fisher]

Attachment: v1 patch

This patch adds a sanity check for the input argument to
nsIDNService::Normalize.    

I don't think this bug should qualify for a bug bounty since the bug would be
fixed by landing the trunk patch on the stable branches.  That simply has not
happened yet, and AFAIK there has not been a next release of the stable
branches since 1.8a3 was released.  I think the text in the bug bounty FAQ
needs to be revised to clarify how this situation should be handled.

Comment 5

[Daniel Veditz [:dveditz]]

I could only once get a crash with registers that approximated my data, and in
that case it was 0x61616161 which I think was crashing on data from a previous
run (which lowercased the URL). I got a couple other crashes with random
registers that didn't look controlled, and mostly noticed nothing at all.

Would be nice to fix the overrun (especially since the trunk fix didn't protect
against other misusers of nsStandardURL), but I'm not convinced this is exploitable.

Gael: have a better PoC for this?

Comment 6

[Brendan Eich [:brendan]]

Plusing bug for 1.7.x and aviary 1.0 -- darin, please request approvals once you
have review.  Also, what bug tracks the XPConnect failure to restrict string to
7-bit chars in all cases?

/be

Comment 7

[Darin Fisher]

> what bug tracks the XPConnect failure to restrict string to
> 7-bit chars in all cases?

bug 256785

Comment 8

[Daniel Veditz [:dveditz]]

Comment on attachment 156918 [details] [diff] [review]
v1 patch

r=dveditz

sr=bryner with the comment that NS_ENSURE_TRUE() would be better than
NS_ENSURE_ARG()

Comment 9

[Gaël Delalleau]

* About exploitability: I had an URL which always crashes the Mozilla 1.7.2 browser with my data in the usual exploitable spot in ntdll.dll on WinXP SP1, each time I ran it. I am currently on vacations (writing 
this comment from my PDA), so I'll be able to provide this PoC only after sunday. I need to double check if the data is filtered in some way, though.

[Anyway, even with a <8 bytes buffer overflow on the heap, with filtered data (only ascii lowercase for instance) it is usually possible to exploit certain OSes. Heap corruption is sometimes very difficult to exploit reliably, but not impossible.]

* About the Security Bug Bounty: I don't really care about getting a bounty or not for this bug, as long as the decision is consistent with your policy as explained in the FAQ.
I think you may need to improve the FAQ to tell with more details for which bugs you want to award a bounty. Here are some examples the FAQ should address:
- what if I find a security bug in the latest CVS version, but in a line someone just wrote and commited? Maybe 2 days later someone would have noticed the bug and it would never make its way in the public release. Maybe not.
- what if I find a security bug in the current version available on the website, but the bug has been reported in Bugzilla (and maybe even fixed in the CVS) but not as a security bug?
I guess some of the cons of not knowing about the security impact of a bug are: the fix may not be included in the next stable release, the QA testing doesn't focus on security so some holes may stay open, third party sofware based on Mozilla are left vulnerable because they don't backport non-security fixes, the attack is not included in IDS and antivirus/filtering software, the users are not aware of this exploit so they can't keep an eye open for the attack, etc.
Now do you want to give a bounty for this kind of information... that's up to you guys.
So, could you please update this FAQ so that security researchers can focus on what the Mozilla Fundation really needs.

Comment 10

[Darin Fisher]

Comment on attachment 156918 [details] [diff] [review]
v1 patch

Requesting approval to land this change on the branches.

Comment 11

[Darin Fisher]

> sr=bryner with the comment that NS_ENSURE_TRUE() would be better than
> NS_ENSURE_ARG()

I can switch to NS_ENSURE_TRUE, I guess.  NS_ENSURE_ARG made sense to me since I
am validating an input argument.  Maybe NS_ENSURE_TRUE with NS_ERROR_UNEXPECTED
would be better?  I could do that, sure.

Comment 12

[Darin Fisher]

fixed-on-trunk

Comment 13

[chris hofmann]

Comment on attachment 156918 [details] [diff] [review]
v1 patch

a=chofmann for the branches

Comment 14

[Darin Fisher]

fixed1.7.3, fixed-aviary1.0

marking FIXED

Comment 15

[Darin Fisher]

Gaël: As for my comments about the Bug Bounty, you should know that I don't
speak for the Mozilla Foundation.  I was simply giving my opinion.  I was/am
somewhat confused about how this situation should be handled.  That said, I
greatly appreciate you bringing to light the potential security concerns of this
bug.

Comment 16

[Daniel Veditz [:dveditz]]

Fixed on 1.7.2 branch

Comment 17

[Gaël Delalleau]

Attachment: PoC of exploitable heap overflow

Hi,

This overflow is indeed exploitable. The data supplied by the
attacker is converted to lowercase, but this is not much of a
problem because most non-alpha characters are unmodified.
For instance we can write to addresses in the 0x7FFDxxxx range,
which are commonly used in heap overflow exploits to take
control of the EIP register. (For an overview of these concepts
I suggest reading the slides of the presentation Daniel Litchfield
gave at Black Hat Windows 2004)

Check the attachment for more details and a few PoC links.

For better results, start a new Mozilla 1.7.2 process, open the .htm
file from a local copy stored on your hard disk, and click on the
links. Don't complain too loudly if you get random crashes, this is only
a PoC for a specific system setup (as described in the .htm file) to
prove that the bug is exploitable, but this is not a working exploit,
and I am not using any technique to make exploitation more reliable.

Comment 18

[pozouille]

(In reply to comment #17)




Hello may be you will see this, on my computer :)

Alert of intrusion, Black Ice PC Protection

[Unauthorized Access Attempt] This looks for links with nonascii characters
embedded within them. These links could trigger a buffer overflow on some
versions of Mozilla.

Time, Event, Intruder, Count
30/11/2004 00:29:24, HTTP_Mozilla_Nonascii_URL_BO, sd285.sivit.org, 12=Count


How to remove this vulnerability Jump to the top of this document

For Firefox:
Upgrade to the latest version (1.0PR or later), available from the Mozilla Web
site. See References.


---------------------------------------------------------------------

install.log of Firefox 

Start Log: 24/11/2004 - 14:35:52
    System Info:
        OS Type: NT51
        Major Version: 5
        Minor Version: 1
        Build Number: 2600
        Extra String: Service Pack 2
        Total Physical Memory: 261616KB
        Total Available Physical Memory: 121692KB

    Product Info:
        Install mode: Normal
        Company name: Mozilla
        Product name (external): Mozilla Firefox
        Product name (internal): Mozilla Firefox
        Uninstall Filename: UninstallFirefox.exe
        UserAgent: 1.0 (fr-FR)
        Alternate search path: 

    Components corrupted (startup):
        none
ة
    Destination Path:
        Main: C:\Program Files\Mozilla Firefox
        SubPath: 



Firefox 1.7.5: 2004110812


May be is just The Version of my firefox, but this is 1.0