Slashdot Mirror
Flaw Found in Apple Bug-Fix Tool
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."
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]
Do Or Do Not, There Is No Spoon, There Is Only Zuul. Everything in the above post is probably opinion.
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?
So far MOAB has released 2 bugs for QuickTime, 1 for iLife, 1 for DiskManagement/diskutil, and 1 for Finder.
The Online Slang Dictionary
Rather than just tell people not to use APE, Landon Fuller (who reported this bug on his blog), should have written an APE SHell Investigative Tool to help people find and fix this error.
Technology needs more catchy acronyms
Crack - Free with every butt and set of boobs
From Anatomy of the Runtime MoAB Patches
...
------
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
So it's Linus' fault if Apache or Sendmail has a security problem?
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.
Menzoberranzan Networks
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 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.
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.
"Things are more moderner than before- bigger, and yet smaller- it's computers-- San Dimas High School football RULES!"
"No, the best they have to offer are vulnerabilities in quicktime, iPhoto, Disk Management, Finder which are apple products. Why CNet and slashdot chose to report on this particular vulnerability, which to many is the least important in the list, is a mistery to me."
Look, while they have included some legitimate bugs it's pretty obvious the project is flailing around somewhat, given that it's only the 10th of "MOAB". In addition to the APE flaw, they've included a VLC flaw and an OmniWeb flaw - neither of which is part of OS X nor installed on any stock Apple box. Additionally they've included a PDF flaw, which isn't even specific to OS X! That's just plain silly.
#DeleteChrome
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
so out of 10 days in this month so far only 4 have been Apple security bugs. So far 40% have been holes that are apple's fault.
I don't know about you, but if some one found a bug in Windowblinds, or some other Windows skinning app, and said it was MSFT's fault then I would be suspicious too.
Also there is a bug in VLC. how is a VLC player bug that is also found in the windows and linux versions an "apple" bug.
If it's an apple product by all means go for it. But no one blames MSFT for bugs in Lotus Notes.
i thought once I was found, but it was only a dream.
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 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 (a bookmark manager for Safari, in the form of a drawer).
When I find a bug in my apple, I throw it away..
I guess it depends if the purpose of publishing the bugs is to fix OS X, or whether it's to educate Apple users that just because you use OS X, you are not immune; it's possible (probable?) that somewhere on your system there will be vulnerabilities.
If you think that is the purpose of the MOAB then you're very, very optimistic, perhaps naive. The purpose is to gain publicity for a few, unscrupulous researchers. They've done this before with other vendors and even agreed to cancel one such project after being paid off. Apple users who know anything about security know there is the potential for security flaws, but they also know the potential is much less than if they are running Windows. Apple users and potential Apple who don't know anything, may be confused by this into thinking that OS X is no more secure than Windows and hence stay with Windows. The simple message "use a mac and you're unlikely to suffer from worms and viruses" is true and simple enough for most people. Complicating the message with, "but if you're using some third party utility, or even some included utilities there is the possibility someone could write a worm, but tso far no one has and they are unlikely to do so in the near future" is way too complex.
At minimum, it's a reminder that whilst OS X is more secure than Windows XP natively, it is not immune from vulnerabilities.
Finding vulnerabilities and not reporting them to the vendor or making them public until it will get you the most press, is detrimental to security and does more to help black hats than it does to help users. Trying to obscure and complicate the simple message that mac==more secure than windows, likewise is detrimental to overall security. The only thing this project is really accomplishing is publicity for themselves at the expense of everyone else. These guys are anti-security researchers. If they aren't willing to behave ethically, they can rot.
Upon further investigate, the Finder vulnerability is also pretty weak. It's at least got the potential to allow code execution (but not privilege escalation) and I agree that it's sloppy programming that should be fixed.
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.
The bug is that /Library/Frameworks is group-writable by users in the admin group.
/Library /System /Applications -perm -022
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.