Stories
Slash Boxes
Comments

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Month of Apple Fixes

Posted by kdawson on Tue Jan 02, 2007 05:33 PM
from the mister-fixit dept.
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."
+ -
story

Related Stories

[+] Month of Apple Bugs - First Bug Unveiled 240 comments
ens0niq writes "The first bug (a Quicktime rtsp URL Handler Stack-based Buffer Overflow) of the Month of Apple Bugs has been unveiled — as previously promised — by LMH and Kevin Finisterre. From the FAQ: 'This initiative aims to serve as an effort to improve Mac OS X, uncovering and finding security flaws in different Apple software and third-party applications designed for this operating system. A positive side-effect, probably, will be a more concerned (security-wise) user-base and better practices from the management side of Apple.'"
[+] IT: Hackers Disagree On How, When To Disclose Bugs 158 comments
darkreadingman writes to mention a post to the Dark Reading site on the debate over bug disclosure. The Month of Apple Bugs (and recent similar efforts) is drawing a lot of frustration from security researchers. Though the idea is to get these issues out into the open, commentators seem to feel that in the long run these projects are doing more bad than good. From the article: "'I've never found it to be a good thing to release bugs or exploits without giving a vendor a chance to patch it and do the right thing,' says Marc Maiffret, CTO of eEye Security Research, a former script kiddie who co-founded the security firm. 'There are rare exceptions where if a vendor is completely lacking any care for doing the right thing that you might need to release a bug without a patch -- to make the vendor pay attention and do something.'"
[+] Flaw Found in Apple Bug-Fix Tool 168 comments
eldavojohn writes "The Month of Apple Bugs (MOAB) is well under way with a startling bug released Monday. From the description: 'Application Enhancer (APE) is affected by a local privilege escalation vulnerability which allows local users to gain root privileges.' APE is the same software used to deploy fixes during 'The Month of Apple Fixes' (MOAF). I know it's confusing but MOAB came first and MOAF was a developer's answer to the bugs — after all, the purpose of posting bugs is to have them identified, confirmed and eradicated. The article talks about potential remote root access by an intruder. Note that this is third party software that all of the bugs seem to be stemming from. I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Kevin Finisterre, security researcher, founder of Digital Munition [digitalmunition], and co-presenter of the Month of Apple Bugs [info-pull.com], has also responded on the SecurityFocus focus-apple list [securityfocus.com] to some of my concerns [securityfocus.com], expanding on some of the motivations and reasoning behing MOAB (followup [securityfocus.com]).

    Also, the second bug was just posted a few minutes ago: a udp:// URI handling vulnerability in VLC Media Player [info-pull.com] 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.)
    • by 0racle (667029) on Tuesday January 02 2007, @05:46PM (#17436054)
      Month of apple bugs over in one Bug? They had to go to an application already? Also, who would have known, an application writer that makes a mistake on one platform might make that same mistake on another.
    • Re: (Score:2, Insightful)

      Man, they're really scraping the bottom of the barrel, and it's only January 2nd! A string handling vulnerability in a cross-platform app I've never heard of? They should at least have been able to make it to the end of the BCS before resorting to filler like that.
      • On one hand you're right. On the other hand, if you've never heard of vlc, you've been living under a fucking rock.
        • by Otter (3800) on Tuesday January 02 2007, @06:16PM (#17436380) Journal
          See, the point of switching back to Mac from Linux for recreational desktop use is that I just click on files and they play. If I wanted abuse for not being familiar with some media player minutia, I'd still be in #mplayer trying to figure out what to install to view a WMV.
          • Re: (Score:3, Insightful)

            WMVs played out of the box on your Mac? You didn't need Flip4Mac or anything else? How did you manage that, then?
    • by Space cowboy (13680) * on Tuesday January 02 2007, @06:31PM (#17436554) Journal
      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
        • by Space cowboy (13680) * on Tuesday January 02 2007, @08:23PM (#17437730) Journal
          I was going to use a stronger word, but my New Years resolution is still (diminishingly) in effect...

          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 ... wrong. I can't think how you could think that. It's hard to construct an argument when your starting premise is just nonsense.

          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 :-) 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.

          Simon

          (*) "Moan like buggery" isn't really rude where I come from, oddly enough...
    • See here [videolan.org] for details.
  • Thank you, Landon.
  • by PurifyYourMind (776223) on Tuesday January 02 2007, @05:44PM (#17436040) Homepage
    Apple products don't have bugs. They have worms.
  • privsep? (Score:3, Interesting)

    by emil (695) <cfisher&rhadmin,org> on Tuesday January 02 2007, @06:00PM (#17436216) Homepage

    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.

    • Re: (Score:3, Insightful)

      You could probably try doing this yourself:

      chown unknown /Applications/Safari.app/Contents/MacOS/Safari
      chmod u+s unknown /Applications/Safari.app/Contents/MacOS/Safari ...and you'll probably need to also change the following:

      chown -R unknown ~/Library/Caches/Safari
      chown -R unknown ~/Library/Safari
    • 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
  • Unabomber. (Score:3, Informative)

    by CODiNE (27417) on Tuesday January 02 2007, @06:07PM (#17436294) Homepage
    Nice pic of the unabomber sketch on the release page... quite telling.
  • by SuperKendall (25149) on Tuesday January 02 2007, @06:15PM (#17436370)
    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.
    • Re: (Score:2, Insightful)

      You're suffering from some serious RTFA syndrome. By doing the patch the way he did you change NO SYSTEM FILES.
    • 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) [unsanity.com]. 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 [securityfocus.com].
        • 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 [unsanity.org].

          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.
    • by landonf (905751) <landonf@plausible.coop> on Tuesday January 02 2007, @05:51PM (#17436120) Homepage
      So some third party is going to try to rush out daily fixes?

      If I have time, or if people help me.

      How much testing is done on these fixes, none?

      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.

      And how do you uninstall these quick fix hacks when Apple releases the legit fixes?

      You open the Application Enhancer pref pane and hit the "-" (minus) button.

    • I don't care who this guy is... I'm not downloading "fixes" for my iMac from anyone but Apple

      Absolutely -- but I'd still strongly suggest disabling the QuickTime RTSP component:

      http://isc.sans.org/diary.php?storyid=1993

      1. Go to MOAB site, record exploit info 2. Create malicious version of exploit 3. Post to web as a "fix" and tell users to blindly install

      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.

    • 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.