Slashdot Log In
Flaw Found in Apple Bug-Fix Tool
Posted by
ScuttleMonkey
on Wed Jan 10, 2007 02:02 PM
from the month-of-bug-creation dept.
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."
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.'"
[+]
Month of Apple Fixes 177 comments
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."
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
Loading... please wait.
A HA! (Score:5, Funny)
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]
Well, well, well (Score:3, Funny)
Errr... (Score:4, Informative)
So far MOAB has released 2 bugs for QuickTime, 1 for iLife, 1 for DiskManagement/diskutil, and 1 for Finder.
Instead ... (Score:5, Funny)
Technology needs more catchy acronyms
MOAB (Score:3, Funny)
I might be missing something, but.... (Score:3, Insightful)
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
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.
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).
Parent
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.
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).
Bugs in apples.. (Score:4, Funny)
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.
Re:Story at 11 (Score:5, Insightful)
Parent
Re:Story at 11 (Score:5, Insightful)
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.
Parent
Re:Story at 11 (Score:4, Insightful)
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.
Parent
Re: (Score:3, Insightful)
No, the price of using a computer is to patch it and not run untrusted software.
Bullshit. That's like saying the purpose of forks is to eat vegetables, and if some forks happen to create a toxic substance when they touch other substances, it is not a concern. People want to run untrusted binaries, because the majority of binaries people run are untrusted to some degree or another. When malware is common, it makes sense to make sure that untrusted binaries are restricted by default.
It does not matter w
Re:Story at 11 (Score:5, Insightful)
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.
Parent
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
The report talks about the ability to change permissions and then use those changed permissions to run programs as root. Maybe it's just me I'm pretty sure i
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.
Parent
Re: (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 w
Re: (Score:3, Informative)
Re: (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.