Vulnerability Development mailing list archives

Re: /lib/ld-2.2.4.so


From: Michal Zalewski <lcamtuf () coredump cx>
Date: Wed, 24 Apr 2002 23:18:28 -0400 (EDT)

On Wed, 24 Apr 2002, FozZy wrote:

Well, not "always". I used to be on a system where home partitions,
/tmp, and any place where you can write something, were mounted as
noexec. There was also no compiler, etc. But, with this trick a cracker
could upload his favorite binary exploit and easily run it.

This is an old trick (I believe I've seen some examples of this on BUGTRAQ
years ago), but it is not a bug. Here's why: Linux architecture, by
default, is not supposed to stop attackers from executing their own,
hostile code once they got shell-level access to your system. Options like
"noexec" are hardly of any security value, and it is a great mistake to
believe otherwise. I wouldn't even say they make attacks more difficult
for script kiddies - unless your system can be compromised by real newbies
- in this case, you're in trouble, but not because of not having "noexec"
enabled.

So... Even if you have your noexec configured perfectly, the attacker can
invoke perl, awk, exploit some feature in bash or any other interpreter.
You surely have a bunch of them. He (or she) can overflow some obscure
function in, say, /usr/bin/dvipdf or any other of few thousand
applications that were never audited, as they deal with "trusted" input
coming from shell users, and run with user's privileges. He can abuse
LD_PRELOAD or any other setting of dozens of libraries your programs use.
He can mess with ptrace. Or, if his hostile code is simply an exploit, for
most local bugs, he can simply pass shellode to the vulnerable program by
hand. I really hope I'm stating the obvious. You can hack up your
bare-bone system to elliminate virtually any possibility of code
execution, leaving only very minimal set of audited tools, but the effort
needed to do it is excessive and functionality impact is pretty severe.
You can elliminate single possibilities, such as LD_PRELOAD or ptrace, but
call me when you are sure you got rid of *every* simple possibility (and
your system still boots ;-). I do believe that minimalism is bad for
typical applications, hate when I can't execute gcc for "security reasons"
on a multipurpose server that probably does not run tactical missile
control software. Security features that hurt functionality more than they
improve the integrity of your systems are flawed by design. Even if you
have lots of functionality to spare. Period.

Default Linux shells do not extensively support trust / access control.
And even if you install third-party ACL solutions, hack your kernel, chmod
few binaries, this is not really a way to control untrusted users with
shell access, because, for some unclear reason, you're equipping the
attacker with a powerful but restricted tool. He will find the way to
bypass your restrictions, sooner or later. It is better to give him a
simple tool you can control better. Typical multipurpose shells are not
designed to prevent people from doing whatever they want. Au contraire!
They are designed to let them do whatever they want in many simple ways.
There are million possible ways to do the same thing. If your shell
interface is unreasonably complex compared to the functionality you want
to offer your users, you end up having severe problems controlling it on
any level. Giving the shell to an untrusted party, and, later, taking away
permissions to do certain things, is not the way to go - the attacker is
ALWAYS ahead of you. The way to go is to refrain from providing full shell
access to untrusted users if they do not have to be able to execute any
program with any parameters or load their own code. Consider using your
own minimal shell where you implictly define what is allowed on your
system. Sure, it takes some time to write it or customize third-party
code, but it pays. This is not perfect, but gives much better starting
point to access / execution control.

-- 
_____________________________________________________
Michal Zalewski [lcamtuf () bos bindview com] [security]
[http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};:
=-=> Did you know that clones never use mirrors? <=-=
          http://lcamtuf.coredump.cx/photo/


Current thread: