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 [lcamtufat_private] [security] [http://lcamtuf.coredump.cx] <=-=> bash$ :(){ :|:&};: =-=> Did you know that clones never use mirrors? <=-= http://lcamtuf.coredump.cx/photo/
This archive was generated by hypermail 2b30 : Thu Apr 25 2002 - 07:30:47 PDT