moab#15: More admin-writable SUID stuff
William A. Carrel
I think the best approach here is to update the script I wrote for
moab#5 to cover both this and the similar issues with APE.
This can't really be defended against without fixing the permissions
on disk. I'm doing a more exhaustive search of suid files now to look
for additional hazards.
--
wac
Greg Hurrell
feature is questionable; you could even argue (and the advisory
certainly does) that it is a "misfeature".
It is no surprise at all that a user in the admin group can acquire
root privileges ("sudo -s" and there you are). The issue here is that
such a user could be tricked into doing so by running a
seemingly-innocuous but actually-malicious executable instead of being
asked for their password. But really to me this is no news at all: if
you run code that someone else gave to you, then you are effectively
accepting the risk because you don't know what that code will do and by
definition that code will run with your privileges and do anything that
you can do, including acquiring root privileges if you are an
administrator.
I think that the "repair permissions" tool is part of the problem and
it should definitely be modified to perform validation prior to
"repairing" (and even that is only going part-way), but the real
underlying issue is that users run as admin users in their day-to-day
computing. They should be running as unprivileged users and only
authenticate as admins when necessary; and only then when they are
fully aware of the risks that they expose themselves to. And although
it makes sense for Mac OS X to create an admin user when first
installed, it should probably do a lot more to encourage users to
create a normal account for daily use instead; I'd even be happy to see
non-login admin accounts (you create an admin account during the
install but logins are disabled for it; you then create your regular
account and that's the one you log in to).
antibozo
> I agree with the advisory that the design of the "repair permissions"
> feature is questionable; you could even argue (and the advisory
> certainly does) that it is a "misfeature".
As with DMG, this is a vulnerability that results from an inadequate
packaging system. If they'd done things properly, there would be stored
digests of the files to go along with the permissions, and the repair
process would check those before mucking with anything.
antibozo
> As with DMG, this is a vulnerability that results from an inadequate
> packaging system. If they'd done things properly, there would be stored
> digests of the files to go along with the permissions, and the repair
> process would check those before mucking with anything.
Of course, there would still be a race condition, even then. I'm not
saying it's okay for the files to be admin-writable in the first place.
:^)
dinornis
On Jan 17, 1:43 am, "Greg Hurrell" <greg.hurr...@gmail.com> wrote:
>....although
> it makes sense for Mac OS X to create an admin user when first
> installed, it should probably do a lot more to encourage users to
> create a normal account for daily use instead;...
OSX Server does this, I guess Apple made a "business" decision
that John Doe users wouldn't tolerate a forced reboot and second
acct. creation...
> "sudo -s" and there you are...
within the grace period: there are numerous suggestions
that users should shorten (or lengthen :-( the grace period.
What if it were made zero by default?
Rosyna
already lost. The priority has always been to prevent malicious code
from running. Not limiting what it can do once it is running. A
malicious application does not need to be root to destroy your
photos, movies, pornography or other personal documents. You should
never run applications from a source you do not trust.
Currently, there are about 50 brazillion ways to get root privs once
you have local access to a machine. And 50 brazillion more if you
have physical access to a machine.
The important thing to prevent is remote exploits that are not a
simple a DoS. While DoS's are annoying as hell, they're more like
flies around your food. Whereas remote exploits are more like E.Coli
infected green beans.
And the worst kind of issues are remote exploits that require no user
interaction whatsoever. These are hella bad.
Ack, at 1/16/07, Greg Hurrell said:
>The issue here is that
>such a user could be tricked into doing so by running a
>seemingly-innocuous but actually-malicious executable instead of being
>asked for their password. But really to me this is no news at all: if
>you run code that someone else gave to you, then you are effectively
>accepting the risk because you don't know what that code will do and by
>definition that code will run with your privileges and do anything that
>you can do, including acquiring root privileges if you are an
>administrator.
--
Sincerely,
Rosyna Keller
Technical Support/Carbon troll/Always needs a hug
Unsanity: Unsane Tools for Insanely Great People
It's either this, or imagining Phil Schiller in a thong.
William A. Carrel
>
> Currently, there are about 50 brazillion ways to get root privs once
> you have local access to a machine. And 50 brazillion more if you
> have physical access to a machine.
With all due respect, if the fix is easy I'd like to make it 50
"brazillion" minus one. "A journey of a thousand miles begins with a
single step."
> The important thing to prevent is remote exploits that are not a
> simple a DoS. While DoS's are annoying as hell, they're more like
> flies around your food. Whereas remote exploits are more like E.Coli
> infected green beans.
>
> And the worst kind of issues are remote exploits that require no user
> interaction whatsoever. These are hella bad.
It's a good thing if you can make it just a little bit harder for
people to make it all the way to root if they figure out how to
remotely execute code on your machine. That is, the machine doesn't
turn into a pumpkin once someone runs exploit code. Security must come
in layers. If this wasn't the case, people would feel just fine about
leaving a suid root copy of /bin/sh lying around.
Remote exploits are very bad, but that doesn't mean local privilege
escalation issues should be ignored. I find it frustrating to see
people downplay security problems just because Mallory can't remotely
own your box with it from a Paraguayan dialup account in one fell
swoop.
--
wac
antibozo
> Indeed. If you're running malicious code on your machine, you've
> already lost. The priority has always been to prevent malicious code
> from running. Not limiting what it can do once it is running.
That's an interesting perspective, given that one of the oft-touted
benefits of Mac OS X is that users don't normally work as root, thus
there are at least some limits on the harm an attack may incur.
I'd be the first to agree that any compromise can be severely damaging,
but an attacker able to execute code on the system as an admin user is
*presumed* by MOAB #15. The vulnerability is that privileges may then
be escalated to root. By analogy, if you put an object inside a safe,
and put that safe inside another safe, the interior safe is pointless
if you don't change the combination from the factory default.
Not every attacker wants to delete your vacation photos and porn
collection. Some of them want to hide a back door or bot on your system
in a way that you can't see it, and the way to accomplish that usually
involves getting root. Preventing remote users from getting root, even
though they've compromised the system as a regular user, retains the
ability to detect the intrusion.
> Currently, there are about 50 brazillion ways to get root privs once
> you have local access to a machine. And 50 brazillion more if you
> have physical access to a machine.
Apparently by "local access" you mean "remote access". I'm sure Apple
would be very interested to hear about all these ways you can get root
without having physical access, since they've worked fairly hard
(though not hard enough) to prevent exactly that. Maybe you should run
a campaign to document all these ways, one per day, lasting a
"brazillion" days.
In any case, the theoretical existence of other privilege escalation
vulnerabilities doesn't make this one *not* a privilege escalation
vulnerability. You're just pulling the wool over your own eyes.
Rosyna
that has thousands of small holes in it?
I think it's far better to put engineering resources into addressing
the remote exploits. If you only have enough man power to do one or
the other and then audit the fixes.
Ack, at 1/16/07, William A. Carrel said:
>On 1/16/07, Rosyna <ros...@gmail.com> wrote:
>>
>>Currently, there are about 50 brazillion ways to get root privs once
>>you have local access to a machine. And 50 brazillion more if you
>>have physical access to a machine.
>
>With all due respect, if the fix is easy I'd like to make it 50
>"brazillion" minus one. "A journey of a thousand miles begins with a
>single step."
--
Rosyna
>On Jan 17, 12:28 am, Rosyna <ros...@gmail.com> wrote:
>>Indeed. If you're running malicious code on your machine, you've
>>already lost. The priority has always been to prevent malicious code
>>from running. Not limiting what it can do once it is running.
>
>That's an interesting perspective, given that one of the oft-touted
>benefits of Mac OS X is that users don't normally work as root, thus
>there are at least some limits on the harm an attack may incur.
The benefits of not having root (at least how I've always stated it)
is that it protects the user from themselves. Everyone makes typos
and does stupid things once in a while. Not having root protects some
of the graver errors.
> By analogy, if you put an object inside a safe,
>and put that safe inside another safe, the interior safe is pointless
>if you don't change the combination from the factory default.
Indeed.
>Not every attacker wants to delete your vacation photos and porn
>collection. Some of them want to hide a back door or bot on your system
>in a way that you can't see it, and the way to accomplish that usually
>involves getting root. Preventing remote users from getting root, even
>though they've compromised the system as a regular user, retains the
>ability to detect the intrusion.
But if no remote user can get into the system...
>>Currently, there are about 50 brazillion ways to get root privs once
>>you have local access to a machine. And 50 brazillion more if you
>>have physical access to a machine.
>
>Apparently by "local access" you mean "remote access". I'm sure Apple
>would be very interested to hear about all these ways you can get root
>without having physical access, since they've worked fairly hard
>(though not hard enough) to prevent exactly that. Maybe you should run
>a campaign to document all these ways, one per day, lasting a
>"brazillion" days.
No, I said local access and meant local access. If a user explicitly
runs an application on your mac by double clicking on it, that
program was granted local access as it became a local resource as
soon as the user interacted with it.
Remote access is when a remote resource does something to get
executed on your machine with no user interaction. It's a gray area
for web resources. If you go to a website and it downloads a disk
image automatically and it them mounts it and causes a kernel panic,
that's a remote denial of service. If you go to a website and it
downloads a disk image but you have to double click it to mount it,
that's a local denial of service.
antibozo
> Ack, at 1/17/07, antibozo said:
> >On Jan 17, 12:28 am, Rosyna <ros...@gmail.com> wrote:
> >>Indeed. If you're running malicious code on your machine, you've
> >>already lost. The priority has always been to prevent malicious code
> >>from running. Not limiting what it can do once it is running.
>
> is that it protects the user from themselves. Everyone makes typos
> and does stupid things once in a while. Not having root protects some
> of the graver errors.
All I can say in response to this, without having to force down the
bile, is that you should spend a lot more effort learning about system
security.
> > Preventing remote users from getting root, even
> >though they've compromised the system as a regular user, retains the
> >ability to detect the intrusion.
> But if no remote user can get into the system...
Yes, obviously we want to prevent that. But when we fail, we don't just
give up in despair. Remote vulnerabilities will always exist. A large
part of system security is containing attacks that are successful at
one layer to prevent them from compromising the entire system.
For example, suppose there are two users on a Mac, Jason and Rosyna.
Rosyna incurs a remote exploit while browsing, and the attacker, for
some inexplicable reason, decides to delete her porn collection. But
because the attacker doesn't have root access, he is unable to delete
all of Jason's iTunes.
Get the picture?
> >>Currently, there are about 50 brazillion ways to get root privs once
> >>you have local access to a machine. And 50 brazillion more if you
> >>have physical access to a machine.
>
> >Apparently by "local access" you mean "remote access". I'm sure Apple
> >would be very interested to hear about all these ways you can get root
> >without having physical access, since they've worked fairly hard
> >(though not hard enough) to prevent exactly that. Maybe you should run
> >a campaign to document all these ways, one per day, lasting a
> >"brazillion" days.
> No, I said local access and meant local access. If a user explicitly runs an application on your mac by double clicking on it, that program was granted local access as it became a local resource as soon as the user interacted with it.
Your terminology remains unclear. You already made a distinction
between "local access" and "physical access" in your initial statement.
I'm still unclear on what you mean, since your new statement states
that they both somehow involve "double-clicking".
> Remote access is when a remote resource does something to get
> executed on your machine with no user interaction.
No, that's a remote exploit. Remote access is when someone has control
of a a system without being physically present. For example, if you ssh
into a Mac in the next room (or in Guam), that's remote access.
You do yourself a disservice by attempting to comment on these matters
without learning the common lexicon of security.
Rosyna
>On Jan 17, 1:10 am, Rosyna <ros...@gmail.com> wrote:
>>Ack, at 1/17/07, antibozo said:
>>>On Jan 17, 12:28 am, Rosyna <ros...@gmail.com> wrote:
>>>>Indeed. If you're running malicious code on your machine, you've
>>>>already lost. The priority has always been to prevent malicious code
>>>>from running. Not limiting what it can do once it is running.
>>
>>The benefits of not having root (at least how I've always stated it)
>>is that it protects the user from themselves. Everyone makes typos
>>and does stupid things once in a while. Not having root protects some
>>of the graver errors.
>
>All I can say in response to this, without having to force down the
>bile, is that you should spend a lot more effort learning about system
>security.
And the fact is, Mac OS X Client isn't written with local security in mind.
>For example, suppose there are two users on a Mac, Jason and Rosyna.
>Rosyna incurs a remote exploit while browsing, and the attacker, for
>some inexplicable reason, decides to delete her porn collection. But
>because the attacker doesn't have root access, he is unable to delete
>all of Jason's iTunes.
>
>Get the picture?
But that involves a remote exploit. If there is no remote exploit,
then it's not an issue.
>> >>Currently, there are about 50 brazillion ways to get root privs once
>>>>you have local access to a machine. And 50 brazillion more if you
>>>>have physical access to a machine.
>>
>>>Apparently by "local access" you mean "remote access". I'm sure Apple
>>>would be very interested to hear about all these ways you can get root
>>>without having physical access, since they've worked fairly hard
>>>(though not hard enough) to prevent exactly that. Maybe you should run
>>>a campaign to document all these ways, one per day, lasting a
>>>"brazillion" days.
>>No, I said local access and meant local access. If a user
>>explicitly runs an application on your mac by double clicking on
>>it, that program was granted local access as it became a local
>>resource as soon as the user interacted with it.
>
>Your terminology remains unclear. You already made a distinction
>between "local access" and "physical access" in your initial statement.
>I'm still unclear on what you mean, since your new statement states
>that they both somehow involve "double-clicking".
Physical access refers to a person, meaning someone is physically
sitting in front of a computer. Someone with physical access also has
local access (of course). Local access meaning a local resource is
running on the machine. Something that's stored on the machine. Local
access does not have to refer to a person.
That's why the distinction is made. If I have physical access to a
machine (I can touch it) I can do a lot more since I can completely
bypass the OS and any security features it may implement. With *only*
local access, you cannot bypass the OS. If a program (say Pages) is
running on a machine, it only has local access to the machine. It
doesn't matter in this context whether or not you are using ssh to
launch Pages or not, Pages still only has local access.
antibozo
> And the fact is, Mac OS X Client isn't written with local security in mind.
I'm sure that's news to the folks at Apple.
> But that involves a remote exploit. If there is no remote exploit,
Good luck with that whole "if there is no remote exploit" approach to
security.
> then it's not an issue.
I'd try to explain, once again, how different local users are supposed
to be protected from one another via that whole mythical "access
control" thing, but we'd be here all day, I'm afraid, walking around in
circles. So start here:
http://en.wikipedia.org/wiki/Computer_Security
and have fun playing with all your photos, movies, pornography, and
personal documents.
Rosyna
Ack, at 1/17/07, antibozo said:
>I'd try to explain, once again, how different local users are supposed
>to be protected from one another via that whole mythical "access
>control" thing, but we'd be here all day, I'm afraid, walking around in
>circles. So start here:
--
dinornis
On Jan 17, 2:00 pm, "antibozo" <antib...@gmail.com> wrote:
> ...an attacker able to execute code on the system as an admin user is
> *presumed* by MOAB #15. The vulnerability is that privileges may then
> be escalated to root.
So, how do you stop admin users surfing porn?
Short answer, you can't. And I don't see how you can quickly patch
the generality of privilege escalations.
So is Apple gonna turn BOFH and put a Server style
SetupAssistant script in desktop machines?
And set the default shell to /usr/bin/true
for non-admin users? No way :-(
Jason Harris
> But what use is it to put scotch tape over one small hole in a dam
> that has thousands of small holes in it?
On Jan 16, 2007, at 6:41 PM, antibozo wrote:
> For example, suppose there are two users on a Mac, Jason and Rosyna.
> Rosyna incurs a remote exploit while browsing, and the attacker, for
> some inexplicable reason, decides to delete her porn collection. But
> because the attacker doesn't have root access, he is unable to delete
> all of Jason's iTunes.
I hope this isn't intended to conflate my thoughts with Rosyna's
espoused philosophy, as Rosyna most definitely does not speak for me
in this case.
Security should be about minimizing risk, nothing more.
This means that if there's a general fix for a particular exploit,
implement it. If not, but there's a specific fix for a specific
attack vector, implement that, for as many attack vectors as
possible, and try to stay on top of things until the vendor provides
a general fix.
If the proposed fix causes more risk than what it protects against
(as in the case of Landon's discussion of kernel patches), do nothing
and wait for the vendor, or look for a less risky solution, as this
group is doing.
That's it. Saying "don't fix it because there are a thousand other
exploits" just ain't the right approach to security.
Jason
Rosyna
dam when efforts could instead be focused on making the dam
completely unnecessary. There isn't enough man power to do both.
Ack, at 1/16/07, Jason Harris said:
>That's it. Saying "don't fix it because there are a thousand other
>exploits" just ain't the right approach to security.
--
antibozo
> So, how do you stop admin users surfing porn?
Um, why would we want to do that? Do we really want a bunch of sexually
frustrated admin users milling around? Give them their porn, for Pete's
sake.
> Short answer, you can't.
Okay, you win. So, was that relevant somehow?
> And I don't see how you can quickly patch
> the generality of privilege escalations.
Ah, there's what we were talking about. No, I agree, you can't do it
quickly, and it's not Landon's job to patch every Mac OS vulnerability
of any variety, even though he once worked for Apple.
The fruitless discussion I was foolishly participating in was about the
severity of MOAB #15, not which vectors folks should try to develop a
quick patch against. Sorry if that wasn't clear, but not much was...
antibozo
> I hope this isn't intended to conflate my thoughts with Rosyna's
> espoused philosophy
If anything, the contrary.
Greg Hurrell
> The priority has always been to prevent malicious code
> from running. Not limiting what it can do once it is running.
I don't think that's correct, Rosyna. Good security requires a
multi-level defense. Even you might one day download a trojan and
unwittingly run it one day... Or you might download a product that has
a bug which causes data loss... if you're running as an unprivileged
user at least you'll only compromise your own files, not those of the
other users on your machine. On the other hand, if you're running as
root or as an admin user...
> The benefits of not having root (at least how I've always stated it)
> is that it protects the user from themselves. Everyone makes typos
> and does stupid things once in a while. Not having root protects some
> of the graver errors.
Yes, this is partly true, but that's just one of the benefits. Yes,
running as an unprivileged user prevents you from accidentally wreaking
havoc with other users' files. But it also limits the damage that a
malicious piece of code could do to other users' files, or code that is
not intentionally malicious but which due to bugs might cause data loss
etc.
As a matter of general principle you should always run with the
absolute minimum of privileges required to complete a given task.
Greg