Bug 815795 (CVE-2013-0768)

stack buffer overflow with canvas

RESOLVED FIXED in Firefox 18

Status

()

Core
Canvas: 2D
RESOLVED FIXED
5 years ago
3 years ago

People

(Reporter: miaubiz, Assigned: gw280)

Tracking

(Blocks: 1 bug, {csectype-intoverflow, sec-critical})

Trunk
mozilla20
x86
Linux
csectype-intoverflow, sec-critical
Points:
---
Bug Flags:
sec-bounty +
in-testsuite ?

Firefox Tracking Flags

(firefox17 wontfix, firefox18+ verified, firefox19+ fixed, firefox20+ fixed, firefox-esr10 unaffected, firefox-esr1718+ fixed, b2g18 fixed)

Details

(Whiteboard: [asan][adv-main18+][adv-esr17+])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Created attachment 685817 [details]
repro case

<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'
(Reporter)

Comment 1

5 years ago
Created attachment 685819 [details]
asan log linux
Whiteboard: [asan]
Flags: sec-bounty?
cc+ Milan. Needs assignee and a sec rating.
Assignee: nobody → milan
George, can you take a quick look?
Assignee: milan → gwright
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];
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.
Keywords: sec-critical
Created attachment 694097 [details] [diff] [review]
Fix integer overflow

Found the expression that overflows, and it seems upstream fixed this already.
Attachment #694097 - Flags: review?(jmuizelaar)
Created attachment 694098 [details] [diff] [review]
Fix integer overflow

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)
Attachment #694098 - Flags: review?(jmuizelaar) → review+
Solid. What versions of FF are affected?
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?
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: --- → ?
Once Al gives sec-approval, please nominate for uplift to Aurora/Beta/ESR10/ESR17, making sure to land no later than 12/26.
status-firefox-esr10: ? → affected
tracking-firefox-esr10: --- → 18+
tracking-firefox18: ? → +
tracking-firefox19: ? → +
tracking-firefox-esr17: ? → 18+
Comment on attachment 694098 [details] [diff] [review]
Fix integer overflow

sec-approval+ on trunk.
Attachment #694098 - Flags: sec-approval? → sec-approval+
status-firefox17: affected → wontfix

Updated

4 years ago
status-firefox-esr10: affected → wontfix
tracking-firefox-esr10: 18+ → ---
tracking-firefox-esr17: 18+ → ---

Updated

4 years ago
status-firefox-esr10: wontfix → affected
tracking-firefox-esr10: --- → 18+
tracking-firefox-esr17: --- → 18+
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.
Landed on m-c:

https://hg.mozilla.org/mozilla-central/rev/7457db98e2e3
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

4 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+
Is there any reason this isn't marked as FIXED if it's on m-c?
Flags: in-testsuite?
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.
esr10 doesn't appear to be affected (or at least, I can't reproduce it locally with esr10) so closing it for that.
status-firefox-esr10: affected → unaffected
tracking-firefox-esr10: 18+ → ---
https://hg.mozilla.org/releases/mozilla-b2g18/rev/59639b84eb14
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g18: --- → fixed
status-firefox18: affected → fixed
status-firefox19: affected → fixed
status-firefox20: affected → fixed
status-firefox-esr17: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
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.
I can reproduce locally. Will investigate. This may require a new bug.
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?
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.
Can you try setting the pref gfx.xrender.enabled to false and see if that fixes the crash in VMware?
(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).
Setting the preference mentioned in comment #24 the problem goes away; the browser remains responsive.

Updated

4 years ago
status-firefox18: fixed → verified
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.
Whiteboard: [asan] → [asan][adv-main18+][adv-esr17+]
(Assignee)

Updated

4 years ago
Blocks: 826379
Alias: CVE-2013-0768
Flags: sec-bounty? → sec-bounty+
Keywords: csec-intoverflow
Group: core-security
You need to log in before you can comment on or make changes to this bug.