Closed Bug 1334102 (CVE-2017-5423) Opened 6 years ago Closed 6 years ago

Mozilla Firefox Int Overflow/Unchecked Address Addition Out of Bound Read (ASLR Bypass)


(Core :: Graphics, defect)

50 Branch
Not set



Tracking Status
firefox-esr45 --- wontfix
firefox52 --- verified
firefox53 --- verified
firefox54 --- verified


(Reporter: defcom1, Assigned: bas.schouten)


(Keywords: sec-low, Whiteboard: [adv-main52-])


(2 files)

Attached file fuzz_521_crash5.html
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.79 Safari/537.36 Edge/14.14393

Steps to reproduce:

Run some JavaScript that creates 2 canvas's and then transforms one and uses drawImage to copy it into the other canvas.

Actual results:

The browser instance crashed out as the address that was being used to create a bitmap was not valid due to an int overflow. This vulnerability could be used to retrieve arbitrary memory blocks that could lead to an ASLR bypass in Windows.

The crash will be in either an NVIDIA driver dll or ATI due to the address being passed down the call stack for processing by the underlying graphics software. But the actual issue lies in Firefox due to unchecked addition to an address.

The vulnerable code path:

Expected results:

The values added to the second argument that's passed to CreateBitmap should be checked prior to being passed to the function.
Milan, can you find someone to investigate?
Group: firefox-core-security → core-security
Component: Untriaged → Graphics
Flags: needinfo?(milan)
Product: Firefox → Core
Bas, would you suggest a CheckedInt approach or something else here?
Flags: needinfo?(milan) → needinfo?(bas)
Group: core-security → gfx-core-security
Flags: needinfo?(twsmith)
This isn't actually related to an overflow. It's a different type of issue, patch upcoming.
Flags: needinfo?(bas)
So there really is an actual driver -or- D2D bug here, we tell the driver we're creating a height 0 surface, which implies we're not passing it any readable memory. However it seemingly still tries to read from the given address. This could be in D2D or the NVidia driver itself.

When our uploadRect is Empty though there's no real need to do anything with the gibberish it might contain though, so the upcoming patch should be a sufficient fix.
Assignee: nobody → bas
Ever confirmed: true
Attachment #8831731 - Flags: review?(milan)
Note the security impact is likely low here as far as I can tell, -if- a surface could be returned at all for a 0x0 size bitmap, which would contain the memory located at that particular byte, it is unlikely to be directly informative nor tell you what the exact content of that byte was.
Attachment #8831731 - Flags: review?(milan) → review+
I haven't actually properly looked at this yet, but I will check it out tonight...

eax=b40ce91c ebx=000000ca ecx=00000001 edx=00000004 esi=bb9278bc edi=0f9e91a0
eip=611e46fc esp=00efc3e4 ebp=00efc3f0 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210202
611e46fc f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

From what I can see from the crash dump I originally got from !exploitable, it looks like a DWORD sized section of memory is being read from ESI, which is the address we control. I'm guessing EDI is the data section of the bitmap that's going to be returned? I will look into it later.
Comment on attachment 8831731 [details] [diff] [review]
Do not attempt to upload empty rectangles.

Approval Request Comment
It is possible this could reduce the number of driver resets on Nvidia  in the cases where the driver resets instead of crashing.  If that was the case, it could benefit the CompositorD3D11::BeginFrame crash, currently top 10 browser crash in 51.

Bas, this doesn't have a security rating; if it is going to be less than sec-high, you can land it without security approval.
Flags: needinfo?(bas)
Attachment #8831731 - Flags: approval-mozilla-beta?
Attachment #8831731 - Flags: approval-mozilla-aurora?
So I looked into this briefly last night and it would appear as though the DWORD gets written into the bitmap object and returned. So it comes down to how Firefox deals with this.
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Group: gfx-core-security → core-security-release
Comment on attachment 8831731 [details] [diff] [review]
Do not attempt to upload empty rectangles.

don't upload an empty rect, aurora53+, beta52+
Attachment #8831731 - Flags: approval-mozilla-beta?
Attachment #8831731 - Flags: approval-mozilla-beta+
Attachment #8831731 - Flags: approval-mozilla-aurora?
Attachment #8831731 - Flags: approval-mozilla-aurora+
Flags: needinfo?(bas)
Flagging this for manual testing, testcase available in Comment 0.
Flags: qe-verify+
Flags: needinfo?(twsmith)
Reproduced the issue with an affected build (51.0.1, 20170125094131) using the testcase from Comment 0 on Windows 10 x64: 6bc8cc71-0730-4966-b006-a43f694bc10f.

This is verified fixed on Windows 10 x64, Ubuntu 16.04 x86 and macOS 10.12.3, using:

  - 52.0b9-build2 (20170223185858),
  - 53.0a2 (2017-02-24),
  - 54.0a1 (2017-02-24),

on which the test case is no longer crashing.
Flags: qe-verify+
out of curiosity, I was wondering if issues like this (sec-low) are also considered for bug bounty program?
(In reply to Soroush Dalili from comment #16)
> out of curiosity, I was wondering if issues like this (sec-low) are also
> considered for bug bounty program?

Per our security page, please write to for bug bounty questions. I only saw this question because I was looking at the bug for other reasons. No, sec-low bugs don't receive bounties.
Whiteboard: [adv-main52+]
Alias: CVE-2017-5423
Whiteboard: [adv-main52+] → [adv-main52-]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.