Hello, my name is Anthony Dale Mehta-Lopes and I'm going to be speaking about escalating
privileges in Unix by backdooring libc in various methods. I work for Outpost 24 in
Sweden. We're an automated vulnerability scanner for networks and I am a software developer
as well as a security researcher. Sorry about my slides here. I'm going to have to kind
of move around because it's too small to see otherwise. So what I'm going to be talking
about is mostly on Unix, the su command, new role, sudo, all of these support specification
of commands to run in another security context and there's a little bit of a problem with
how this is actually done. This can be abused to escalate privileges and I want to clarify
that I'm talking about escalating privileges. I'm not talking about without any exploitation
at all. You should already be in the system as a regular user, say, exploiting Firefox
or Mozilla or something like that. So this is just how to get root after you've already
compromised the system in some way or another. And I'll give you a proof of concept demo
with using Ptrace to inject code into another process in the same security context to get
to the next security context as well as using the typical LD preload to do this as well.
Okay. My hypothesis here is that work to be executed in a new security context should
not be scheduled in the previous security context and I'll explain why I think this
is true. The theoretical support for this is that, well, you already know what su does
and how that works and basically the arguments to su new role, any of these things can be
modified because they exist in a memory which is only part of the previous security context.
So say my user's name is user or Tony or something like that which exists and then I run shells
in this and there's Firefox in that as well. And these both exist in the same security
context. So my shell can edit the memory of the Firefox and the Firefox can edit the memory
of that and there are various ways to do this. I chose either Ptrace or LD preload. And I
think you guys can see this kind of graph here. Basically, this is the specific example
of using Ptrace but basically a user runs a shell. The user's shell is infected by
Trojan. This comes from the Mozilla or whatever else is infected. User requests an action
A to be executed in the security, the privileged context. They, the Trojan is then activated
and modifies what they've requested to be done like say replacing action A with action
B or maybe a combination of both so you're a little bit more covert about that. The user
then authenticates and now you're actually using SU. You're actually in that and it's
that UID binary so there's nothing more to attack there. And then that's automatically
escalating privileges if you type your password correctly and B is executed which is not obviously
what the user intended to do and eventually you go back to the original security context.
Some background for this, the Trojan property is not new. This has been in login and various
things people replace their login prompts with other things to steal passwords and stuff
like that. Typically these things require a little bit more of attacker interaction
with their target. However, this is, this particular approach that I'm taking completely
automated and it still exists. For the most part on local terminals anyway you have, if
you have physical security you don't exactly have this problem but we're talking here in
that network context. Crot-site scripting also seems to be like the new, the web's new
Trojan login so that's also a related problem. And basically what it comes down to is that
there's a severe lack of trusted path in the common UNIX security model. And I'm saying
common because some systems actually do support this to some degree and I'll talk about that
later. This is interesting because it's not just SU and SUDA that have this problem. The
new role as I said in SU Linux, one of the up and coming NSA's secure mandatory access
control based and role based access control and so on and so on system for locking down
Linux also has this trivial little flaw in it. You can have a great policy going but
if you can execute commands that the user didn't intend to execute in the first place
you could still do things within that policy. Yeah and one of my points here is that vulnerabilities
and unprivileged applications still matter and this is just one demonstration of why
that is true. I get, I do a lot of vulnerability research and I get a lot of the time like
oh this doesn't matter, you found something in some really common applications not set
UID or I hear it from the other side a lot of researchers are like oh where's the set
UID binaries on this system, that's what the first thing they look for but I really don't
think that's necessary if you just have a small amount of patience because some people
are going to use SUDA, SU, new role, whatever to do some administration tasks. If it's a
server you're going to run Apache eventually, if it's not a server it's a desktop you're
going to run start down eventually and you have to do these as a privileged user usually.
This is changing with the advent of PolicyKit and SE Linux as well but in most 99% of the
case this is the way people are using their computers, their Unix computers these days.
And I also want to point out that I think that in policies for SE Linux and other mandatory
control systems, mandatory access control systems, the user land applications, the unprivileged
applications should be locked down with policy as much as the privileged applications are.
So I'd really like to know why people think it's okay that Mozilla can read my GPG keys
and my SSH keys but it's not okay for Apache to do such and such other than just serving
web pages. I think it should be equal on both sides. I'm not sure why it's not that way
especially for desktop systems like Fedora and stuff like that. Why do we have a targeted
policy for Apache? People are typically doing that on their desktops. They're usually a
desktop running Firefox and things like that and these applications really shouldn't be
interacting except for the communication channels that they're allowed to. People are still
using SU everywhere. I use it. People are still using pseudo. That seems also really
common. Other applications are built on top of these like GKSU, KDESU. There's a new known
one. I'm not really sure what it's called. It's integrated in Fedora or Red Hat or something.
PolicyKit, I'm not going to talk too much about it because I really don't have a lot
of experience but from the first look at it, it seems that it has, it's at a similar state
to what NewRole is and I'll explain that so just keep that in mind. But definitely more
research should be done about PolicyKit and these other kits that are from FreeDesktop.org
managing authentication, console login and that kind of stuff. So you guys probably know
what SU is considering but in case there's any Windows people here, SU is a setUID Unix
program that allows you to switch to an escalated privilege context or to another arbitrary
user. Typically without any arguments, it just gives you a shell. With arguments, with
this specific argument, dash C, it'll give you, it'll execute that command that you request
and exit immediately. So let's move on. Yeah. NewRole is a program that allows, this is
specific to SC Linux by the way. This is not common for most distributions but like I said,
Fedora and some other ones that are doing the SC Linux thing now are using this and
it looks like from the targeted policy, it's basically the same as SU more or less. It
has the same problem as SU but it's typically more restricted because what you can and can't
do in the NewRole depends on what the policy is. So for example, someone could have a policy
where you're allowed to run LS and you could also say view images as root. Okay, these
are ridiculous examples but anyway, you can't go and say, oh yeah, I want to change your
LS to be something like I want to open a port. That's just something that's policy dependent.
However, it's still strange that you would be able to change what the user is intending
to do from viewing directory listings to viewing images. It just doesn't make sense. Yeah,
so I think I just covered most of these points. One of the interesting things, controversial
I guess, is that in SC Linux and other systems that are similar to this reference monitor
based system, policy is supposed to be separated from mechanism and well, I'm going to talk
more about this in the resolutions of the problems, the remedies for the problem but
basically the policy for fixing this in SC Linux can be quite daunting to actually do
this and if anyone knows any policy for this, it's just quite daunting in the first place.
So it may be nice to actually just remove this as a potential solution but I'll go into
that more later. Pseudo is just like SU. It has like a really limited type of policy thing
where you can say like this user can run this command and basically instead of using the
root password, it will typically authenticate against their password although I think that's
also configurable. Pseudo has other problems, has a long history of problems. People write
policies that don't really make any sense for example like you can write a policy, this
user can use VI and what that means is you can just do bang in the thing and run a root
shell or whatever context you're in. More or less, there's like a million programs that
have this problem. You can do all kinds of other stuff as well. It's just not that secure
but my recommendation here would be to audit and audit the applications that you're allowing
users to run at a free and privileged context. Details of the problem, okay. So all these
programs, the thing, one of the things that have some common, they all have different
forms with SUH-C with the other one, new role, it's putting it just after the rest of the
command and so on. All this stuff is stored in the previous contexts, the unprivileged
context memory area and like I said so is the other vulnerable, sorry, the exploited
application is also in this same memory space more or less. Yeah, so that covers the first
three points. Modification of this memory can be easily done by placing a Trojan in
the Xecve code in libc. So I know you guys are a lot of technical guys here so I'm just
gonna, this isn't on my slides but I'll just explain a little bit about that. Basically,
using ptrace I inject code originally just to allocate memory using random stuff like
return to libc and stuff like that and basically allocate some memory, put my code there and
then memprotect libc so that I can actually overwrite the int 80 for going into the kernel
with a jump to my code that I've just allocated and then fixing it all up and then detaching
so it can run. So this is what you do to all the shells and anything that can run a shell
and all that kind of stuff. So whenever someone runs Xecve, su, whatever, the dash c and the
rest of the arguments will be appended. So I just wanna make it clear that these are
not attacks on the programs I'm discussing here, these are attacks on the way that the
shell actually deals with this stuff. So I think that might be kind of confusing because
everyone's like, well you can't ptrace a setuid application, well I'm not, I'm attacking the
actual shell that the user runs the su from and changing what they requested to do. Yeah,
you can also do this with ldpreload which is obviously not quite as exciting. Okay,
so this is the details of just the generic algorithm for it. You use proc or something
like that to find all the processes that are shells, what starts with dash sh, what starts
with slash sh, what starts with bash, whatever. Just look for all of them, attach to each
one and do as I just described back during Xecve. Now when you use, here's a perfect
example of how this works, you wanna run su-c cat var log messages is a typical thing system
administrators would do. And instead what you get is the, I inject this bad code here
and then also you're catting the messages there anyway. So this bad code is any shell
script or program or whatever that the policy or lack of policy allows you to run. Details
of the ldpreload, the ptrace is always more interesting to me but if anyone is to actually
make malware out of it, I would guess this is the way they do it since it would be so
simple and reliable. Basically Mozilla or whatever gets owned, it basically just overwrites
or appends to their profile, their shell profile and export the ldpreload to the location of
the path. One of the reasons I did the ptrace thing is because it never actually touches
the disk and doesn't leave any resident evidence. However, this probably would but it would
also be most likely more reliable. And so you have the exact same thing here. Now this
doesn't affect all current running shells as the ptrace one does but any shells that
they've invoked after their profile has been modified will be vulnerable now. Okay. I think
right now I'm gonna show you a little demo here which is gonna be tricky because I, I
can't open this microphone. Hold on a second. So this is a, this is an uninfected shell
right here. I'm gonna just ask you to root to show you that. Nothing, nothing abnormal
happens at all so that's okay. Now I'm gonna run the ptrace program here. This is, this,
you can just pretend this screen right here is like from within the context of Mozilla
or whatever. I'm sure you could see how that's possible. So and the number right there is
the process ID of the shell that I want to attack. I just run this, a lot of output there,
a lot of debugging output. Then we switch over here and now when I do SU, I just executed
ID in there on the root as you can see. It ran as root so this is not a trick. It actually
does work. And just a second and I'll show you the LD preload version of this as well.
In a new shell that's not infected. That's the important part right there. You need to
actually run a new shell for this actually to affect it because the LD preload affects
the application at the beginning of its run time. You can't do this while it's running.
Okay. And there you have another little gem there running ID and you can see it's running
as root obviously. Okay. So everybody got that. These demos I will show at the end are
there. These demos are available at the website. Can everyone read that? The first URL there?
Is that okay? If not, come up and ask me later. It's part of a larger project I'm doing
to basically prove that preventative security measures are probably better than these retroactive
measures such as antivirus. Anyway, I won't go into that in detail. I'm just going to
show you the code that you saw. There's some descriptions and documentation. So we're going
to go through all this code that you saw is available there. So workarounds and solutions.
How do we solve this problem? I think the most obvious thing is to remove the mechanism.
I think that as my hypothesis says that I think that work to be run as a privileged user should
be scheduled by someone who has already authenticated themselves as a privileged user, not by someone
else previously who may or may not be able to authenticate anyway. Now for SC Linux,
like I said, apply targeted policies to all network facing applications. And these days
that basically means everything. That means bash, that means your document viewers, your
PDF viewers, your email client, everything. And I don't think this is a terrible amount
of work. I mean it's obviously a lot of work, but I don't think it's a stretch to actually
do something like this. And instead of using a, okay, this is actually almost the same
point, but just use a targeted policy, a strict policy instead of the targeted policy. It
can find everything instead of just specifically what you think should be protected because
one of my points is here that I think everything should be protected. Moving on from that,
I want to say that for sudo, I think it is possible to actually secure this to some degree
with that if not completely secure it with that. I think if you have a strict enough
sudoers file, so that, and you have, especially if you have more than one user for different
tasks you want to accomplish, for example you have a user specifically for RPM and stuff
like that, you audit all the applications that are done for that. I think it might be
quite a bit of work, but I think it's completely a solvable problem. For su, I'm definitely
going to recommend that the best thing you do is remove the dash c option from that.
And I'm not really sure what else you can do. There's not really any kind of policy
for it or any kind of way you can control it that much. Yeah, sorry, I'm going to go
right to the third option there. You could use pam modules possibly to do this. There
are none that I know of that exist for Linux to do trusted path. However, trusted Solaire's
also has their own implementation of a trusted path module. I'm not completely sure if it
solves the problem, but I definitely think it should be looked into. And like I said,
obviously the second option is to use a lock down SE Linux or some variation of some pseudo
policy that would actually fix this problem. So, like my hypothesis, my conclusion is that
su new role blah blah blah all these should support the specification of a command to
run in the new security code before authentication. This can be, we should demonstrate that this
can be used to gain privileges without too much work at all. A proof of concept using...
Okay, that was already done. Anyway, yeah, I just want to thank you for this. I'm really
interested in people's feedback about this as much as possible. I'd like to know whether
you think this is a big deal or not. I've been working on this for about two years now.
This is, well, not the entire time obviously, but so it's not exactly new to me and it seems
obvious to me, but I'd like to know if there's anyone here that does policy or does any kind
of work on distributions or something, what they think about it. I want to say that, yeah,
I'm going to again point you here to my project that I'm working on here. It's just like some
code to support that it's probably a good idea to use mandatory access systems in just
various parts of trusted computing that probably should apply to desktop computing as well.
The source code is there of course. Then I want to say in June 2007, which seems to be
about the exact same time I thought about this, we both thought about it independently.
He used Ptrace to attack pseudo, with a program called PseudoJump. I think you might be able
to see his homepage there. You can go check it out. You can go see the mailing list thing.
What I actually suggest is that you search for his name and look at all the places that
he posted this on BugTrack, on just everything. The insecure.org archives, this posting shows
up in about ten different places and there's one response. I think that's probably not
an acceptable thing in the security community since this is such a problem. Well, in my
opinion it's such a problem, but like I said, I'm waiting for more feedback. Like I said
before, in trusted Solaris you have the PAM TP auth PAM module. It's not completely clear
whether this solves the problem, but we should definitely check that out and see what we
can do about that in Linux and BSD and Mac OS 10 and the rest of the Unix platforms that
are affected by this. I'm just going to end right there. If anyone has questions, please
feel free to raise your hand. Questions? Well, there's several levels to trusted path actually.
One of them is that you invoked the program you intended to invoke, which is the case
here. You did in fact use the pseudo from user bin SU or whatever and there's various
ways of compensating for that. For example, doing checksumming on the actual executable
that you're running or sorry, digital signatures probably even better, but that's the first
level of trusted path and the second level of trusted path here is that you did invoke
the program and it's behavior has been altered in a way that you did not intend. I don't
know how you would get a wrapper in there if you were actually running slash user slash
bin whatever. You would just be modifying the shell in a very similar way to this. Like
I said, there's more ways to do it than what I presented. Yeah, okay. Well, in trusted
computing it wouldn't actually respect your path. So that's kind of what I'm saying is
you'd have to invoke the specific application you intended to. Sorry, I couldn't hear that.
There we go. I think we're doing better. Make it a promise. That'll be as good, that'll
Yeah, okay, actually I agree with you on that completely.
Yeah, you're right.
And I heard a few other things too,
like someone suggested immutable memory as well,
and I think that it would also be vulnerable
to the problem you're discussing as well.
I think Ted Trent, sorry, Trent, his name is Trent
from Washington, one of his solutions was just
to disable P-Trace completely, which I'm not really sure
that the problem is P-Trace.
Honestly, I don't really know what the real solution
is here, but that's definitely an alternative as well.
Disable LD-preload, disable P-Trace, that kind of stuff.
But I don't know, I think maybe that a policy
affecting all of unprivileged applications
would probably help you though.
It just might be difficult to do that.
Yeah.
Yeah.
Yeah.
Yeah.
Yeah.
Okay.
Yeah.
Exactly, and I'm not an, I think it's pretty obvious
I'm not an expert in Trusted System,
I'm just the end user of it, and so I really don't know
how to solve the problem in the best, most appropriate way.
But yeah, I agree with you.
And sorry, who was saying that about sniffing the password,
I was gonna say that's also an issue of Trusted Path
to the path from your keyboard to the application
you're talking to, and Linux has some support for this,
typically through hardware and some complicated drivers,
but there's a lot of papers on how that works.
And this is kind of assuming that all those are in place.
Obviously they're not on my system,
but the Trusted Path with the actual path
and the Trusted Terminal as well,
but this would still affect that after that.
Any other questions?
Okay, thank you.
Thank you.