Flaw Found in Apple Bug-Fix Tool 168
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."
Errr... (Score:4, Informative)
So far MOAB has released 2 bugs for QuickTime, 1 for iLife, 1 for DiskManagement/diskutil, and 1 for Finder.
Anatomy of the Runtime MoAB Patches (Score:5, Informative)
------
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
Re:The problem isn't really 3rd party apps (Score:3, Informative)
The software has to be secure from top to bottom. If your PHP app has a security problem, it can do bad things on your machine no mather the OS.
Re:Story at 11 (Score:3, Informative)
I disagree with "at its best". The example "exploit" installs what basically amounts to a rootkit. So, in other words, this security "researcher" is distributing malware that gives him access to anyone's computer that accesses it. Since when do real security researchers distribute malware? More information is in the comments here [unsanity.org].
Not to mention he posted this thing with nothing but malice. It was done because Landon Fuller refused to work with LHM. LHM wanted to keep the bugs from the developers and said as a condition of such working together, that Landon Fuller must not tell anyone else about the bugs.
Sticking up for APE (Score:5, Informative)
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.
Apple Bug-Fix Tool? (Score:5, Informative)
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.
Re:Story at 11 (Score:3, Informative)
Summary to date... (Score:4, Informative)
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
InputManagers in general (Score:4, Informative)
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:Sticking up for APE (Score:4, Informative)
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:Story at 11 (Score:5, Informative)
But their report says that in trying to expliot the flaw their DMG failed validation test done before mounting the image and that they were therefore unable to create a working exploit. The rest of their report is based on the assumption that they could manipulate parts of the DMG file and bypass the validation already in place, without any real indication of how that might happen.
It's not an APE bug, it's a big Apple bug. (Score:5, Informative)
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
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.
Placing the blame in the right place... with Apple (Score:3, Informative)
Too many words. Let me fix that for you: The vulnerability is that
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
Re:Story at 11 (Score:1, Informative)
This "Apple bug" should be called "bug in a third-party kernel hack that you need to have admin privs to install in the first place".
These guys are really scraping.