If you read the last paragraph, sounds like his is a bit bitter:
Stay away of Application Enhancer. It's flawed, and not just by this particular issue. If the developers have left a binary executed with root privileges at an user-writable path, they are certainly capable of doing other non-sense. The approach for fixing the MoAB issues is actually making Apple boost it's vulnerability handling process, and not leveraging the work to a jackass third-party which has no security background at all and spends more time flaming and insulting on a delusional IRC channel than on real work (sic, stupidity is so vindictive!). Wish the ZERT guys had time to work on the stuff, they rock the house and have skills.
The funny thing is the issue isn't really with APE they just happen to be using it as an example... obviously to have a little fun with our attempts to use APE to provide temporary patches to vulnerabilities identified during MOAB. So far their statements on their website has been less then profession in tone and this one continues this trend (if not takes it to the next level).
They are simply using the fact that users in the admin group [1] have the ability to write to various directories on the system since those directories are writable to members of the admin group. In the case of /Library many directories exist that are probed under the "domain" lookup concept of Mac OS X and as a result could be using to inject code at the time an application is launched and/or the user logs in.
Not sure what Apple will do about this... they could change those directories to have a group of wheel and/or remove group write access (similar to what they do for LaunchAgents, StartupItems, etc.) but doing so would require users with admin privileges to enter their password, etc. more often (which isn't necessarily a bad thing).
[1] The user created by Mac OS X installer is a member of such a group by default and any user with "allow user to administer this computer".
> The funny thing is the issue isn't really with APE they just happen to > be using it as an example... obviously to have a little fun with our > attempts to use APE to provide temporary patches to vulnerabilities > identified during MOAB.
Having spent some time misunderstanding this issue (partly because the description provided is unclear and misleading, partly because it's late here) it seems that it is in fact a problem with APE. At least, I'm not aware offhand of any other program which launches a daemon in /Library from a patch on a root process (WindowServer).
The expectation that you can treat /Library as a safe place is understandable, but then, so is the expectation that you can pass a string to NSRunAlertPanel(); nevertheless, the OmniWeb bug was considered a bug in OmniWeb even though it had its roots in a questionable design in a system component.
On Jan 9, 2:31 am, "shawnce" <shaw...@gmail.com> wrote:
> On Jan 8, 4:20 pm, "darkp...@gmail.com" <darkp...@gmail.com> wrote: > They are simply using the fact that users in the admin group [1] have > the ability to write to various directories on the system since those > directories are writable to members of the admin group. In the case of > /Library many directories exist that are probed under the "domain" > lookup concept of Mac OS X and as a result could be using to inject > code at the time an application is launched and/or the user logs in.
Someone sent the link to this thread. Well, regarding MoAB's release for today, you're wrong saying that this is just a permissions problem and "isn't really with APE". Actually, what the exploit does is patching a binary which happens to be executed with root permissions, that later executes another one ('aped'), that they use for the real payload. ApplicationEnhancer drops privileges and sets the current uid to that of the user that is logged in.
The problem is that they can move the framework directory because of the top-most directory permissions (/Library/Frameworks) and... happily, APE is jackass enough for running the binary once the directory has been moved, re-created and tampered (that is, it doesn't even check the permissions and owner of the binary to be launched with root privileges). The new ApplicationEnhancer simply doesn't drop privileges, as the instructions have been patched (for both x86 and ppc; xor eax, eax, then call to setuid, etc, aka setuid(0) ...). The point is, if they replace or otherwise corrupt the binary, the user might be blocked from logging in (check yourself, also works when replacing aped with a shell script). That's why they are using the 'aped' binary, and overwrite it with their payload (actually a fat binary of a typical bind shell backdoor, check it out if you have time for some reversing fun).
The new ApplicationEnhancer will then execute 'aped' with root privileges (while the legitimate one runs it under the current user's privileges. Game over.
It's APE which shouldn't use that approach. /Library/Frameworks is definitely not the place to use for binaries which will run privileged. APE is a nice tool, but, without any offense meant, it's flawed by design. This isn't the only one issue existent right now, although it's of course up to you to downplay or deny it (and the other ones if they happen to get released). The exploit and information are available for "technical-minded" people to check.
Regards, and keep up the good work on the fixes (as long as they don't represent new threats ;-) ).
> On Jan 9, 2:31 am, "shawnce" <shaw...@gmail.com> wrote:
> > On Jan 8, 4:20 pm, "darkp...@gmail.com" <darkp...@gmail.com> wrote: > > They are simply using the fact that users in the admin group [1] have > > the ability to write to various directories on the system since those > > directories are writable to members of the admin group. In the case of > > /Library many directories exist that are probed under the "domain" > > lookup concept of Mac OS X and as a result could be using to inject > > code at the time an application is launched and/or the user logs in.
> It's APE which shouldn't use that approach. /Library/Frameworks is > definitely not the place to use for binaries which will run privileged.
> On Jan 8, 6:40 pm, Christopher Forsythe <c...@growl.info> wrote: > > So why did you bring this up at all? Basically the email was pointless?
> To hint that Apple has something planned that will help with this type > of issue.
One would hope that any company is planning features to improve the security of their product.
Tightening up permissions in /Library would be a good start as we've seen from Day 5 and Day 8. (Although it isn't hard to imagine presenting people with an authopen dialog under false pretenses and getting them to assist further in their own victimization.)
> Tightening up permissions in /Library would be a good start as we've > seen from Day 5 and Day 8. (Although it isn't hard to imagine > presenting people with an authopen dialog under false pretenses and > getting them to assist further in their own victimization.)
At a certain point we have to admit that the user is the unpatchable component in any software deployment.
What strikes me as interesting is LHM's open attack against us. I guess Landon hurt the poor kid's feelings by turning down his offer. His statement about our lack of security background is probably true (at least for me it is true) but apparently he is threatened enough by our stupid, vindictive, flaming, insulting and delusional group that he must try to discredit us on his own project sight. Too funny.
But we are getting off topic. I was wondering how long it would long it would take LMH to attack APE. Consider this; APE was never intended to be a permanent fix for any of these issues, merely a method by which we could apply a temporary bandage. Does APE have issues of its own? Yes, but if it can be used to help patch a dozen other flaws, is that not a sufficient trade-off? Ultimately it is up to the developers to fix these issues, we are here to hopefully fix a few things and have fun doing so.
If that fact hurts LMH's perception of superior perfection, then that is his problem.
So, does anyone have any ideas for this issue?
Steven
Two people walk into a crowded restaurant. Both notice a guy in the corner whose pants zipper is unzipped. The first person moves over to the guy and discreetly lets him know of what could have been very embarrassing. The second person on the other hand jumps on top of the nearest table and loudly shouts, "Look, his fly is unzipped! HA HA!" Which are you LMH? Of course, if he ultimately zips up his fly, what does it matter? It's a win-win, right?
> What strikes me as interesting is LHM's open attack against us. I > guess > Landon hurt the poor kid's feelings by turning down his offer. His > statement about our lack of security background is probably true (at > least for me it is true) but apparently he is threatened enough by our > stupid, vindictive, flaming, insulting and delusional group that he > must try to discredit us on his own project sight. Too funny.
I'd actually been meaning to send out an e-mail regarding this -- I'm personally a fan of sticking to the Thumper Protocol [1]: If you can't say anything nice, don't say anything at all.
Feel free to laugh at me now.
Seriously, though, I'd really prefer to keep conversation here running on a positive note. One doesn't have to agree with everyone, but we can disagree politely, and focus on solving problems.
> But we are getting off topic. I was wondering how long it would > long it > would take LMH to attack APE. Consider this; APE was never intended to > be a permanent fix for any of these issues, merely a method by > which we > could apply a temporary bandage. Does APE have issues of its own? Yes, > but if it can be used to help patch a dozen other flaws, is that not a > sufficient trade-off? Ultimately it is up to the developers to fix > these issues, we are here to hopefully fix a few things and have fun > doing so.
There's no rule that says we can't be pro-active in identifying issues in Application Enhancer. I kind of like the idea, but I don't know if that's something Unsanity would be interested in.
> > But we are getting off topic. I was wondering how long it would > > long it > > would take LMH to attack APE. Consider this; APE was never intended to > > be a permanent fix for any of these issues, merely a method by > > which we > > could apply a temporary bandage. Does APE have issues of its own? Yes, > > but if it can be used to help patch a dozen other flaws, is that not a > > sufficient trade-off? Ultimately it is up to the developers to fix > > these issues, we are here to hopefully fix a few things and have fun > > doing so.
> There's no rule that says we can't be pro-active in identifying > issues in Application Enhancer. I kind of like the idea, but I don't > know if that's something Unsanity would be interested in.
This of course isn't limited to Application Enhancer either. Every good software engineer should be interested in hearing intelligent suggestions about how they can produce a more secure product. The key is to make sure that both the engineers working on the bugs and the researchers finding the bugs communicate openly and without malice aforethought by both parties.
To add to the keeping positive note from earlier: Sometimes I see people flaming back and forth and am struck by the fact that a lot of people (myself included) should've paid a lot more attention to what Mr. Rogers had to say when they were growing up.
It's a beautiful day in the neighborhood... -- wac
On Jan 9, 5:02 am, "William A. Carrel" <willia...@carrel.org> wrote:
> Tightening up permissions in /Library would be a good start as we've > seen from Day 5 and Day 8. (Although it isn't hard to imagine > presenting people with an authopen dialog under false pretenses and > getting them to assist further in their own victimization.)
Especially not when there's no way to tell if that auth dialog comes from a real app or from an InputManager running in an app you consider safe.
On Mon, Jan 08, 2007 at 11:30:04PM -0800, Landon Fuller wrote:
> On Jan 8, 2007, at 11:14 PM, missileboat wrote:
> >What strikes me as interesting is LHM's open attack against us. I > >guess > >Landon hurt the poor kid's feelings by turning down his offer. His > >statement about our lack of security background is probably true (at > >least for me it is true) but apparently he is threatened enough by our > >stupid, vindictive, flaming, insulting and delusional group that he > >must try to discredit us on his own project sight. Too funny.
> I'd actually been meaning to send out an e-mail regarding this -- I'm > personally a fan of sticking to the Thumper Protocol [1]: > If you can't say anything nice, don't say anything at all.
> Feel free to laugh at me now.
> Seriously, though, I'd really prefer to keep conversation here > running on a positive note. One doesn't have to agree with everyone, > but we can disagree politely, and focus on solving problems.
> I'd appreciate a review before I post it publicly in the not-to- > distant future.
> -landonf
> [1] If you don't know it, Google the quote. Then laugh at me.
I read through the draft, and I think that it'd be good to add a note about not running as an admin user. Towards the end there's a paragraph that starts with:
The vulnerability is real -- it is possible for a local administrator account on the computer....
Either then end of this paragraph or the next, or maybe a new paragraph after them, would be a good place to insert something like:
These problems illustrate the reasons to use a non-administrator account as your primary account. Mac OS X Tiger (10.4) makes it very easy to do administrative tasks when needed (it presents you with dialogs when a task requires administrative privileges).
I'm all for give a plug to the various hardening guides, with Apple's being one of them (its actually quite good). The guides I'd point out are:
As well, in the Conclusion there's text about the possibility of mistakes. If there is a mistake in one area, the current choice for users is to run with the mistake or to remove *all* of the fixes. While I don't really want to have a huge (20+) stack of haxies, one per fix, I do think it'd be good to have some way of having the most recent (few?) fixes as separate haxies. That way the older (and presumably more stable) fixes would be a bundle, while the most recent fixes would be individual and thus easily disabled individually. I do see a problem with maintenance for users that way, they'd be continually having to add and remove haxies. Perhaps we could set up a preferences pane for the fixes, and all the fixes could be in one haxie and the user can enable/disable them individually.
On 09/01/07, Jens Ayton <jens.ay...@gmail.com> wrote:
> The expectation that you can treat /Library as a safe place is > understandable, but then, so is the expectation that you can pass a > string to NSRunAlertPanel(); nevertheless, the OmniWeb bug was > considered a bug in OmniWeb even though it had its roots in a > questionable design in a system component.
NSRunAlertPanel is documented to take a format string in that argument (although indirectly). There are clear warnings in the headers.
>> The expectation that you can treat /Library as a safe place is >> understandable, but then, so is the expectation that you can pass a >> string to NSRunAlertPanel(); nevertheless, the OmniWeb bug was >> considered a bug in OmniWeb even though it had its roots in a >> questionable design in a system component.
> NSRunAlertPanel is documented to take a format string in that argument > (although indirectly). There are clear warnings in the headers.
Documenting a questionable design does not make it a non-questionable design.
> But we are getting off topic. I was wondering how long it would long > it > would take LMH to attack APE. Consider this; APE was never intended to > be a permanent fix for any of these issues, merely a method by which > we > could apply a temporary bandage. Does APE have issues of its own? Yes, > but if it can be used to help patch a dozen other flaws, is that not a > sufficient trade-off? Ultimately it is up to the developers to fix > these issues, we are here to hopefully fix a few things and have fun > doing so.
I would wonder if we could switch to using mach_inject and mach_override. It can do the same job as APE, but recqiures a bit more work on the developer end. It's open source and not very large, I doubt he could find a 'sploit in it.
> I would wonder if we could switch to using mach_inject and > mach_override. It can do the same job as APE, but recqiures a bit more > work on the developer end. It's open source and not very large, I > doubt he could find a 'sploit in it.
IIRC mach_inject and mach_override require membership in a special group to work correctly as of some recent change - I think all Intel machines and maybe recent versions of 10.4 on PPC. Membership in that group could itself be considered a vulnerability on some level - I'm sure that Apple had a good reason for this restriction.
> Either then end of this paragraph or the next, or maybe a new > paragraph after them, would be a good place to insert something like:
> These problems illustrate the reasons to use a non-administrator > account as your primary account. Mac OS X Tiger (10.4) makes it very > easy to do administrative tasks when needed (it presents you with > dialogs when a task requires administrative privileges).
> I'm all for give a plug to the various hardening guides, > with Apple's being one of them (its actually quite good). > The guides I'd point out are:
I posted too early for this, but I agree, it'd be a really good to offer some links to generic security advice. Most people aren't going to patch their system, but they can take some steps, in some cases, to mitigate the issues.
> As well, in the Conclusion there's text about the possibility of > mistakes. > If there is a mistake in one area, the current choice for users is > to run with > the mistake or to remove *all* of the fixes. While I don't really > want to have a > huge (20+) stack of haxies, one per fix, I do think it'd be good to > have some > way of having the most recent (few?) fixes as separate haxies. > That way the older > (and presumably more stable) fixes would be a bundle, while the > most recent > fixes would be individual and thus easily disabled individually. > I do see a problem with maintenance for users that way, they'd be > continually > having to add and remove haxies. > Perhaps we could set up a preferences pane for the fixes, and all > the fixes > could be in one haxie and the user can enable/disable them > individually.
I think this is a really good idea. 20+ haxies is a maintenance headache, but users should really have an option regarding what they're willing to patch. Having one haxie with patch settings makes sense to me. Anyone up for implementing this?
|
