A bug in Apple’s Safari leaves it vulnerable to crashing from an animated image. All webkit apps are vulnerable, even rss readers. This comes after Internet Explorer and Firefox had vulnerabilities due to pictures. Why is it that images cause browsers so many problems?
I clicked the “>>Image Of doom<<” link before posting and it did crash Safari… all 7 pages I had open…
Hopefully Apple get this sorted quick, as I don’t like the idea of images killing my browser
who said that ‘statically linked image decoding libraries are evil’ ?
each app having its own local copy, each app has to be updated instead of simply updating a shared library.
…and then you have to worry about the bug getting caught in all of the applications (if it exists) and then updating when and if the vendor releases one. With shared libaries, update once, and all your apps are updated as well.
There are flip sides to that as well: if a shared library is updated, it is just as likely to cause everything that depends on it to work in a different manner than before; this is AKA “DLL Hell” under Windows, and I’m sure there’s no difference in other OS’s, beyond the name.
So, what am I saying? They’re both good and bad, but are mirror opposites in terms of which ways they’re good and bad.
The advantage AND disadvantage of shared libraries is you upgrade everything at once, while the advantage AND disadvantage of statically linked libraries is that you upgrade everything separately, with the first case of shared possibly breaking everything else that previously worked, and the static version only fixing one thing, if you can get it updated, but at least it doesn’t break everything else that was working fine.
As far as resource usage, shared libraries are definitely more efficient, and get more efficient as more currently running applications that use them are in use: they exist once in physical memory, and thus are more likely to be in the CPU cache (can’t remember, though, if the CPU caches by logical or physical address) and definitely more likely to not be paged out because of how frequently they are used, besides the fact that they only take up a fixed amount of physical memory, regardless of how many processes are using them.
So, use them according to what the user and system needs: they both have their places.
It didn’t crash my Safari. I sat there waiting to be shocked when I clicked on the image of doom, but it didn’t happen.
Should I report this to apple as a bug 🙂
5 second’s after loading the image Safari crashed (OS 10.4.2 and all the security updates installed)
People using Safari 1.2.X are reporting that it doesnt crash in general, Mac OS X 10.4.X which includes Safari 2.0 (412.2.X) are in general experiencing the crash… I use safari 2.0 on MacOS X 10.4.2 and after about 5seconds Safari crashed aswell
Also One comment on the linked page, said that with certain Webkit builds the image doesnt cause a crash either.
Well hopefully Apple figures it out.
>Why is it that images cause browsers so many problems?
Because their decompression algorithms are rather complex, leaving many points of failures. And the image loaders have traditionally not have many eyes studying them, looking for errors.
—
http://www.digg.com , the better /.
Yet another reason why I prefer Camino. 😉
Having said that, it’s not crashing on my copy of Safari either.
I agree completely. AmigaOS’s datatypes is something I’m surprised to not see in more systems. Or maybe there are negative sides to it that I’m not aware of…
Datatypes were taken one step further in BeOS, they’re called Translators.
It will no doubt be interesting to see, how long it will take Apple until they release a security fix for this flaw.
After all, they have been trying to explain to customers for a rather long period of time that their reactivity is far superior to the one the company from Redmond has, yet until now, we got to see the truth. Security fixes are, even though released faster than with Microsoft, not fast enough. Than again, when are security fixes released fast enough…
A point on which I ask myself at least one question is the following. The Safari versions who got this vulnerability are still, if I remember correctly, based on the KHTML engine. So than, is there a chance that Konqueror is vulnerable as well?
Didn’t crash with Konqueror 3.4.2 on FreeBSD 5 STABLE.
It maybe that just the Apple Webkit GIF Library has the vulnrability. Would be bad if Konq had this problem as well, as I use Konq as my browser on BSD, and Linux
The image didn’t crash a patched Konqueror under SUSE (patched KDE 3.4.0). I do remember a while back there were a number of image library updates. Although I don’t see any GIF related advisories (SUSE and Mandriva/Mandrake) in my archive.
I have Safari 1.1.1 running on OS X 10.3 – no crash.
Tried it with Konqueror – Kde 3.4.1 on FreeBSD 6-Beta 2. Waited and waited and waited for it to crash but nothing happened. Konq went on strong without a crash.
————————————————
For the best newbie friendly PC-BSD guide, see my site at:
http://michael-and-mary.net/intro
———————————————————————- –
Is Konqueror based on WebCore or WebKit ?
No, it’s the other way around, Safari is based on Konqueror, or rather khtml. 😀
Let’s hope Apple has some sort of in-house Security Squad at the ready, and pagers/cellphones are ringing right now.
Apple has a lot of people on crack (obviously, I mean, brushed metal?), that’s for sure.
Can someone clarify to me wh ythis is classed as a “vulnerability” or “security problem”, when other problems that cause programs to crash are counted as “bugs”?
Is it something to do with the internet aspect of it, or something else?
Thanks
Ben
Because like the linked page says there is a possibility for malicious use of this “Flaw” in the Image library in webkit.
How is that a security issue?
It’s simple, right now this particular image is causing a crash because someone threw it together to prove a point and the data that it is executing is just junk. Now give a black hat a few days to finely craft an image that instead of executing junk, executes something malicious, like say delete everything in my user folder, or download and execute this worm from some website. If the user has permissions to do the bad thing, then it will happen.
Oddly, it didn’t crash Safari using the default 10.4.2+All updates. But a using a version with a very recent check-out of WebKit crashes.
using Safari 1.3 and it didn’t crash
I’m still on Mac OS X 10.4.1, using Safari 2.0 build 412 and the “image of death” looks like just another image to me. The vulnerability was likely introduced by the 10.4.2 update.
Yes, but will it crash Safari running on my AMD Athlon 64?
it probably will if you’re using a vulnerable version of webkit
I’m running OSX Tiger (10.4.2) with all official updates since release (including security update 2005-007, v1.1). Safari is at version 2.0 (412.2.2).
Attempting to load the ‘Image of Doom’ in the same window and in a seperate window fail to cause a crash. I have tried half a dozen times, with no crash.
I’ve been wondering why Myspace.com crashes Safari on occasion. I guess that would be why.
Myspace tanks Konqueror, Mozilla Suite, Firefox and Opera 8 so I would test the javascript code on myspace and validate it being W3C compliant before thinking it is well written.
Yeah MySpace is definitely a Safari Killer…same with Friendster.
When Safari crashes and the Crash Reporter pops up, be sure to copy and paste the link to the picture (you can open Safari again) before sending it off.
This is what I like about Mac OS X, protected memory. If something crashes a program at least it doesn’t take the whole machine down with it. You can instantly reopen the app and get right back to buisness.
By the way, these corrupted images also affect iPhoto.
Still this vunerability isn’t fixed yet. (harmless link to site)
http://secunia.com/multiple_browsers_dialog_origin_vulnerability_te…
And this one wasn’t fixed yet either (will launch iChat *scary*)
http://www.halo3leak.cjb.net
And this one as well (may crash PC machines!)
http://www.jgiannotti.com/pwned/imagecrash.jpg
Tiger & Safari 2.0 on Blue & White w/G4 upgrade.
Datatypes were taken one step further in BeOS, they’re called Translators.
I did not know that. Thanks.
… but I’ve been experiencing other problems with safari. It freezes along with everything else. The finder is still somewhat working, BUT when I try to start another program… it wont. So I have to hold down the power button, not even reboot or shut down works. Camino is relatively free of that.. even if I’ve tried it once. I believe that SI.com is the problem. So I’ll have to read Dr. Z on sports.yahoo.com instead.
But it bugs me.. I had no problems then came home from vacation and whoopdeedoo!
… but I’ve been experiencing other problems with safari. It freezes along with everything else. The finder is still somewhat working, BUT when I try to start another program… it wont.
I get that as well, as far as I can tell it’s lookupd getting hosed and it causes all manner of different problems.
Try disconnecting and reconnecting your network connection (from the menu bar), that works for me. The disconnect / reconnect seems to force lookupd to crash, the system automatically restarts it and then it’s fine.
—
Image of doom did nothing until I pressed reload, there was a delay and then…
Mac OS X 10.4.3 (8F15) / Safari 2.0.1 crashes too…
this really shouldn’t happen
I wholeheartedly agree. Let’s think about this for a minute… How long has the GIF format, let alone the animated version thereof been around? How long have web browsers been around? How long has the internet been around? Why are these things even still possibly problems??? It’s just sad. It’s sloppy, lazy programming on a lot of peoples’ hands.
Oh, and I agree with shared libraries being super important and useful (to some extent, as there’s always a con to everything, though I can’t think of one off the top of my head for shared libs). OS X has the right idea with the Core libraries, and Apple should keep furthering that whenever possible. On the ADC site there’s an article about endian conversion for PPC->x86 and it says Core Endian (not one word). Hmm.
I had to reload to get it happen. OS X 10.4.2 (8C46) with Safari 2.0 (412.2.2). I also made sure to report it to Apple with the link.
I use the nightly WebKit builds using NightShift.app. It has been a couple of weeks since my last update, but the old update didn’t crash by viewing Image of Doom either. I tried updating WebKit just now as well to see if the problem reappeared, but no such luck. Works fine here.
I do sometimes find Safari a big memory eater, but that is the price to pay by using nithtly WebKit builds I guess.
yeah, that’s the price to pay. But there are so many advantages to using nightly builds of a rendering engine!! Like… err… well….
Haha.
You should try the builds, they are stable enough. This last one fixed my memory problem as well.
Well, add this to a list of things that make me mad over safari.
The memory leaks are my main issue, a browser shouldn’t suck a gig of ram after a few days.
The freezes are annoying.
The sudden closing of the browser while computer not in use is very annoying.
And just today I awoke to the safari having had crashed and for the first time actually popping up a crash alert.
I really don’t get why apple has had such a hard time making safari work. You can see why they have barely changed it since they introduced it. They have probably had to many other issue then to add features.
Keap fingers crossed for 10.4.3
Hehe, just posted the link to one of my friends using mac… and it actually crashed his chat client (Proteus)!
Seems Proteus uses WebKit for the chat window rendering,
so users of proteus should disable the “display inline images” feature until this is fixed..
Many users have mentioned it does not crash on their safari. I wonder if it is processor dependent. I have a G3 iBook running Tiger with all the patches and it definitely crashes.
well I’m on a G4 Mini and it crashes
Tiger 10.4.2 Safari 2
Powerbook G4 1.25
OS X 10.4.2
Safari 2.0
Using OSX 10.4.2 all updates with Safari Version 2.0 (412.2.2) loaded the image of doom and no crash even after 1 minute. Refreshing the image page caused safari to crash however.
Yeah, it loaded but on a reload, kaboom safari is no more.
Running 10.4.3 SU7 V1.1 on a dual 1.8 PM
Probably whether it crashes or not depends how Safari’s memory is currently allocated. In either case, the exploit causes Safari to access memory that it shouldn’t be accessing from that part of the code. Depending how its memory is allocated, that memory can be either in its allocated memory region (in which case it doesn’t crash, but its still a bug – especially if it tries to write to that memory), or outside its allocated memory region (in which case Mac OS X’s protected memory manager catches it, and terminates Safari).
Bad coders / stupid choice of languages.
I don’t use Tiger for just *two* reasons (“iPiano” and “Go… Network” are wonky) and now I hear that Tiger users are suffering Safari *CRASHES* because of mere animated GIFs? BWA-HA-HA-HA! I always sensed that Tiger was buggier than Panther (in certain respects)… and now we’re seeing those little bugs creeping all over Tiger like fleas on a cat’s back!
The way it looks now, I’ll probably upgrade to Tiger (or Leopard) when the Intel Macs hit the shelves… if they’ve gotten all the BUGS worked out by then! Heh! Until then, I’m happily using Panther 10.3.9.
Rid the internet of animated gifs, esp. ugly ones like that.
I’m pretty sure anyone laughing at this bug is not a programmer.
And for those who are programmers, go on the internet, find the specification for animated gifs, and try to code a animated GIF decoder, one that is fast. And that without stealing code from others. How many times do you think your decoder will crash while in development until you get a stable version? How much time before you are sure that no GIF can ever crash it, even corrupted ones? How can you test all possible GIF sizes, palettes and animation parameters possible? There are billions of possibilities if you also take into account the possible contexts inside which it’s being run. Sure you can try a range of possibilities, and make sure to test extreme parameters and corrupted files, but you’d never be %100 sure. The more sure you want to be, the more time it takes to test it. Maybe, just like in the WebKit/Safari bug, there is a special case that could crash your decoder in your “shipping” version.
Actually, until relatively recently it was possible to crash just about any browser with a corrupted image (JPEG, PNG or GIF). I’m sure there are plug-ins like video players that can crash on specific movies. I’m pretty sure I could lock just about any browser with a flash movie. There is nothing extraordinary about a corrupted file making a browser crash, but since Apple is in the spotlight, you get this kind of coverage: “Look Macs are not safer after all! because one GIF file can make the browser crash!”
Another reason why people talk about it is that sometimes, these crashes can be exploited to execute malicious code. But it’s not automatically the case. Until now, none has proven that you could use the GIF bug in WebKit/Safari to execute code. There is only vague speculation about it in comments found in the linked page.
Sometimes you have to reload the image three or four times for Safari to crash and it may take tens of seconds to do so, at least in Safari 2.0.1 (412.5) running under 10.4.2.