Go beyond the impossible!
Stack Exhaustion in WebKit.dll – Safari.
Well well, if you haven’t already, stop using Safari! This script is very simple and very critical, it causes an Access Violation exception in WebKit.dll, which several browsers are based upon. Luckily, Google Chrome is enough sandboxed and can not be exploited trough this vulnerability.
The script simply fills the DOM document with <marquee> tags and within seconds, causes both Safari and Opera to crash. However Opera does not run WebKit but it turned out that the exploit made it crash for other reasons (http://secunia.com/advisories/39590).
I was going to debug this, but Visual Studio 2010 was unable to analyze the process however OllyDBG said:
Don’t know how to step because memory at address FFF3F5FB is not readable. Try to change EIP or pass exception to program.
I have only tested this in Safari and Chrome, feel free to comment if you test in some other browser using webkit and tell us your results.
The exploit can be found here.
Update: Apparently Konqueror does not run WebKit, I’m sorry for this miss and thanks for pointing it out, “Arioch”.
Print article | This entry was posted by Mathias Karlsson on 26/04/2010 at 3:20 pm, and is filed under Critical, Documentation, Web Security. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site. |
about 1 week ago
I just have to write this interesting error log from Opera:
OPERA-CRASHLOG V1 desktop 10.51 3315 windows
Opera.exe 3315 (1) caused exception C0000005 at address 00000000 (Base: 1090000)
Registers:
EAX=035D6470 EBX=03482B78 ECX=001AEA5C EDX=67E15018 ESI=07F3A738
EDI=032539B8 EBP=001AEAB0 ESP=001AEA44 EIP=00000000 FLAGS=00010246
CS=0023 DS=002B SS=002B ES=002B FS=0053 GS=002B
FPU stack:
00000000000000000000 00000000000000000000 00000000000000000000
4006B300000000000000 4006B300000000000000 4003D800000000000000
3FFF8000000000000000 00000000000000000000 SW=0126 CW=027F
…
Cheers mate!
about 1 week ago
As i wrote two posts ago, this exploit also affects the:
# Dolphin Browser/2.5.0 – HTC Hero
# Chrome/??? – HTC Hero (Default Browser)
-webbrowsers. And as said previously, we do not have the required tools to debug it. Unfortunately.
about 6 days ago
“Konqueror and other browsers relying on WebKit might also have this flaw but I have only tested this in Safari, Opera and Chrome”
Opera uses Presto, not WebKit.
about 6 days ago
Yes, we thought it did when we tried it and it would crash but it turned out to be another vulnerability in Opera (http://secunia.com/advisories/39590). I can see why the text makes you think it uses WebKit. Updated and thanks for the comment!
about 5 days ago
Opera has already published a patch: http://my.opera.com/desktopteam/blog/2010/04/28/opera-10-53-rc1-for-windows-and-mac
It’s just a snapshot, not a “stable” release, but at least it should fix the bug.
about 5 days ago
Yeah we noticed, awesome by Opera to publish a patch that fast!
about 4 days ago
Konqueror does not use WebKit as well. so someone having KDE test it plz
about 4 days ago
Pretty nice post. I just stumbled upon your blog and wanted to say that I have really enjoyed browsing your blog posts. In any case I’ll be subscribing to your feed and I hope you write again soon!
about 3 days ago
I tried it on Opera 10.10 on FreeBSD. Didn’t crash. So it affects only 10.51.
about 3 days ago
“Konqueror does not use WebKit as well.”
It does now. It switched to WebKit after the mess Apple made, I think.