Slashdot Mirror
Month of Apple Fixes
das writes "On the same day as the launch of the Month of Apple Bugs (MOAB) (blog), Landon Fuller, a programmer, Darwin developer, and former engineer in Apple's BSD Technology Group, has launched an effort to provide runtime fixes for each MOAB issue as they are released. A fix has already been posted for the first MOAB issue."
Kevin Finisterre, security researcher, founder of Digital Munition, and co-presenter of the Month of Apple Bugs, has also responded on the SecurityFocus focus-apple list to some of my concerns, expanding on some of the motivations and reasoning behing MOAB (followup).
Also, the second bug was just posted a few minutes ago: a udp:// URI handling vulnerability in VLC Media Player that affects both the Mac OS X and Windows versions of VLC Media Player. While not exactly what I'd call an "Apple bug" (yes, yes, I know the FAQ says they're also looking at "popular applications" that run on Mac OS X as well), it is interesting to note that vulnerabilities in cross platform applications may transfer more easily to the Intel-based Macs running Mac OS X...
In any event, Apple's immediate technical response and longer-term strategic response to MOAB should be interesting.
(Disclaimer: I am the story submitter.)
Apple products don't have bugs. They have worms.
You're suffering from some serious RTFA syndrome. By doing the patch the way he did you change NO SYSTEM FILES.
The acronym MOAB has already been taken http://en.wikipedia.org/wiki/Massive_Ordnance_Air_ Blast_bomb
To prevent confusion I propose it should be Apple Month of the Bugs. AMOB
All this is a little fun exercise and a public service, if you will. Also, anyone can examine the code.
How do you uninstall these quick fixes? Simple. They'll almost all invariably be runtime fixes with Application Enhancer (APE). APE modules are just self-contained directories; nothing more. They can be unloaded on demand, and APE itself can be easily installed, uninstalled, disabled, and modules can be loaded and unloaded at will.
Also, Landon Fuller is anything but an "Apple fanboy", or in any way remotely interested in "saving Apple's rep". The idea is to look at the bugs, and see if a quick technical solution or remediation can be provided. No one has to install them. Since the code is available, anyone can see what's being done, including the rest of the community. If one wishes to wait for Apple's official patches, fine.
Aside from all of this, of course Mac OS X, like any other operating system or large software project, has bugs. Some of these bugs will enable vulnerabilities that can be exploited. I fail to see how any of this is surprising. If you're actually interested, I've summed up my thoughts on this here.
If I have time, or if people help me.
I tested thoroughly on Intel and PowerPC Macs. I wouldn't release a fix to the world without being fairly certain that it works correctly. You're welcome to review the code for the first fix -- it's about 10 lines. I'd be happy to explain the various entry points for you, too. We're using these fixes on all our Macs here at Three Rings Design.
Alternatively, you can not use the patch. I won't mind.
You open the Application Enhancer pref pane and hit the "-" (minus) button.
http://plausible.coop
See above posts, maybe even RTFA... then RTFSC. All 10 lines of it. Cheers.
Sorry... that acronym is already taken:
AMOB Anna Maria Oyster Bar (Bradenton, FL)
AMOB Automatic Meteorological Oceanographic Buoy
You should try an acronym that is totally original, like:
Exploits & bugS from aPple moNth
I realize that the idea is just catching on in IE and has not been implemented anywhere else, but why doesn't Safari setuid() the rendering engine to guest (or some other nonprivileged user)?
Is this feature in the works? I certainly hope so.
Nice pic of the unabomber sketch on the release page... quite telling.
Cwm, fjord-bank glyphs vext quiz
From the other thread, it appeared that no Mac owner posted saying that they had been able to replicate the results - the people that did post results said the quicktime file given crashed Quicktime, but did not run the payload target. Simply being able to crash an application is not the same as actually executing arbitrary code.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Absolutely -- but I'd still strongly suggest disabling the QuickTime RTSP component:
http://isc.sans.org/diary.php?storyid=1993
You forgot number 4:
4. Have my professional and personal reputation permanently sullied.
I'll pass! =) The code is up for review, but if you don't feel comfortable with my fix, you can disable the primary attack vector by following the directions from the SANS web site.
http://plausible.coop
So
[simon:~] simon% vlc
tcsh: vlc: Command not found.
[simon:~] simon% perl VLCMediaSlayer-x86.pl
jump address is: 0x41424344
writing to file: pwnage.m3u
[simon:~] simon% open pwnage.m3u
[simon:~] simon% (opens iTunes)
the application for this second bug is not even shipped on Mac's by default! Meaning that this completely 3rd-party software, if installed onto a Mac, can cause problems with the Mac. And this is Apple's problem how, exactly ?
Simon
Physicists get Hadrons!
See here for details.
Ugh. :-(
APE isn't going to be necessary for ANY fixes from Apple. Apple will release their fixes in due course, and they'll be like all their previous fixes have been: normal updates to the OS that come down via Software Update, etc.
But since we can't directly fix Apple's code, this is a little technical exercise that fixes them with runtime patches. One very easy way to do runtime patches and code injection such as this is to use APE.
Also, APE is *very* easy to uninstall. It has its own uninstaller right in the installer, which will, categorically and definitely, uninstall every single last thing that has anything to do with APE.
Also, there is nothing wrong with APE, and here is a very detailed explanation of exactly what APE is and what it does.
All this project is is just that: a project. The community is welcome to inspect all of the source code, and anyone is free to use these runtime patches. Yes, QuickTime, and VLC, and everything else that will be covered in MOAB will be fixed by Apple and the various applicable vendors/developers. That is not at all the point of providing on-demand runtime fixes each day, and you have apparently totally missed the point of this projects, and the post you responded to where I pretty concisely explain it.
I was going to use a stronger word, but my New Years resolution is still (diminishingly) in effect...
... wrong. I can't think how you could think that. It's hard to construct an argument when your starting premise is just nonsense.
:-) that QT doesn't support the codecs that you want, but it's not Apple's fault that other 3rd-party codecs have bugs in. Yes, I'm a Mac fan, but not a fanboy - I completely agree with bug #1, but this is just completely ... bogus.
If Apple don't supply a piece of software, it is *not* their fault that there can be subsequent problems using that piece of software, it's the program-author's fault. Obviously vlc isn't completely necessary (otherwise I would have it installed, I install a fair amount of linux-related s/w). I do have windows-media player and realmedia player installed...
To say that just because Apple don't supply a particular feature (viewing movies that require codec XXX), it's Apple's problem when you install 3rd-party software that does is just
By the same logic, it's Apple's fault that:
- I can't run my FPGA-mapping software on my Mac Pro, because Xilinx don't support the Mac. Apple ought to do something.
- I can't run any game I want on the Mac. Curse those game-producing companies, oh no, wait, it's Apple's fault.
- My Mac doesn't make toast! How simple is making toast? Apple ought to pull their finger out!
- ad nauseum.
Install 3rd-party software, have problems with that software, blame the software author. Don't blame the machine manufacturer / operating-system provider.
Moan like buggery (*) (hmm, unfortunate turn of phrase
Simon
(*) "Moan like buggery" isn't really rude where I come from, oddly enough...
Physicists get Hadrons!
I realize that the idea is just catching on in IE and has not been implemented anywhere else, but why doesn't Safari setuid() the rendering engine to guest (or some other nonprivileged user)?
First, let me make one point clear. This is not "just catching on in IE", it has been used for running potentially exloitable applications in UNIX for decades. It's a last resort when applied to interactive programs... it's usually used with applications that are running unattended and providing services to the outside world... and the limitations of this kind of technique are abundantly clear. UNIX environments typically take this kind of thing several stages further, using chrooted environments and jails to really isolate the untrusted code from the rest of the system.
Second, Security is like sex, if you're penetrated you're fucked. Just because an exploit in IE can only have an effect on resources owned by a restricted user should not be considered a big deal. Why?
(1) Once you can run local native code, you're in a MUCH better position to devise a secondary exploit against a local privilege escalation vulnerability.
(2) Resources accessible to Internet Explorer include (of necessity) any security tokens (passwords, etcetera) used for access to online services, as well as anything else that you use the same tokens for... like, say, your local account.
I've repeatedly argued that the fact that the local user runs with lower privileges on Mac OS X than on Windows is not nearly as important as Mac fanatics make out. Well, the converse is true... this new hack Microsoft has come up with to avoid facing the security flaws in the design of IE isn't nearly as importantas Microsoft apologists make out.
In the sense that it affects Apple machines, sure.
But, yeah, it's kind of weak. If this is the best they can come up with, Apple can rest easy.
Clear, Dark Skies