Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 3 users
Status: Fixed
Closed: Dec 2012
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment
Chrome_Mac: Zombie <DownloadItemController: 0x1f1e6fd0> received -handleReveal: (via -performSelector:withObject:)
Project Member Reported by, May 25 2012 Back to list
Product: Chrome_Mac
Stack Signature: (anonymous namespace)::ZombieObjectCrash-5F6508
New Signature Label: (anonymous namespace)::ZombieObjectCrash
New Signature Hash: ed37f031_4af25130_2aa2945d_8e1b6bea_63c38dfd

Report link: http://go/crash/reportdetail?reportid=58df4fa6b1b0d24b

Meta information:
Product Name: Chrome_Mac
Product Version: 20.0.1132.17
Report ID: 58df4fa6b1b0d24b
Report Time: 2012/05/25 06:18:24, Fri
Uptime: 60 sec
Cumulative Uptime: 0 sec
OS Name: Mac OS X
OS Version: 10.6.8 10K549
CPU Architecture: x86
CPU Info: GenuineIntel family 6 model 30 stepping 5
ptype: browser
zombie_dealloc_bt:	 0x44cb7e41 0x9427dbc6 0x9437274a 0x45262721 0x9424da4c 0x955e5770 0x45264390 0x45262dd8 0x45263a83 0x46f670ee 0x46f67acc 0x46f68a5e 0x46f6d4a4 0x46f647a8 0x45527816 0x45527c77 0x454f97e5 0x955a142b 0x9559eeef 0x9559e3c4
sendaction:	 NSMenuItem tag 0 sending handleReveal: to 0x1f1e6fd0

Comment 1 by, May 31 2012
Labels: -Area-Internals -Restrict-View-Google Area-UI Feature-Downloads
Thread 0 *CRASHED* ( EXC_BAD_INSTRUCTION / EXC_I386_INVOP @ 0x44cb76b4 )

0x44cb76b4	 [Google Chrome Framework]	 -]	(anonymous namespace)::ZombieObjectCrash
0x44cb7716	 [Google Chrome Framework]	 -]	-[CrZombie performSelector:withObject:]
0x94292a25	 [AppKit]	 + 0x00086a25]	-[NSApplication sendAction:to:from:]
0x44edb441	 [Google Chrome Framework]	 -]	-[BrowserCrApplication sendAction:to:from:]
0x942928d8	 [AppKit]	 + 0x000868d8]	-[NSMenuItem _corePerformAction]
0x942925c9	 [AppKit]	 + 0x000865c9]	-[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:]
0x942924b5	 [AppKit]	 + 0x000864b5]	-[NSMenu performActionForItemAtIndex:]
0x94292468	 [AppKit]	 + 0x00086468]	-[NSMenu _internalPerformActionForItemAtIndex:]
0x942923ce	 [AppKit]	 + 0x000863ce]	-[NSMenuItem _internalPerformActionThroughMenuIfPossible]
0x94292312	 [AppKit]	 + 0x00086312]	-[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:]
0x94286a54	 [AppKit]	 + 0x0007aa54]	NSSLMMenuEventHandler
0x9638cc2e	 [HIToolbox]	 + 0x00007c2e]	
0x9638bef5	 [HIToolbox]	 + 0x00006ef5]	
0x963ae7f2	 [HIToolbox]	 + 0x000297f2]	
0x963dae86	 [HIToolbox]	 + 0x00055e86]	
0x963ffb8f	 [HIToolbox]	 + 0x0007ab8f]	
0x963ffb46	 [HIToolbox]	 + 0x0007ab46]	
0x963ffa5c	 [HIToolbox]	 + 0x0007aa5c]	
0x96581363	 [HIToolbox]	 + 0x001fc363]	
0x965816ba	 [HIToolbox]	 + 0x001fc6ba]	
0x9451e6e5	 [AppKit]	 + 0x003126e5]	_NSSLMPopUpCarbonMenu3
0x9451ea75	 [AppKit]	 + 0x00312a75]	-[NSCarbonMenuImpl _popUpContextMenu:withEvent:forView:withFont:]
0x94697944	 [AppKit]	 + 0x0048b944]	-[NSMenu _popUpContextMenu:withEvent:forView:withFont:]
0x946979e3	 [AppKit]	 + 0x0048b9e3]	-[NSMenu _popUpContextMenu:withEvent:forView:]
0x946977b6	 [AppKit]	 + 0x0048b7b6]	-[NSMenu _popUpMenuWithEvent:forView:]
0x9488e65c	 [AppKit]	 + 0x0068265c]	-[NSView rightMouseDown:]
0x9457fd1a	 [AppKit]	 + 0x00373d1a]	-[NSControl _rightMouseUpOrDown:]
0x94369b27	 [AppKit]	 + 0x0015db27]	-[NSWindow sendEvent:]
0x45251488	 [Google Chrome Framework]	 -]	-[ChromeEventProcessingWindow sendEvent:]
0x45279ccd	 [Google Chrome Framework]	 -]	-[FramedBrowserWindow sendEvent:]
0x9428260a	 [AppKit]	 + 0x0007660a]	-[NSApplication sendEvent:]
0x44edb65d	 [Google Chrome Framework]	 -]	-[BrowserCrApplication sendEvent:]
0x94216252	 [AppKit]	 + 0x0000a252]	-[NSApplication run]
0x454f9ba0	 [Google Chrome Framework]	 -]	base::MessagePumpNSApplication::DoRun
0x454f970b	 [Google Chrome Framework]	 -]	base::MessagePumpCFRunLoopBase::Run
0x4552713b	 [Google Chrome Framework]	 -]	MessageLoop::Run
0x44ee2168	 [Google Chrome Framework]	 -]	ChromeBrowserMainParts::MainMessageLoopRun
0x46f3dad5	 [Google Chrome Framework]	 -]	content::BrowserMainLoop::RunMainMessageLoopParts
0x46f3e1d2	 [Google Chrome Framework]	 -]	(anonymous namespace)::BrowserMainRunnerImpl::Run
0x46f3cd70	 [Google Chrome Framework]	 -]	BrowserMain
0x4549fe3a	 [Google Chrome Framework]	 -]	(anonymous namespace)::ContentMainRunnerImpl::Run
0x4549efff	 [Google Chrome Framework]	 -]	content::ContentMain
0x44bcdca8	 [Google Chrome Framework]	 -]	ChromeMain
0x44bc7f57	 [Google Chrome]	 -]	main
0x44bc7f15	 [Google Chrome]	 + 0x00000f15]	start


