Closed Bug 256316 Opened 16 years ago Closed 16 years ago
non-ascii char in URL lead to heap overrun
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
(this was received Wed, 18 Aug 2004 06:35:44 -0700 (PDT))
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?
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.
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.
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?
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
> what bug tracks the XPConnect failure to restrict string to > 7-bit chars in all cases? bug 256785
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()
* 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 on attachment 156918 [details] [diff] [review] v1 patch Requesting approval to land this change on the branches.
> 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.
Status: NEW → ASSIGNED
Comment on attachment 156918 [details] [diff] [review] v1 patch a=chofmann for the branches
fixed1.7.3, fixed-aviary1.0 marking FIXED
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.
Fixed on 1.7.2 branch
Whiteboard: [have patch] [sg:fix] → [sg:fix] fixed1.7.2+
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.
Whiteboard: [sg:fix] fixed1.7.2+ → [sg:fix] fixed1.7.3
(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
You need to log in before you can comment on or make changes to this bug.