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.
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
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
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.
When I find a bug in my apple, I throw it away..
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.