0x44cb7e41 (anonymous namespace)::ZombieDealloc (chrome/common/mac/
0x45262721 -[DownloadItemController dealloc] (chrome/browser/ui/cocoa/download/
0x45264390 -[DownloadShelfController remove:] (chrome/browser/ui/cocoa/download/
0x45262dd8 -[DownloadItemController remove] (chrome/browser/ui/cocoa/download/
0x45263a83 DownloadItemMac::OnDownloadUpdated (chrome/browser/ui/cocoa/download/
0x46f670ee DownloadItemImpl::UpdateObservers (../base/memory/weak_ptr.h:171)
0x46f67acc DownloadItemImpl::Completed (content/browser/download/
0x46f68a5e DownloadItemImpl::OnDownloadRenamedToFinalName (content/browser/download/
0x46f6d4a4 DownloadManagerImpl::OnDownloadRenamedToFinalName (content/browser/download/
0x46f647a8 base::internal::Invoker<4, base::internal::BindState<base::internal::RunnableAdapter<void (content::DownloadManager::*)(int, const &, int)>, void (content::DownloadManager *, int, const FilePath &, int), void (content::DownloadManager *, int, FilePath, int)>, void (content::DownloadManager *, int, const FilePath &, int)>::Run (../base/bind_internal.h:1569)
0x45527816 MessageLoop::RunTask (/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.2.1/bits/stl_vector.h:361)
0x45527c77 MessageLoop::DoWork (base/
0x454f97e5 base::MessagePumpCFRunLoopBase::RunWork (base/

Comment 2 by, May 31 2012
Status: Assigned
Just a heads up that we (Cambridge downloads team) don't have a lot of Mac UI expertise on this end, which may slow down our ability to handle this bug.  
Based on the stacks, it looks like the DownloadItemController is being right-clicked (which spins nested runloop) while a Chromium task gets pumped that causes the DownloadItemController to be removed and deallocated.
Labels: Restrict-View-SecurityTeam Review-Security
Security folks: Based on the description (which sounds like use-after-free) this is a potential security issue; that right?  

Asanka: Do you have any background in the Mac UI, or is this more of a "someone's got to climb the learning curve" bug?
Labels: SecImpacts-Beta
It does sound like use-after-free, which is a security issue. It sounds like maybe even not just a bad field read/write, but a bad update to the instruction pointer (the "EXC_BAD_INSTRUCTION / EXC_I386_INVOP @ 0x44cb76b4" makes me think maybe Chrome tried to find a function pointer but it was wild. That is potentially Critical, mitigated perhaps by the requirement of user interaction (right-click required).

Can we get a reproduction case for this? Without that it's hard for us to properly triage the bug and be sure that it is really fixed.
Labels: -Type-Bug Type-Security
Labels: Mstone-20
This is an ObjC use-after-free, which is caught by the runtime and we crash ourselves (deref into a NULL pointer). See ZombieObjectCrash.
Yeah, definitely looks like a security bug, although the severity is unclear because we don't know the full context of the trigger. The code in ZombieObjectCrash looks helpful for debugging purposes, but I don't see anyway it would stop an actual exploit attempt if an attacker can force memory churn between the free and stale use of the object in question.
jschuh: This is a null deref, see comment 9. Aren't those safe?
Comment #9 pointed to some code that tries to catch stale object accesses for analysis purposes. Unless I was misreading the ObjC (possible, because it's not my strongest area) this code helps track down crashes by tracking the most recently freed objects and triggering a NULL deref if they're accessed. However, any modern use-after-free exploit is going to need to churn memory to get the necessary address reallocated. So, the memory in question still gets aged out and reused; it just requires a bit more churning. That's why I said "I don't see anyway it would stop an actual exploit attempt."

Or, is there something I'm missing?
No, jschuh's analysis is correct. If you allocate and deallocate enough objects, an attacker could cause zombies to fall off the treadmill, messages to which would then not be caught by ZombieObjectCrash (though it's a very large treadmill, 10k in the browser, 1k in all other ptypes). Thakis is also correct, though, that the exception code is for a NULL deref.

I'm still not sure about the exploitability, though. That and the attacker would have to be pretty knowledgable about the ObjC runtime calling conventions to create an exploit. I'm don't think I've heard of such a vulnerability in the Cocoa community before, but it's obviously possible.

I think it's also possible to create a unit test to exercise this (a user repro would maybe be a little more difficult). I'll try and write that test this week.
Those numbers aren't particularly high, and there seemed to be patterns that could trigger reuse sooner. The main obstacles to an exploit at that stage would be major unpredictability in the reallocation patterns, but that doesn't seem to be an issue here.

As for ObjC, I haven't personally done Mac/iOS exploit work, so I can't say definitely. However, my impression from those who do is that the ObjC runtime is a very soft target. Either way, we generally don't debate the hypothetical exploitability of security bugs. We make a best effort to rate them appropriately and focus on getting the fix out.
Switching owners per discussion with rdsmith.

Definitely intend to fix it, but it seems hard to rate the severity if we don't understand the exploitability. From what I can tell, this can only happen with the nested runloop from a right-click menu. I need to noodle on the proper fix, however.

I also don't have an insights into the ObjC runtime from a security perspective.
Labels: SecSeverity-High
@rsesek - Sounds like we're in agreement on that; The requirement for a right-click is actually a pretty useful mitigation, because it's an unusual enough interaction that it would make the attack less viable in practice. That's why we hadn't assigned severity yet, because we were unsure if that was necessary. Based on your assessment that it is, I'm assigning high rather than critical.
Status: Started
Found the issue; CL coming shortly.

The closure that calls DownloadItemImpl::OnDownloadRenamedToFinalName and eventually -[DownloadItemController remove] is in fact pumped while the download context menu is running. -[DownloadItemButton mouseDown:] properly guards against this by retaining the DownloadItemController before popping open the menu. This means that if you click the arrow portion of the button, you can't repro this. But AppKit by default opens the attached menu when right-clicking on controls, but since DownloadItemButton does not retain the controller in -[rightMouseDown:], you can get a zombie controller.


1. Download a medium-sized file
2. While it's downloading, click on the button in the shelf to cause it to open when the download completes
3. RIGHT (Ctrl-) click the button to pop open the context menu
4. After the download completes, choose "Reveal in Finder"
5. Crash
Labels: SecImpacts-Stable
This can also affect stable.
Project Member Comment 21 by, Jun 6 2012
The following revision refers to this bug:

r140870 | | Wed Jun 06 15:39:34 PDT 2012

Changed paths:

Retain the controller in -[DownloadItemButton rightMouseDown:] before opening the menu that targets it.

BUG= 129826 
TEST=See comment #18 in bug.

Review URL:
Labels: Merge-Requested
Labels: -Merge-Requested Merge-Approved
Status: FixUnreleased
The security team can handle the merge, or you can do it if you don't mind.
If you guys want to drive the merge, that'd be great!
Project Member Comment 25 by, Jun 12 2012
Labels: merge-merged-1132
The following revision refers to this bug:

r141707 | | Tue Jun 12 12:27:29 PDT 2012

Changed paths:

Merge 140870 - Retain the controller in -[DownloadItemButton rightMouseDown:] before opening the menu that targets it.

BUG= 129826 
TEST=See comment #18 in bug.

Review URL:
Review URL:
Labels: -Restrict-View-SecurityTeam -SecSeverity-High -Merge-Approved Restrict-View-SecurityNotify SecSeverity-Low Merge-Merged
Merged but seems low severity due to complicated UI interactions to trigger?
 Issue 94751  has been merged into this issue.
Comment 28 by, Jun 21 2012
Wow, looks like I had everything I needed in that other bug, but didn't annotate it correctly.  Apologies!
Labels: CVE-2012-2827
Project Member Comment 30 by, 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.
Status: Fixed
Project Member Comment 32 by, Mar 10 2013
Labels: -Type-Security -Area-UI -Feature-Downloads -SecImpacts-Beta -Mstone-20 -SecSeverity-Low -SecImpacts-Stable Security-Severity-Low M-20 Security-Impact-Stable Security-Impact-Beta Cr-UI Type-Bug-Security Cr-UI-Browser-Downloads
Project Member Comment 33 by, Mar 13 2013
Labels: Restrict-View-EditIssue
Project Member Comment 34 by, Mar 14 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue
Project Member Comment 36 by, Mar 21 2013
Labels: -Security-Severity-Low Security_Severity-Low
Project Member Comment 37 by, Mar 21 2013
Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member Comment 38 by, Mar 21 2013
Labels: -Security-Impact-Beta Security_Impact-Beta
Project Member Comment 39 by, Jun 14 2016
Labels: -security_impact-beta
Project Member Comment 40 by, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Project Member Comment 41 by, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Sign in to add a comment