Closed
Bug 783041
Opened 12 years ago
Closed 12 years ago
out-of-bounds read when blurring
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
RESOLVED
FIXED
mozilla17
People
(Reporter: miaubiz, Assigned: MatsPalmgren_bugz)
References
Details
(5 keywords, Whiteboard: [asan][adv-track-main17+])
Attachments
(9 files)
|
1.29 KB,
text/plain
|
Details | |
|
1.83 KB,
text/plain
|
Details | |
|
1.95 KB,
text/plain
|
Details | |
|
1.55 KB,
text/plain
|
Details | |
|
2.36 KB,
text/plain
|
Details | |
|
1.58 KB,
text/plain
|
Details | |
|
1.58 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
|
1.40 KB,
patch
|
roc
:
review+
|
Details | Diff | Splinter Review |
|
9.16 KB,
patch
|
Details | Diff | Splinter Review |
opening this html crashes asan:
<html>
<head>
<style>
#el7 {
font-size:.92em
}
#el0 {
height: 200px ! important;
margin: 0px;
display: table;
font-size:.92em
}
#el3 {
line-height: 0.5px;
text-shadow: 0px 5px 5px, 0px -20px 10px;
display: table-row-group;
transform: translate3d(-3px, -300px, 0px);
}
#el5 {
height:1em;
display:block;
}
.c4 {
margin: 1em;
padding: 0.5em;
}
</style>
<script>
onload = function() {
el7=document.createElement('iframe')
el7.setAttribute('id', 'el7')
document.body.appendChild(el7)
el0=document.createElement('span')
el0.setAttribute('id','el0')
document.body.appendChild(el0)
el0.appendChild(document.createTextNode('A'))
el3=document.createElement('q')
el3.setAttribute('id','el3')
el0.appendChild(el3)
el5=document.createElement('q')
el5.setAttribute('id','el5')
el3.appendChild(el5)
el0.appendChild(document.createTextNode('A'))
document.body.offsetTop
el0.setAttribute('class', 'c4');
el7.setAttribute('class', 'c4');
}
</script>
</head>
<body>
</body>
</html>
like so:
==7766== ERROR: AddressSanitizer heap-buffer-overflow on address 0x7fffc8308570 at pc 0x7ffff18196d7 bp 0x7fffffff22c0 sp 0x7fffffff22b8
READ of size 1 at 0x7fffc8308570 thread T0
#0 0x7ffff18196d7 in mozilla::gfx::BoxBlurVertical(unsigned char*, unsigned char*, int, int, int, int, mozilla::gfx::IntRect const&) /builds/slave/try-lnx64/build/gfx/2d/Blur.cpp:148
0x7fffc8308570 is located 16 bytes to the left of 1-byte region [0x7fffc8308580,0x7fffc8308581)
allocated by thread T0 here:
#0 0x424331 in __interceptor_malloc ??:0
#1 0x7ffff1817c86 in mozilla::gfx::AlphaBoxBlur::Blur() /builds/slave/try-lnx64/build/gfx/2d/Blur.cpp:443
==80621== ERROR: AddressSanitizer heap-buffer-overflow on address 0x0001297b6e78 at pc 0x1080f96f7 bp 0x7fff5fbeaa60 sp 0x7fff5fbeaa58
READ of size 1 at 0x0001297b6e78 thread T0
#0 0x1080f96f7 in _ZN7mozilla3gfxL15BoxBlurVerticalEPhS1_iiiiRKNS0_7IntRectE (in XUL) (Blur.cpp:148)
0x0001297b6e78 is located 8 bytes to the left of 1-byte region [0x0001297b6e80,0x0001297b6e81)
allocated by thread T0 here:
#0 0x10000bd1d in (anonymous namespace)::mz_malloc(_malloc_zone_t*, unsigned long) (in firefox) + 45
#1 0x7fff92d583c8 in __strtodg$UNIX2003 (in libsystem_c.dylib) + 945
#2 0x7fff92d591a4 in __strtodg$UNIX2003 (in libsystem_c.dylib) + 4493
#3 0x1080f7cb6 in mozilla::gfx::AlphaBoxBlur::Blur() (in XUL) (Blur.cpp:443)
I've seen anything from 4 to 84 bytes to the left depending on the exact values.
|
Assignee | |
Comment 6•12 years ago
|
||
I get a fatal assertion on the first and fourth testcase using a Linux64 asan debug build: Assertion failure: aRows > 0, at gfx/2d/Blur.cpp:119
Assignee: nobody → matspal
Severity: normal → critical
status-firefox-esr10:
--- → affected
status-firefox14:
--- → affected
status-firefox15:
--- → affected
status-firefox16:
--- → affected
status-firefox17:
--- → affected
Component: Layout → Graphics
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [asan]
|
|
Assignee | |
Comment 7•12 years ago
|
||
The problem is that we test IsEmpty() on 'rect' which is a gfx Rect which use floating point members, and then later copying those to 'mRect' which is IntRect, so a small rect.height makes IsEmpty() false but mRect.height zero. Later we depend on 'mData' being NULL for an empty 'mRect' - the "aRows" in the assertion comes from 'mRect.height'. Testing mRect.IsEmpty() instead should fix it. I don't see anything that would do an illegal write operation in this file (for either zero width/height) so the bug appears non-exploitable, just an illegal read operation, which should crash safely. This patch applies also to Aurora and Beta. The code is slightly different on esr10, but it looks like it's also affected (gfxAlphaBoxBlur::Init in file gfx/thebes/gfxBlur.cpp). It should be easy to make a similar fix for esr10. https://tbpl.mozilla.org/?tree=Try&rev=aa94c6c8986e
Attachment #652243 -
Flags: review?(roc)
|
|
Assignee | |
Comment 8•12 years ago
|
||
'shadowIntRect' is redundant now - we can use mRect instead which already is an IntRect. s/IntersectRect/Intersect since we don't use the return value of the former.
Attachment #652246 -
Flags: review?(roc)
Attachment #652246 -
Flags: review?(roc) → review+
Attachment #652243 -
Flags: review?(roc) → review+
|
Reporter | |
Comment 10•12 years ago
|
||
if the adjacent memory is mapped readable, can the result of the bluring be used to leak contents of memory?
|
|
Assignee | |
Comment 11•12 years ago
|
||
(In reply to miaubiz from comment #10) > can the result of the bluring be > used to leak contents of memory? No, the read values are only stored in a local variable and does not propagate any further when the bug occurs. The code is written in such a way that the write operations does not occur when aWidth or aRows is zero: http://hg.mozilla.org/mozilla-central/file/50e4ff05741e/gfx/2d/Blur.cpp
|
|
Assignee | |
Comment 12•12 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/9e3450bbd3e3 https://hg.mozilla.org/integration/mozilla-inbound/rev/6383531428d1
Flags: in-testsuite?
Target Milestone: --- → mozilla17
|
|
Assignee | |
Comment 13•12 years ago
|
||
miaubiz@gmail.com, I slapped the standard MPL2 onto your files: <!-- This Source Code Form is subject to the terms of the Mozilla Public - License, v. 2.0. If a copy of the MPL was not distributed with this - file, You can obtain one at http://mozilla.org/MPL/2.0/. --> OK?
|
|
Reporter | |
Comment 14•12 years ago
|
||
@mats: ok with me
|
||
Comment 15•12 years ago
|
||
(In reply to Mats Palmgren [:mats] from comment #12) > https://hg.mozilla.org/integration/mozilla-inbound/rev/9e3450bbd3e3 > https://hg.mozilla.org/integration/mozilla-inbound/rev/6383531428d1 https://hg.mozilla.org/mozilla-central/rev/9e3450bbd3e3 https://hg.mozilla.org/mozilla-central/rev/6383531428d1
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
|
||
Comment 16•12 years ago
|
||
Sec-other implies that this bug is not exploitable. Is that the case? https://wiki.mozilla.org/Security_Severity_Ratings
|
|
Assignee | |
Comment 17•12 years ago
|
||
Yes, it's not exploitable AFAICT, see comment 7 and comment 11.
|
||
Comment 18•12 years ago
|
||
sec-other, non-exploitable, falls outside of esr criteria - wontfixing.
|
||
Comment 19•12 years ago
|
||
Since this is not exploitable there shouldn't be a problem landing the tests and unhiding the bug.
|
||
Comment 20•12 years ago
|
||
Should we flag this status-firefox14:wontfix and status-firefox15:wontfix at this point?
|
||
Updated•12 years ago
|
Whiteboard: [asan] → [asan][adv-track-main17+]
|
|
||
Updated•12 years ago
|
Alias: CVE-2012-5832
|
|
||
Updated•12 years ago
|
Alias: CVE-2012-5832
|
|
||
Updated•11 years ago
|
Group: core-security
Flags: sec-bounty-
|
|
Assignee | |
Comment 21•11 years ago
|
||
Crash tests: https://hg.mozilla.org/integration/mozilla-inbound/rev/c955c4e5eaff
Flags: in-testsuite? → in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•