Post a Comment
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.
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.
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?
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
---------------------------------------------------------------------- -
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.
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.
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
... 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...
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 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.
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
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).
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.
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.




