MOAB #8
dark...@gmail.com
http://projects.info-pull.com/moab/MOAB-08-01-2007.html
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.
shawnce
On Jan 8, 4:20 pm, "darkp...@gmail.com" <darkp...@gmail.com> wrote:
> MOAB-08-01-2007: Application Enhancer (APE) Local Privilege Escalation
>
> http://projects.info-pull.com/moab/MOAB-08-01-2007.html
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".
Jens Ayton
>
> 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.
--
Jens Ayton
Sed quis custodiet ipsos custodes?
st...@info-pull.com
> 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 ;-) ).
shawnce
On Jan 8, 5:56 pm, s...@info-pull.com wrote:
> 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 this point I agree.
-Shawn
shawnce
the feature I am thinking of just yet.
-Shawn
Christopher Forsythe
Chris
shawnce
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.
-Shawn
William A. Carrel
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.)
--
wac
Remy Porter
> 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.
missileboat
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?
Landon Fuller
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.
On a semi-related note, I've got a draft document that provides a
brief introduction to runtime patches:
http://landonf.bikemonkey.org/static/patch.html
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.
Landon Fuller
On Jan 8, 2007, at 11:14 PM, missileboat wrote:
> 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.
-landonf
William A. Carrel
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
Dag Ågren
> 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.
Eric Hall
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:
Apple's:
http://images.apple.com/server/pdfs/Tiger_Security_Config.pdf
Corsair guide:
http://www.corsaire.com/white-papers/060517-securing-mac-os-x-tiger.pdf
CIS Benchmark:
http://www.cisecurity.org
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.
-eric
Finlay Dobbie
> 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.
-- Finlay
Jens Ayton
> Jens Ayton
>>
>> 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.
Colin Barrett
On Jan 8, 2007, at 11:14 PM, missileboat wrote:
> 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.
-Colin
Augie Fackler
On Jan 9, 2007, at 7:01 PM, Colin Barrett wrote:
> 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.
Augie
>
> -Colin
>
> >
Finlay Dobbie
> design.
There are reasons for designing it that way. Behaves as designed and
documented, therefore the bug is in OmniWeb. That is all.
-- Finlay
Landon Fuller
On Jan 9, 2007, at 8:29 AM, Eric Hall wrote:
> 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:
>
> Apple's:
> http://images.apple.com/server/pdfs/Tiger_Security_Config.pdf
>
> Corsair guide:
> http://www.corsaire.com/white-papers/060517-securing-mac-os-x-
> tiger.pdf
>
> CIS Benchmark:
> http://www.cisecurity.org
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?
-landonf