New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 94487 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Security: JSC::Yarr regexp 32/48 to the left of 768 with workers

Reported by miau...@gmail.com, Aug 27 2011

Issue description



VULNERABILITY DETAILS

The repro itself is rather large, and it contains a lot of repetition, inside a lot of repetition and it takes a lot of tries to repro it.

But it does happen over and over with this file and not with others. 

repro.html is the main file, and the others are the stock files from the chromium/webkit automated tests.

it only works with the http:// schema for me, (maybe because there are no workers in the file:// schema?)

the filesystem api is not needed for this, because it says in the output div:
[Worker] This test requires FileSystem API.
Got error from worker: Uncaught ReferenceError: requestFileSystem is not defined

VERSION

Chromium	15.0.864.0 (Developer Build 98444-dirty)
OS	Linux
WebKit	535.2 (trunk@93707)
JavaScript	V8 3.5.8

64bit linux

REPRODUCTION CASE
attached

FOR CRASHES, PLEASE INCLUDE THE FOLLOWING ADDITIONAL INFORMATION
Type of crash: worker thread, sad tab


==12910== ERROR: AddressSanitizer crashed on address 0x00007fffe5724450 at pc 0x7ffff669080b bp 0x7ffc56f05c70 sp 0x7ffc56f05c00
READ of size 4 at 0x00007fffe5724450 thread T96
    #0 0x7ffff669080b in JSC::Yarr::Interpreter::matchDisjunction(JSC::Yarr::ByteDisjunction*, JSC::Yarr::Interpreter::DisjunctionContext*, bool) ???:0
    #1 0x7ffff668cdc5 in JSC::Yarr::Interpreter::interpret() ???:0
    #2 0x7ffff668c9e4 in JSC::Yarr::interpret(JSC::Yarr::BytecodePattern*, unsigned short const*, unsigned int, unsigned int, 

0x00007fffe5724450 is located 48 bytes to the left of 768-byte region [0x00007fffe5724480,0x00007fffe5724780)
allocated by thread T0 here:
    #0 0x7ffff6c7d7ea in malloc _asan_rtl_
    #1 0x7ffff373cf2b in WTF::fastMalloc(unsigned long) ???:0
    #2 0x7ffff669b734 in WTF::Vector<JSC::Yarr::ByteTerm, 0ul>::reserveCapacity(unsigned long) ???:0
    #3 0x7ffff669811d in JSC::Yarr::ByteCompiler::regexBegin(unsigned int, unsigned int, bool) ???:0
    #4 0x7ffff668c1d8 in JSC::Yarr::ByteCompiler::compile(WTF::BumpPointerAllocator*) ???:0

 
asan-worker.txt
8.7 KB View Download
repro.html
366 bytes View Download
worker-repro.zip
8.8 KB Download

Comment 1 by tsepez@chromium.org, Aug 29 2011

Labels: -Pri-0 Pri-1 Mstone-14 SecSeverity-High

Comment 2 by tsepez@chromium.org, Aug 29 2011

Labels: -Mstone-14 Mstone-15

Comment 3 by kareng@google.com, Aug 30 2011

Owner: security@chromium.org
Status: Assigned
Cc: kcc@chromium.org
Mind taking a look at  issue 72548 ?
I've seen some random race reports from JSC::Yarr on our TSan UI bot

Comment 5 by kcc@chromium.org, Aug 31 2011

Labels: Stability-AddressSanitizer
Interesting! 
The race reports in   issue 72548  look extremely weird, but if there is an OOB access these race reports start making sense.

The initial comments by miaubiz@ about the required long repetition also suggest a race. 
Cc: knorton@google.com

Comment 7 by mal@google.com, Sep 8 2011

Labels: Stability-CodeYellow

Comment 8 by kareng@google.com, Sep 8 2011

Labels: Mstone-16
Owner: ----
Status: Untriaged
@kareng: let's avoid assigning things to security@chromium.org for now. It makes it look like something is being worked on when in fact it is not :)

Comment 10 by cdn@chromium.org, Sep 27 2011

Labels: OS-All
Labels: -SecSeverity-High SecSeverity-Low
Owner: jsc...@chromium.org
Status: Assigned
It's a race condition in DOMImplementation::isXMLMIMEType. In a normal renderer the static local xmlTypeRegExp will always be initialized on the main thread. However, in a worker process you can have multiple threads racing to initialize xmlTypeRegExp, which can cause you to crash on a wild read when the initialization conflicts between two threads.

I'm inclined to bump this out of security queue given that it's a race to an OOB read where you don't control any input data and can't read back the value. However, I'll just bump it down to low-severity. It's an easy enough problem to fix. I just need to figure out the WebKit way to do it.

Labels: -Restrict-View-SecurityTeam -Area-Undefined -Mstone-16 Restrict-View-SecurityNotify Area-WebKit Mstone-15 Merge-Approved
Status: FixUnreleased
http://trac.webkit.org/changeset/96999
Labels: -SecSeverity-Low SecSeverity-Medium SecImpacts-Stable SecImpacts-Beta
Bumping it up to medium since it can be triggered after xmlTypeRegExp is initialized, which gives control of at least the source string.
Labels: -Merge-Approved Merge-Merged merge-merged-874
merged to m15 in r97020.
Labels: CVE-2011-3878

Comment 17 by cdn@chromium.org, May 15 2012

Status: Fixed
Marking old security bugs Fixed..
Project Member

Comment 18 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 19 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Area-WebKit -SecSeverity-Medium -Stability-AddressSanitizer -Mstone-15 -SecImpacts-Stable -SecImpacts-Beta Cr-Content M-15 Security-Impact-Beta Security-Severity-Medium Performance-Memory-AddressSanitizer Security-Impact-Stable Type-Bug-Security
Project Member

Comment 20 by bugdroid1@chromium.org, Mar 13 2013

Labels: Restrict-View-EditIssue
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Project Member

Comment 25 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member

Comment 26 by bugdroid1@chromium.org, Apr 1 2013

Labels: -Performance-Memory-AddressSanitizer Stability-Memory-AddressSanitizer
Project Member

Comment 27 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 28 by sheriffbot@chromium.org, Jun 14 2016

Labels: -security_impact-beta
Labels: reward-topanel
Project Member

Comment 30 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 31 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Labels: -reward-topanel reward-unpaid reward-1000
We're going over old bugs that might have missed going in front of the VRP panel.  The panel decided to award $1,000 for this bug!
Labels: -reward-unpaid reward-inprocess
Labels: CVE_description-submitted

Sign in to add a comment