Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Security Businesses Apple

Flaw Found in Apple Bug-Fix Tool 168

Posted by ScuttleMonkey from the month-of-bug-creation dept.
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.

Flaw Found in Apple Bug-Fix Tool More

Flaw Found in Apple Bug-Fix Tool

Comments Filter:

  • A HA! (Score:5, Funny)

    by Thansal ( 999464 ) on Wednesday January 10, 2007 @01:07PM (#17542838)
    I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards.


    I see it now. This entire MOAB thing is just there to tout how great and secure Apple Products are, and that the only bugs possible HAVE to come from 3rd party software!

    It is all a plot by Jobs!

    A PLOT I TELL YOU!

    [/psycho]
    • Really, though, this is lame. Another third-party bug? Pointing out third-party bugs is great, but this was touted as a month of Apple bugs to point out insecurities that needed to be fixed in Apple software. Widening that to third-party bugs is a little disingenuous and misleading.
    • Every few weeks another exaggerated headline of another Apple security "hole" is posted. In every case, closer examination reveals that the hole really isn't a hole at all, and it requires physical access to the machine, etc.

      From TFA:

      "The vulnerability is real--it is possible for a local administrator account on the computer to gain root access, without any user confirmation, by replacing pieces of Application Enhancer's installation," said Fuller in his blog. "While this cannot be exploited remotely, it c

  • Well, well, well (Score:3, Funny)

    by Anonymous Coward on Wednesday January 10, 2007 @01:09PM (#17542880)
    What do you have to say for yourselves now, Apple fanboys? With this glaring bug, coupled with the other devastating bugs, it now is clear that your smug castle is crumbling. Maybe it's time to give the rock-solid Vista another chance, no?

    • Re: (Score:2)

      by Xugumad ( 39311 )
      I dunno, I'm not sure paranoid and twitchy is an improvement in OS terms :)

      (Vista really does seem terrified that someone else might be touching your computer)
    • Hell, Windows depends on this bug. The bug is... Apple left parts of /Library writable. Microsoft requires that every user have write access to parts of the system file tree to handle things like printing and web-page caching. Instead of fixing that, they've added a subsystem to monitor it and undo changes to system files... and of course there are viruses that use that subsystem to hide in so they get put back after they're removed by AV tools.

      But more importantly, in Windows everyone runs as a member of L

  • Personally I think (Score:2, Insightful)

    by 0racle ( 667029 )
    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.
    Personally I think that the reason most/all of the bugs released are 3rd party apps and not OS X itself is that the people running the project are to lazy to try and find some actual Apple bugs.

  • Errr... (Score:4, Informative)

    by WalterGR ( 106787 ) on Wednesday January 10, 2007 @01:11PM (#17542906) Homepage

    Note that this is third party software that all of the bugs seem to be stemming from.

    So far MOAB has released 2 bugs for QuickTime, 1 for iLife, 1 for DiskManagement/diskutil, and 1 for Finder.

    • 5 Bugs on 4 Apple products, 3 of these products that come default with the OS. 2 of these products are Core to the OS. and only one of these products a User can't use a mac without. 10 Days in. That is still darn good. The point is all these 3rd party apps that are being added to the list to make Macs look insecure, give me an Open BSD system, then install some 3rd party apps, misconfigure Open SSH, and bang it is not as secure as it use to be. I was expecing by this point to be 20-30 bugs found just on

      • Re: (Score:2)

        by e4g4 ( 533831 )

        2 of these products are Core to the OS

        Well, not exactly. Since you didn't say which, I'm going to assume that you mean 2 of the following 3: Quicktime, Finder, and DiskManagement.framework. Quicktime is just an app with a set of codecs and some plugins (all removable). Finder is just an app, and while the method for doing so is not GUI accessible, you can in fact turn it off and use something else (i.e. the terminal, or PathFinder). DiskManagement.framework is just an API for easier/higher level access (higher than say mount or umount) to d

        • Well I did mean Finder and Disk Manager. Finder is the general tool used to manage the UI. It may not be a kernel module or irreplacable. But to keep OS X OS X Finder is a Core Application. It runs after boot automaticly code is there to make it difficult to throw it away, It is core for a GUI OS. The DiskManager while not as nessary as Finder is still and important tool for maintaing the OS. As well used for basic OS Work such as burining ISOs, creating Disk Images. A lot of things that OS X wants you do
    • And also note that the OS is supposed to be secure, which means 3rd party stuff shouldn't be leaving the entire OS exposed like this without the user doing something very stupid and intentional.

      I don't by the 3rd party thing as an excuse... and I AM an Apple fanboi

  • Instead ... (Score:5, Funny)

    by Salvance ( 1014001 ) * on Wednesday January 10, 2007 @01:12PM (#17542930) Homepage Journal
    Rather than just tell people not to use APE, Landon Fuller (who reported this bug on his blog [bikemonkey.org]), should have written an APE SHell Investigative Tool to help people find and fix this error.

    Technology needs more catchy acronyms

  • MOAB (Score:3, Funny)

    by dr_strang ( 32799 ) on Wednesday January 10, 2007 @01:20PM (#17543058)
    Does that make it the Mother Of All Bugs?

  • I might be missing something, but.... (Score:3, Insightful)

    by 8127972 ( 73495 ) on Wednesday January 10, 2007 @01:21PM (#17543076)
    Why would anyone who is serious about computer security use a THIRD PARTY app to fix a security issue?

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      You wouldn't. These third-party fixes are being done as an intellectual exercise, not a serious offering.

  • Anatomy of the Runtime MoAB Patches (Score:5, Informative)

    by shawnce ( 146129 ) on Wednesday January 10, 2007 @01:38PM (#17543362) Homepage
    From Anatomy of the Runtime MoAB Patches [bikemonkey.org]

    ------

    01:04 Tue, 09 Jan 2007 PST -0800
    Anatomy of the Runtime MoAB Patches

    Introduction

    For the past few days I've been releasing patches for software vulnerabilities in an assortment of Mac OS software. This project was intended to be a technical one, and I've never sat down to explain, in clear terms, how the patches work, what Application Enhancer is, or what the potential risks are in running these patches. I'm also not the first one (not by a long shot) to think of implementing third party patches for unpatched software vulnerabilities, either, and I'd like to discuss those efforts.

    Here goes ...

    Third Party Patches, Past and Present

    Generally speaking, a software vulnerability is usually announced in coordination with a vendor-supplied software update. However, there are cases when a vendor patch is not available for a critical software vulnerability, leaving the user with limited options. Relatively recently, the idea of a "third party patch" has emerged; when a vendor patch is not available, a third party can reverse engineer the software in question and produce a temporary bug fix.

    This technique has previously been used for both unpatched Windows and Mac OS X vulnerabilities. In 2006, Alexander Sotirov presented "Hotpatching and the Rise of Third-Party Patches" at the Las Vegas Black Hat conference, and is responsible for implementing two patches for unfixed Internet Explorer vulnerabilities. ZERT (Zero-day Emergency Response Team), who is composed of an impressive array of individuals, "work(s) together as a team to release a non-vendor patch when a so-called '0day' (zero-day) exploit appears in the open which poses a serious risk to the public, to the infrastructure of the Internet or both." On the Macintosh, Unsanity released Paranoid Android, a run-time patch for a critical vulnerability in Mac OS X's document handling. I believe the award for the first third party Windows patch for an unfixed vulnerability goes to Ilfak Guilfanov's December 2005 WMF patch. Guilfanov is the author of the excellent IDA Pro disassembler and debugger.

    Risks and Benefits of Third Party Patches

    A vendor-supplied update is always preferable to a third party patch. Third party patches are created by reverse engineering the vulnerable code, and are subject to limited testing and potential implementation deficiencies -- like the author of the vulnerable software, patch implementors are human, too. It is always possible that a bug in the patch could result in instability, or potentially expose a new exploit scenario.

    On the other hand, a third party patch can provide protection against a critical vulnerability before the vendor is able to implement, test, and release a fix. The decision to use a third party patch should be made after a careful assessment of the vulnerability's risks and your own requirements -- it's never unreasonable to wait for an officially provided vendor fix.

    Patching (more) Safely with Application Enhancer

    The patches we've provided have all been implemented using Unsanity's Application Enhancer, and are "run-time patches" -- the patches insert themselves into applications at runtime, find the vulnerable code, and apply a band-aid. Nearly all of the patches released so far work by wrapping the vulnerable code and providing additional data validation, rejecting data that would otherwise cause the vulnerable code to malfunction (and thus allow the exploit to succeed). There are other options for implementing run-time patches on Mac OS X, including the open source mach_star -- I've previously used mach_star to implement runtime security patches for software on my own Mac. However, for the purposes of providing these fixes, I decided upon Application Enhancer.

    Application Enhancer provides a nice, easy to use GUI for installing Applicati

  • Sticking up for APE (Score:5, Informative)

    by usermilk ( 149572 ) on Wednesday January 10, 2007 @01:45PM (#17543466)

    The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins. So a local admin can replace the APE executable and gain root privileges. Read that again. A local admin can replace the APE binary to gain root access.

    A local admin, an effective root user account, can gain root access.

    Or they could open up NetInfo Manager and enable the root account and enter in a password of their own choosing and then log into the GUI as root. Or they could open up Terminal and run sudo sh and get a root shell.

    This is simple revenge. Rosyna called them trolls [unsanity.org] and linked to an APE fix for one of their bugs. I think Rosyna may be right of the 9 published bugs, 4 of them are not from Apple provided software.

    • Re:Sticking up for APE (Score:4, Informative)

      by ioErr ( 691174 ) on Wednesday January 10, 2007 @02:08PM (#17543880)
      The problem is not that a malicious admin can gain root access -- of course he can, as you pointed out. No surprise there.

      The problem is rather that a trojan or similar run by a clueless admin can gain root access without the user being prompted for his password. Most Mac home users do use an admin account for day-to-day work, and think that they'll be fine. So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.

      Personally I've solved this by using a normal user account that's added to sudoers. I can wreak full havoc on my machine when I want to, without having to log in as my admin account, but can't do so unknowingly (I hope).

      • Re: (Score:2)

        by Rosyna ( 80334 )
        The problem is rather that a trojan or similar run by a clueless admin can gain root access without the user being prompted for his password.

        You do realize there are about 50 brazillion ways to do this, correct?

        Either way, as soon as you're running malicious code, you're already screwed. A malicious application does not need to be root to destroy your photos, movies, pornography or other personal documents. You should never run applications from a source you do not trust.

        • Re: (Score:2)

          by ioErr ( 691174 )

          You do realize there are about 50 brazillion ways to do this, correct?

          Indeed, which is why the default configuration for Macs is so troublesome. We may mock Windows users for having to run as admins to get their poorly written software to work, but most Mac users run as admins out of ignorance, because that's just the way the default configuration is. Or was, the last time I installed OS X at least, but I hope I'd heard if things had changed.

          Either way, as soon as you're running malicious code, you're already screwed. A malicious application does not need to be root to destroy your photos, movies, pornography or other personal documents.

          At least with a non-root the damage is localized to one account. Daddy's porn may be gone, but his daughter's homework (and porn) is s

        • Either way, as soon as you're running malicious code, you're already screwed.

          Not to minimize the problem (and it IS a real problem) but this is important.

          Security is like sex. Once you're penetrated you're fucked.

          You should never run applications from a source you do not trust.

          Don't forget to turn off "Open 'Safe' Files After Downloading" in Safari.
      • The problem is not that a malicious admin can gain root access -- of course he can, as you pointed out. No surprise there.

        A malicious application running as an "admin" should not be able to gain root access.

        No wonder Apple didn't care that aliases bypass traverse checking. That's a *minor* problem by comparison.

        So the real problem is either that too many Mac users are running as admin, or that admin users have too broad write permissions without using sudo.

        The real problem is that admin users have too broad
    • The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins.

      Too many words. Let me fix that for you: The vulnerability is that /Library is writable by local admins.

      Even if you don't install APE on your system, an attacker who has the ability to execute this exploit can simply drop an input manager or other plugin into /Library and piggyback their way to root on any privileged application.

  • Apple Bug-Fix Tool? (Score:5, Informative)

    by Aqua OS X ( 458522 ) on Wednesday January 10, 2007 @01:49PM (#17543524)
    An Apple Bug-Fix Tool? Err, um, no and no.

    APE is developed by Unsanity and it's not a "bug fix tool."
    It's a third party framework and daemon used for a number of thing.

  • Summary to date... (Score:4, Informative)

    by shawnce ( 146129 ) on Wednesday January 10, 2007 @02:01PM (#17543756) Homepage
    Note that this is third party software that all of the bugs seem to be stemming from.


    This statement doesn't make sense. The MOAB issues outlined to date have been a combination of Apple and 3rd party issues. See the following break down...

    MOAB #1 - Apple issue
    MOAB #2 - 3rd party issue
    MOAB #3 - Apple issue
    MOAB #4 - Apple issue
    MOAB #5 - Apple issue
    MOAB #6 - Apple and 3rd party
    MOAB #7 - 3rd party issue
    MOAB #8 - Apple and 3rd party
    MOAB #9 - Apple issue

    • How is number 8 an Apple issue? It is an overflow in a third party application.

      • Re: (Score:2)

        by shawnce ( 146129 )
        Issue #8 [info-pull.com] is not an overflow issue (buffer overrun I assume you mean).

        #8 involves APE (Unsanity folks could make some changes to help avoid the issue) however IMHO the core of the issue is with file permissions that Apple has defined for various directories under /Library that Apple recommends 3rd parties install software into. That is why I outlined that it is a 3rd party and Apple issue.

        • IMHO the core of the issue is with file permissions that Apple has defined for various directories under /Library that Apple recommends 3rd parties install software into.

          The security hole is in APE. The fact that you disagree with Apple's permission choices is pretty irrelevant. OS X does not stop Adobe Acrobat from being installed either, does that mean any hole in that reader is also partially Apple's fault?

          • Re: (Score:2)

            by nathanh ( 1214 )

            The security hole is in APE. The fact that you disagree with Apple's permission choices is pretty irrelevant.

            It's not a disagreement. Apple's default permissions on that directory are plain wrong. APE is just an example application that proves the point. The actual fault lies with Apple.

            I think the real problem here is that the MOAB deniers are woefully ignorant of the problems. They think they can make up for their woeful ignorance with chest-beating. I've been nothing but disgusted with the Mac co

            • Re: (Score:3, Insightful)

              by 99BottlesOfBeerInMyF ( 813746 )

              Apple's default permissions on that directory are plain wrong. APE is just an example application that proves the point.

              This is just wrong. The framework file is installed by a third party application, which sets the permissions. Giving administrators the right to set permissions is a design choice, and arguably a bad one, but it is not a bug in and of itself.

              I think the real problem here is that the MOAB deniers are woefully ignorant of the problems.

              Deniers? What the project isn't happening? I'm pis

              • Re: (Score:2)

                by nathanh ( 1214 )

                Take a look at my posting history.

                I have. And my estimation of your worth has diminished considerably.

                I blame the MOAB guys because their disclosure is about as irresponsible as you can get. Intentionally providing a vendor who acts in good faith with no advance notice

                Your factiness is compelling. Unfortunately the facts disagree with you. Despite your claim that these guys aren't notifying Apple of these bugs in advance, they claim that they have, and I find them a whole lot more convincing t

                • I'm not going to address your points one by one, because I don't have the time and they don't deserve it. Some of the items you reply to were not even in my post. But I thought I'd address your conclusions.

                  Apple? I see complacency and rhetoric and outright deception . Then I see ignorant - yes, I think you are ignorant - pundits such as yourself who would attack the messenger rather than admit there's a problem.

                  Ahh, a problem eh? How many Macs have been compromised this year by worms? Oh yeah that would

              • This is just wrong. The framework file is installed by a third party application, which sets the permissions.

                % ls -ld /Library
                drwxrwxr-x 56 root admin 1904 Dec 27 16:07 /Library
                % open -s "Disk Utility"
                (pause for repair disk permissions)
                % ls -ld /Library
                drwxrwxr-t 56 root admin 1904 Dec 27 16:07 /Library
                % ls -l /Library
                [...]
                drwxrwxr-x 4 root admin 136 Sep 12 12:09 InputManagers
                drwxrwxr-x 19 root admin 646 Dec 15 12:16 Internet Plug-Ins
                [...]
                drwxrwxr-x 11 root admin 374 Dec 28 18:45 PreferencePanes
                [...]
                %

  • InputManagers in general (Score:4, Informative)

    by Lord Grey ( 463613 ) * on Wednesday January 10, 2007 @02:07PM (#17543874)
    For those of you who don't know about APE: There exists in the OS X framework this concept of enabling alternate input mechanisms for already-installed applications. The mechanism is the InputManager. A properly-constructed bundle is simply copied to a designated location and the OS will happily load it whenever an application is launched. The bundle is loaded as part of the application, and the bundle has access to the application's internals. Some good information on InputManagers can be found on CocoaDev [cocoadev.com].

    The "designated location" is actually one of several: /Library/InputManagers/ or ~/Library/InputManagers/. In other words, it doesn't take special privileges to make an InputManager bundle active on a given system for a specific user. You do have to have admin privileges to place the bundle into /Library/InputManagers/ so that all applications executed by all users are touched, but that's it.

    Objective-C lets objects of one class "pose" as objects from another class. Posing is like dynamic subclassing; method dispatch happens against your class first and then on up to the original class if you didn't implement it or if your method specifically calls the "parent." This is where code injection comes in. You write a new class that poses as some class in the application and intercept the calls; your code starts executing.

    Figuring out the application's classes isn't difficult. A free utility like class-dump [codethecode.com] can be used to grab an OS X application's class and data structure definitions, and from there it's easy write your own posing classes. Lots of bugs arising from injected code is due to sloppiness on the part of the programmer, and some of it is due to an InputManager modifying an application's data at the wrong time (which is easy to do, because the application rightfully believes that it owns its data).

    I was going to write something about the security issues this entire scheme raises, spelling out how a nefarious programmer could hijack passwords and the like. I'll leave that to your imagination, though.

    Shameless plug: While I didn't use APE, I did use InputManager technology in order to create Concierge [bti.net] (a bookmark manager for Safari, in the form of a drawer).

    • Re: (Score:2, Insightful)

      by TheUser0x58 ( 733947 )

      Not quite... InputManager only works with Cocoa applications, as the CocoaDev page you cited mentions, and class posing will only work with parts of applications written using Objective-C classes.

      APE uses mach_inject and mach_override to actually patch new code into applications loaded into memory. This works at the kernel level and thus is framework and language agnostic.

      • You are quite right about APE's implementation. I plead guilty to thinking I knew more about APE's internal structure than I actually do. I have to say, though, that using mach_inject and mach_override to patch code is somewhat scarier than using Objective-C's dynamic dispatching when you take into consideration that APE supports a plug-in methodology.

        Thanks for the clarification!

  • Bugs in apples.. (Score:4, Funny)

    by FrostyCoolSlug ( 766239 ) on Wednesday January 10, 2007 @02:10PM (#17543930)
    When I find a bug in my apple, I throw it away..
  • I suggest for the next few thing on this topic:

    MOSES

    BALAAM ;)

  • Wow! (Score:2, Insightful)

    by Cervantes ( 612861 )
    " I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards."

    So, when Apple does it, it's OK, but when Microsoft does it, they've obviously made a flawed system and deserve to be beaten about the head with an office chair?

    I know this is /. , but I have a relatively high user ID, so I just want to be sure I understand the logic...

    • Re: (Score:2)

      by argent ( 18001 )
      No, this one Apple needs to be nailed to the wall on. Leaving parts of the system writable as admin means that you're a quick framework patch away from being root... which means being in admin is almost as dangerous as being in the Local Administrators group on Windows. Not that that stops anyone from running as Local Administrator on Windows.

      http://apple.slashdot.org/comments.pl?sid=216122&c id=17546398 [slashdot.org]

      Not to mention Adobe and everyone else who shows up when you run that find command.
  • "I guess Apple has made a fairly secure system but they can't expect all third party developers to follow the same rigorous standards." That's about right. *stares long and hard at Javascript and Flash*

  • In the words of Walter Sobchak: (Score:3, Funny)

    by Night Goat ( 18437 ) on Wednesday January 10, 2007 @03:50PM (#17545742) Homepage Journal
    "Fuck it dude, let's go bowling."

    Reading that summary as a Mac user, I just can't be bothered to sort all of this out.
  • The bug is that /Library/Frameworks is group-writable by users in the admin group.

    ANY application run setuid, or any framework or plugin used by any application run setuid, could have been used to demo it. It's got nothing to do with APE. This is no different from the many privilege escalation issues in Windows caused by writable executables and system directories.

    To tell if your Mac is susceptible to this kind of privilege escalation attack, run this command:

    find /Library /System /Applications -perm -022

    If there are no results, then your system is probably safe. If there are more than a few results, then you're likely vulnerable.

    Try it and see.

    • Re: (Score:2)

      by dedazo ( 737510 )
      Hookay, I can see this in my MacBook. How do you fix it manually? By resetting the permissions? Won't that break something else?
    • You may not even need to be admin.

      Try "find /Library /System /Applications -perm -02". Any files or directories that show up there are world writable.
  • 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."

    Quicktime, Finder and iPhoto are third party now?

    I guess the kernel is also third party by zealot logic then - or at least it will be after they start publishing the kernel level exploits. Kind of like what happens after a proof of concept virus gets announced for OSX - the zealots simp
  • This is like building a list of windows bugs and submitting a norton product as an exhibit. If this is the week of APPLE bugs, why are we hearing about macintosh software developers? Must be slim pickins in Mac OS X for security holes?? I thought they were going to post some real apple bugs? This is very disappointing, though I suppose it's nice to see they are having this problem.
    • This is like building a list of windows bugs and submitting a norton product as an exhibit.

      This is not a flaw in APE. Any existing plugin or a new plugin could have equally well been used. The flaw is that /Library is writable... and in investigating I've found that even after "fixing permissions" there's an awful lot of /Library that's not just writable by administrators... but by anyone.

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close