Breaking out of the Chrome sandbox – 2 interesting vulns in 24 hours? Got IE8? :)

So it hasn’t even been out 24 hours yet but Chrome is, as predicted, getting scrutinized heavily and well . . . it’s falling down at a pretty alarming rate (as say compared to say – IE8 beta 2 which has been out longer :))
So yesterday Aviv Raff discovered that Chrome is vulnerable to the Safari carpet bomb issue as reported here:  This is actually a download and execute / remote code execution bug which is about as bad as it gets!  I verified that the PoC downloads a .JAR file to my IE downloads folder and then attempts to execute it (I got a file open dialog since I don’t have Java installed).

Then this morning we have a new, more interesting (IMHO) crash that was posted here:
So, I slapped WinDBG on both processes to see what’s going on – and I visited the PoC site from my Vista++ machine and this is what I observed in the debugger attached to the medium IL kernel process:
0:022> g

(1078.fe4): Break instruction exception – code 80000003 (first chance)

eax=553a2ff0 ebx=0024e238 ecx=553a2ff0 edx=775cea74 esi=0024e238 edi=00000002

eip=553a2ff3 esp=0024e180 ebp=0024e180 iopl=0         nv up ei pl nz na pe nc

cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000206

*** ERROR: Symbol file could not be found.  Defaulted to export symbols for D:\Users\rhensing\AppData\Local\Google\Chrome\Application\\chrome.dll –


553a2ff3 cc              int     3

0:000> ub eip


553a2fe3 56              push    esi

553a2fe4 e8d5dc5d00      call    chrome_553a0000!ChromeMain+0x5ddb99 (55980cbe)

553a2fe9 59              pop     ecx

553a2fea 8bc6            mov     eax,esi

553a2fec 5e              pop     esi

553a2fed c20400          ret     4

553a2ff0 55              push    ebp

553a2ff1 8bec            mov     ebp,esp

Why is this crash interesting?  Because it crashes the medium IL ‘kernel’ process and not the low IL ‘sandbox / rendering engine’ process (though that process does exit when the parent process dies)!!  Why is that interesting?  Because it points to protocol handler abuse as a potential way to bypass the protection measures of the low IL rendering engine sandboxes! 

Overall – I have to admit – I am in love with Chrome – the UI is fantastic, the rendering is pretty fast, and it’s very intuitive and clutter free . . . that said – I’m very concerned about the code quality given that in less than 24 hours we’ve got one confirmed remote code execution vuln (one that was already patched by Apple in the same source code weeks ago!) and one ‘interesting’ discovery / crash – that is certainly going to draw attention to fuzzing protocol handlers and maybe lead to the discovery of something even more interesting.

Welp – the ball has been resoundingly slammed back over the net at Google – and it will be interesting to see how they respond.  Will they release a blog detailing what’s going on with the protocol handler debug break above?  Will they release an update soon that corrects these two issues?  Will they talk about how these issues were missed and what they’re doing to ensure there aren’t variations all over the place?

Comments (1)

  1. Anonymous says:

    Zawsze uważałem, że rozwojowi oprogramowania najbardziej sprzyja konkurencja. Jeżeli jakiś producent