Everything is under control

Around a week ago the following at the Internet Storm Center popped up in my feeds...
Multiple vulnerabilities have been reported in Apple Mac OS X and applications. Proof of Concept code has already been posted along with the information regarding the vulnerabilities. At this time no patches or workarounds appear to be available for the majority of the vulnerabilities. The impact is Denial of Service or arbitrary code executed remotely, and severity is highly critical.
I set a reminder to write some notes about it if it hadn't really permeated the "Mac Web" after a week -- or whatever the hell pandering placebo passes for the majority of it at this point (it's probably food for thought that the majority people reading will be seeing them first the first time on some site named DrunkenBlog sporadically updated by some guy named drunkenbatman... and no offense to myself, but that's probably as big a canary as the following issues) -- so it's worth running through these while the coffee brews as, ya know, they're kinda important...
I'll keep it relatively brief, as they're exactly the types of things I was talking about in the last few posts and I think some of the patterns are pretty self-evident and not worth rehashing from those. You can follow the links for more specific info, but the liner notes are what really snagged my head...
- Apple OS X 10.4.5 .tiff "LZWDecodeVector ()" Heap Overflow
When processing a malformed .tiff image file, the LZWDecodeVector() function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.
Oh. My. Fucking. Gawd.This issue was silently fixed by Apple in update 10.4.6.
Feel free to check the release notes for Mac OS 10.4.6 yourself, and raise your hand if it seems immediately obvious why a vendor fixing a security issue known internally in a point release without informing their users that it even exists in the previous version is a really bad idea both in the short term for users and in the long term for Apple as a company. I mean, bajesus.
Ba-fucking-jesus.
This just harms me internally.
Apple. What. The. Hell.
- Apple OS X BOM ArchiveHelper .zip Heap Overflow
BOMArchiveHelper is the default archive file handler in Mac OS X. It runs as a service that does not have a GUI interface. It is invoked when double clicking on a archived file. A heap overflow vulnerability exists within BOMArchiveHelper which allows for an attacker to cause the application to crash, and or to execute arbitrary code on a targeted host.
This vulnerability was to Apple on 2/21/2006. No patch is available at this time.
- Apple OS X Safari 2.0.3 Multiple Vulnerabilities
Multiple vulnerabilities exist within Safari 2.0.3 (417.9.2) and all prior versions which causes the application to crash, and or may allow for an attacker to execute arbitrary code. Below are the crash address, and links to basic PoC to reproduce the crashes.
Apple was notified of these issues on 01/06/2006. Currently no patches have been released for these vulnerabilities.
- Apple OS X 10.4.6 "ReadBMP ()" .bmp Heap Overflow
A heap overflow vulnerability exists when processing .bmp files which causes the application to crash, and or may allow for an attacker to execute arbitrary code on the targted host.
Apple was notified. Currently no patches have been released for this vulnerability.
- Apple OS X 10.4.6 "CFAllocatorAllocate ()" .gif Heap Overflow
A heap overflow vulnerability exists when processing .gif files which causes the application to crash, and or may allow for an attacker to execute arbitrary code on the targted host.
Apple was notified. Currently no patches have been released for this vulnerability.
- Apple OS X 10.4.6 .tiff "_cg_TIFFSetField ()" DoS
When processing a malformed .tiff image file, the _cg_TIFFSetField () function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.
Apple was notified. Currently no patches have been released for this vulnerability.
- Apple OS X 10.4.6 .tiff "PredictorVSetField ()" Heap Overflow
When processing a malformed .tiff image file, the PredictorVSetField () function does not properly parse the malformed data causing the application which it was opened with to crash. This issue is within the core .tiff parsing engine making Preview, Finder, QuickTime, and Safari potential attack vectors for this issue.
Apple was notified. Currently no patches have been released for this vulnerability.
[Update] In a bit of amusing timing, a reader pointed me to Macs no longer immune to viruses at MSNBC from last night with quotes from Ferris, who found the issues above, which is also linked at Slashdot this morning. Where it gets confusing is that there are apparently claims now of people having arbitrary code run on their machines, while Apple is saying it can't happen, but there aren't links to deconstruct what's actually going on. Until there are so it can be verified and dissected, it has to be taken with a grain of salt. Fun times.
[Update 2] Duh, this was probably just the Oompa-Loompa, aka Leap.A, the worm from February. Since they didn't actually name it and said he clicked a link, I made the jump that they were implying it was something else. Oof.
Comments (34)
Posted by: John Pannell at May 1, 2006 10:05 AM
DB - For a guy who seems to share mojo/karma/vibes with developers, you sure have been merciless in these security threads. The first time it was eye-opening, but this is just getting nuts. Perhaps you should polish your resume, and get a job making security fixes for Apple to rid yourself of your demons!
Posted by: raygadson at May 1, 2006 10:27 AM
This post would have been much better if you had embedded one of those malformed .tiff files inside the page.
I think you're losing your mojo.
Posted by: Tobias at May 1, 2006 10:33 AM
Considering theses are potentially very dangerous but easy to fix bugs I think DB is allowed to be mad. We all should be. And further considering that a company we like seems to adopt the ways of certain a company we don't like: doubly so.
Posted by: at May 1, 2006 10:38 AM
OH MY GOD, CODE HAS BUGS. WHO WOULD HAVE THOUGHT.
Posted by: Alex at May 1, 2006 10:51 AM
Good to know you're still alive and kicking DB.
Also... wow. I wonder how long until Apple gets a serious wake up call. Something like W32/Blaster for Mac OS X do you think?
Posted by: TL at May 1, 2006 10:54 AM
Do static analysis tools for XCode and GCC exist in OSX? On Windows, there are tools to analyze source code for obvious errors such as buffer overruns, badly allocated memory, bad strings and race conditions.
Posted by: j at May 1, 2006 11:01 AM
There are some interesting slashdot comments:
From your buddy the Rosyna:
It's just sad really. This Tom guy can't read crash reports. He reports the same TIFF crash as two different crashes, and then says there is a parsing error in CFAllocatorAllocate(), which does parse anything, it just allocates memory. In CF, most functions will call abort() and force an application crash if given bad parameters. Such as a 0 size for memory.
Most, if not all, of these just amount to DoS attacks and it's not actually possible to get them to run arbitrary executable code. But now days any kind of reproducible crash is incorrectly regarded as a massively massive security issue. It's people like Tom Ferris that make real computer security jobs into a joke.
And from an Anonymous Coward
I'd take an Apple spokeswoman's word over Tom Ferris's word. He's fairly good at finding crash bugs, but he frequently reports zero dereferences as "buffer overflows", etc. See his record in bugzilla.mozilla.org, for example, starting with bug 303433. I have no idea why the media keeps calling him a security expert.
Posted by: plurgid at May 1, 2006 11:13 AM
Why is it that the computer security 'scene' encourages more testosterone production than dollar beer night at a gentleman's club? Everybody's a badass & I mean EVERYONE. I've seen the most mild mannered folks transformed into headstrong asses, absolutely convinced of their own infallibility. I know, because I've been in the field for almost 10 years, and I can tell you I've done it, and everyone I know has done it. I can also tell you that a detached, analytical approach with a healthy dose of humility is far more productive in the long run, and will save you a ton of grief when it turns out that, in spite of yourself, you were wrong about something fundamental.
Another thing is that 'the scene' is basically an echo chamber full of people on the kind of testosterone fueled orgy of self-assuredness I described above. Add in the fact that there's a burgeoning computer security industry thriving off the energy from this scene, and you've just got a real bad signal to noise ratio.
I'm not invalidating what you're saying up there. I'm just kinda saying that it's probably not time to rend our garments and run through the streets proclaiming the end is neigh.
Yeah, if Apple doesn't manage to get real quick and thorough with their security patches, the mac will no longer 'be immune' to viruses. The switch to x86 instruction set probably doesn't help.
Having to deal with security on a mac like on a PC will suck.
I hope apple manages to work this out before it gets serious, but really, what are you planning to do? Shame them into submission? I dunno, maybe that'll work ... carry on good sir!
Posted by: Matt Johnson at May 1, 2006 11:32 AM
I'm glad DB linked to the Slashdot article with Rosyna's comment. It makes sense to a non-programmer. My question to him is if the "researcher" is below-par and can find these bugs, what is there for the true hackers to find? Less or more? MJ
Posted by: Peter Jaros at May 1, 2006 02:31 PM
> OH MY GOD, CODE HAS BUGS. WHO WOULD HAVE THOUGHT.
Try telling that to Apple right about now... ;)
Posted by: Kevin Ballard at May 1, 2006 02:42 PM
I haven't checked up on this myself, but I was told that article is actually a repost of an older article, which coincided nicely with the terminal-command-file-as-image exploit, which is what my first thought as to the vector of exploitation for that article sounded like.
Posted by: a at May 1, 2006 04:14 PM
Hey DB, if you put one of the following into your post, you can crash Safari for anyone who visits. That'll make 'em take you seriously.
<TABLE COLSPEC=http:SECURITY-PROTOCOLS CELLSPACING=7432679423 >
<OBJECT DATA=YIKES >
<LI VALUE=2143658709 TYPE=A >
<TABLE >
<FRAME SCROLLING= NAME=TOMFERRIS SRC= SCROLLING= >
<FRAMESET >
Posted by: Peter at May 1, 2006 05:01 PM
OMG!!11!1 Macs have viruses! Or Will! Might! Soon! Any! Day! Now! Really! Buy my report! Ipod's OS/X needs Norton, or Bad Things Will Happen Someday! And a pony!
Sheesh.
Posted by: jtr at May 1, 2006 06:08 PM
1. Water is wet
2. The sky is blue.
3. Software has bugs.
Get over it, luser.
Posted by: Peter da Silva at May 1, 2006 07:04 PM
I don't care whether you're Microsoft or Apple, you just bloody DO NOT use the same set of bindings for opening local files that the user has explicitly asked you to open and for files you're using a helper application to display from a mail message or web page.
You just don't do this.
Microsoft, you've been trying to make this safe since 1998. By the time Vista is actually in common use that'll be 10 years you've been trying to make this work. You won't have it fixed. You'll just make it more annoying. How about a post-vista update in which you back out ActiveX and the "yes, we got it right this time, we can run untrusted native code" aspects of .NET and try and get Windows back to where it was when the "Good Times" virus was just a joke.
Apple, you should know better. You've been laughing at Microsoft for pulling this shit, how about you have a look at what you're doing yourselves. It's not as daft as ActiveX but lord knows it's not smart. Get rid of all the auto-install auto-open auto-run shit and stop treating the Internet as part of your filesystem. It's not.
Posted by: Adrian at May 1, 2006 09:47 PM
Yeah, if Apple doesn't manage to get real quick and thorough with their security patches, the mac will no longer 'be immune' to viruses. The switch to x86 instruction set probably doesn't help.
The new TV ads probably don't help either.
Posted by: Gaita at May 1, 2006 11:42 PM
Hmmmm? Posting this the same day the "I'm a mac, I'm a PC" ads are aired for the first time is a funny coincidence... isn't it? ...right? ...right?
Posted by: P at May 2, 2006 02:44 AM
On 1) above: It doesn't say when the issue was reported. Are you certain that it even WAS reported? Are you certain Apple knew about it? Perhaps they were just investigating some other bug and happened to fix this as well during a rewrite? Of course you should realise what you're actually doing when fixing a buffer overflow, but would and should etc.
Posted by: Rosyna at May 2, 2006 04:09 AM
Adrian, as stated before, there is no proof whatsoever that these crashes can be used to execute arbitrary code. The worst they have been proven as is a denial of service attack (the service being the application that crashes).
Posted by: Dave at May 2, 2006 05:24 AM
Trackback:
"... The most worrying of these from my perspective is the first link, not so much for the exploit itself because I think over the course of previous threads we have agreed that they can and will happen. No, the thing that worries me is the fact that security fixes are not being disclosed by Apple in their release notes. ..."
Posted by: fee at May 2, 2006 06:54 AM
Wolf! Wolf! Wolf! WOLF!!1! ... Hello? Anyone out there?
Posted by: Arden at May 2, 2006 12:01 PM
Is DB drinking the coolaid? How are any of these security vulnerabilities at all? The most they do is make applications crash, which I would hardly pin under the category of "security flaw." As a couple people have stated before:
Software. Has. Bugs.
That doesn't mean it's a security vulnerability. I can't see anybody using any of these crashes in the vein of, say, the Slammer worm, or the iLoveYou virus, or anything like that at all. If all of the things DB listed here are "security vulnerabilities," then I think Windows has a lot more "security vulnerabilities" than are already known.
Geesh.
Posted by: Stern at May 2, 2006 12:39 PM
Arden wrote:
I can't see anybody using any of these crashes in the vein of, say, the Slammer worm, or the iLoveYou virus, or anything like that at all.I just wanted to point out that the ILOVEYOU worm didn't utilize any vulnerabilities. It was just a VB script that disguised itself as a text file, and required the user to run it.
Posted by: Jay Tuley at May 2, 2006 12:55 PM
I don't know DB, why should I believe this when Apple has a factual sounding web page that says
People attempting to break into computers may disguise a malicious program as a picture, movie, or other seemingly harmless file. You might download such files from the Web, or get them via mail or chat. A PC just blindly downloads them without a peep. A Mac, however, will let you know that you may be getting a wolf in sheep’s clothing. The Mac web browser, Safari, can tell the difference between a file and a program, and alerts you whenever you’re downloading the latter.http://www.apple.com/getamac/viruses.html
Posted by: Anders Hovmöller at May 2, 2006 04:22 PM
Which underlying core issues are you talking about here? And what should be done about it? It's all fine and good pointing to the problem, but there ARE solutions, do at least LINK to them.
Posted by: Jeff at May 2, 2006 06:11 PM
I do understand some of DB's frustrations but in many ways, Apple is now in the same mode as Microsoft, where new features are generally more important than security or finding problems. It would be interesting to learn if Apple has people even looking for problems in Mac OS X, or if they simply wait for problems to occur.
The only operating system where proactive work seems to occur is OpenBSD.
Posted by: Ajay at May 2, 2006 06:49 PM
HAHAHA, "no offense to myself," HAHAHA
Posted by: Skorp at May 2, 2006 07:03 PM
DB is getting retarded.
Posted by: John at May 6, 2006 12:58 AM
With regard to your first gripe: libtiff was updated, which corrected this flaw. This fix was in and shipped before the cause of the crash was known, and hence there was no security update needed.
JP
Posted by: Arden at May 8, 2006 11:21 PM
Further proof that DB is drinking the kool-aid, or maybe too many white Russians:
http://www.newsfactor.com/story.xhtml?story_id=43170
Posted by: Peter da Silva at May 9, 2006 09:50 AM
"Which underlying core issues are you talking about here?"
The ones mentioned in the top link of the page my URL points to. :)
The use of a single set of bindings for remote (and therefore inherently unsafe) files and local files opened by the user's explicit request.
Having an option to open "safe" files.
The use of a single set of bindings for internal URIs and external URIs.
Having a mechanism to open documents using internal URIs from a web page.
Automatically installing applications, applets, or plugins after downloading.
None of these are as bad as ActiveX, but they're all fundamentally wrong.
My proposed fix would be:
1. Create a second set of bindings like LaunchServices, or within LaunchServices, to be used by applications opening unsafe content.
2. By default, only applications that are designed to be secure against attack will be in this "WebServices" set of bindings.
This means that any application looking for a helper application to open (for example) a PDF in a web page will always get "Preview", even if the user prefers "Joes Insecure DPF viewer" locally, unless the user explicitly requests otherwise.
This means that any application looking for a helper application to open a "Zip" file will get "BOMArchiver" from LaunchServices, but could get "Secure Unzip" from WebServices.
This means that opening a RTF file from a web browser could get you "TextEdit", but you could use Microsoft Word for your own files.
There would be this unmistakable distinction between "applications designed to handle untrusted content" and "applications that might run scripts"... after all, you DO want to be able to run scripts as well as applications from Finder.
Posted by: Peter da Silva at May 9, 2006 09:54 AM
"The Mac web browser, Safari, can tell the difference between a file and a program, and alerts you whenever you’re downloading the latter."
So does Internet Explorer!
And I've still had to clean up computers from people who downloaded and ran a program from IE. Multiple times, sometimes, yes, the same people! Yes, they saw the "this is a program" dialog. Yes, they ran it anyway.
Dialogs are not a solution.
Don't stop and ask the user "I'm going to do something that may be stupid, should I do it?".
Don't do the stupid thing in the first place.
I've *never* had anyone say "Peter, I downloaded a program to the desktop, and ran it, and now I think I may be infected" more than once. Ever. Because downloading a file and opening it are far enough apart that there isn't the reflex "another stupid dialog, hit OK" reaction that the virus writers depend on.
Posted by: jacob at May 12, 2006 03:38 AM
http://docs.info.apple.com/article.html?artnum=303737








Ouch.
But you're still an asshole.