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?
"I use a Mac because I'm just better than you are."
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
Does that make it the Mother Of All Bugs?
This is a sig. It is like every other sig in the world, except that it is mine, and it is different.
Why would anyone who is serious about computer security use a THIRD PARTY app to fix a security issue?
This is my opinion. To make sure you don't steal it, it's covered by the DMCA.
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
This is scaremongering at its best. Nothing to see here, move along.
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.
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.
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
The Month of Apple Bugs intended to identify 31 security problems in Apple Software. The Month of Apple Fixes intended to fix those bugs in short order, so that they would not represent as much of a security threat between announcement and release of an official bugfix. Because much of MacOSX is closed source, patched binaries were a means of distributing these fixes. The latest bug was found in the third party tool that was used to patch the binaries at runtime.
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..
Not at all, but they are the main focus. We'll be looking over popular OS X applications as well.
So they are not blaming apple anywhere in their site or implying this vulnerability is apple's fault at all. Where did you get that idea? This is not a project to destroy or harm apple, quite the opposite, it will help them in the long run.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.
"Where did you get that idea?"
Um, from the title of the "project", which is "Month Of Apple Bugs". Golly, how could I possibly have been mislead?
Why yes, I AM a rocket scientist!
So, the title "Month of Apple Bugs" doesn't imply anything? Yes, you could take it to mean "bugs that infect applications developed for use on the operating system running on most computers made by Apple," but that's just not as sexy, is it? If a similar project were called "Month of Microsoft Bugs" and mostly targeted 3rd party apps, I wager people would more quickly see the problem.
Shop as usual. And avoid panic buying.
While there are some valid bugs listed, the Disk Management one basically says "anyone in the admin group can arbitrarily set file permissions". I don't know about you, but given that the admin group has, by design, unrestricted access to `sudo` I wouldn't consider their ability to set file permissions in a convoluted way a very serious security threat.
/var/log/asl.log` and you'll even delete the evidence.
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 it would be easier to just type `sudo su` followed by your password. Follow that with `rm -f
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 what OS you are using. If you tell people they are invincible because they have a Mac or use linux, you are doing them a disservice. You are also lying to them.
Yeah, now show me one example of a person with any authority seriously saying macs are invincible... just one. Apple doesn't say that. I've never seen a security researcher, or even sensationalist papers say that. If you do a Google search for "mac invincible" you find one blogger asking if Macs are invincible and one article explaining that your statement is a classic strawman argument.
I tell people that Macs or anything but windows are safer because less people care to attack them.
That is a fine message to spread, but if the paper is reporting, "30 bugs in Macintosh computers in a month demonstrate they are not secure," what do you think the average Windows user will take away from that headline? Do you think they will correctly derive from that headline that if they get a mac the chances of them getting malware are almost zero, or do you think they will take from that that it does not matter if they have a mac or a Windows machine, they are still going to get malware? Do you think it makes people more or less likely to be infected with malware, considering it may well dissuade people from moving to both Mac and Linux machines?
The poorly named MOAB is dropping vulnerabilities one after another intentionally spread out, with no prior notification in such a way that Apple either has to wait for all of them, or commit to not fixing some of them right away simply because of the time necessary for development and QA cycles. Can you think of a better way to encourage malware without actually creating exploit code yourself? Further, they're intentionally delaying releasing vulnerabilities they have found to the public, increasing the window for exploitation. Why? It gets them more press that way and a truly cynical person might say because it is the best way to encourage malware based upon their bugs so that they can get more press as they talk about how they discovered the hole first and were right about how Apple would get hacked. It is utterly irresponsible.
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.
"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.
/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.
The vulnerability is that APE installs itself in /Library where its supposed to go. /Library is writable by local admins.
/Library is writable by local admins.
/Library and piggyback their way to root on any privileged application.
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
Well, privilege defines the difference: if an unprivileged app can be hacked in such a way as to escalate privileges, that is the fault of the OS, no matter what the app did wrong. If it can be hacked only so that a remote user can execute arbitrary commands with the privilege of the process they hacked, that is the fault of the app.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
While you're looking at APE, have a look in /Library... maybe you'll be the first to find some spyware hiding in there thanks to all the world-writable files and directories... ... because that's the real problem. They didn't need APE, they could have used their own Input Manager instead. They just picked APE to thumb their nose at Landon Fuller.