[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: linux-kernel-digest V1 #4993
From:       "Theodore Y. Ts'o" <tytso () mit ! edu>
Date:       1999-12-31 16:20:14
[Download RAW message or body]

   Date:   Fri, 31 Dec 1999 04:29:55 -0800 (PST)
   From: Robert Dinse <nanook@eskimo.com>

   This is a more difficult problem though, because ANY change in the binary
   will change that location and you can't pad it with 8k of nulls to make an
   approximation adequate.

In practice, this isn't a problem, because of the distributions imposing
a large amount of homogeneity.  Assume that the attacker has access to a
copy of the sendmail binary as shipped by the lastest version of RedHat,
Debian, and Suse (add your own favorite distribution if that makes you
happier).  That covers the vast majority installations right there.

   In all likelihood, the conventional attack is going to be tried first
   because it's easiler.  And that, with the non-executable stack in
   place, will be logged, so you know you're being attacked and have an
   opportunity to deal with it.

Very bad assumption.  This assumes that attackers aren't stupid, and
won't adapt to their environment.  The attackers will probably use the
attack which targets the RedHat sendmail binary first, since that has
the highest probability of working, *and*, if it fails, will only result
in sendmail core dumping, which might not even get logged.  It would
then be followed by specific attacks against other distributions --- or,
if "telnet" or some other indication is helpful enough to identify the
machine as being a Suse or Debian machine, then the attacker will simply
use that specific attack first.  The conventional attack will be the
last one that would get used, simply because it has a higher chance of
causing the attacker to get caught.

	Look, if you're going to demand that any security fix be a 100% fix,
   nothing will EVER progress in the arena of security because nothing
   is 100%.  You can only make it harder, more difficult to penetrate.
   That is all you CAN do.  That's life, that's reality.  Maybe it bites
   or bytes... But that's it.

I've done a lot of work on security in my day (I chair the IP Security
working group, was development lead for Kerberos, and am on the Security
Area Directorate of the Internet Engineering Task Force, the standards
body for the Internet).  So, it might just possible that I know
something about the concept.

Sure, nothing in life is ever 100%.  But at the same time, you have to
remember that the attackers of necessity can move faster than we can;
suppose we put some kind of security hack into the kernel.  The crackers
can start analyzing it and trying to find ways around it long before
distributions pick up the new kernel, and long before people start
upgrading their production machines to use the new release.  That has to
be taken into account when trying to assess the costs and the benefits.
If the hack doesn't address the fundamental issue, but simply requires
that the crackers change their tools slightly to exploit the problem
(which hasn't gone away), one has to ask whether or not it's worth it.

   Date: Thu, 30 Dec 1999 22:49:47 -0500 (EST)
   From: Gregory Maxwell <greg@linuxpower.cx>

   No, this is not an approiate comparison. You are intentionally confusing
   the issues.

   Some attacks are simply NOT possible with the patch, sometimes the binary
   does not contain any useful exploitable code.

Just about any binary will have exploitable code.  Any program that
calls any one of these system calls can have enough exploitable code to
do a lot of damage:

	open, unlink, exec, rename, link, chmod, chown
	(and there are probably others)

Remember, a stack smasher can arrange to have pretty much arbitrary
arguments on the stack.  The only thing it needs to do is transfer
control to the appropriate "call" instruction in the text segment.  Even
if the attacker needs to smash the stack multiple times to execute each
system call, this can often be done, especially if the daemon is started
out of inetd.  So it's a much bigger hole that you might think.


   Date: Fri, 31 Dec 1999 13:45:04 +0100 (MET)
   From: R.E.Wolff@BitWizard.nl (Rogier Wolff)

   > 	* at program start time, randomly changing the starting point of
   > 		the stack by a few hundred kilbytes.  (Since the starting
   > 		location is changing randomly for every program
   > 		invocation, guesses based on one process doesn't help
   > 		eliminate possible guesses on another process.)

   This is one of the measures that you argued against with your very
   good antibiotics analogy.

   - Attacks will simply have to find a static buffer with data to return
   to or, return to a fixed address that happens to have the right
   calling sequence.

Very true; but the same criticism extends to the non-executable stack
patch.  And this doesn't require making nearly as hairy a kernel change,
and it doesn't restrict compilers (possibly non-C compilers) from using
trampoline code.

   - Randomly changing the starting point of the stack won't help against
   deamons that are dynamically restarted when they get killed. If they
   fork off a master httpd, like apache, they are most likely setup with
   the same stack offset, so you can systematically test all
   possibilities, say at 0.5k at a time (0.5k of nops). So you'll need
   256 tries to scan a 128k window of stack-offsets. 

That's true.  If you fork off a master process, like Apache, then in
order to gain protection each child process would need to add some
random amount to its stack.  

   If they are exec-ed like ftpd's then you have a statistical chance of
   getting it right, on average once every 256 times.

That's a much more serious issue.  It can be partially addressed by
having inetd cut off a daemon if it sees more than a few processes die
abnormally due to a SegV, or some such, though.  It would probably be a
good idea for sendmail to do the same thing; if it spawns children
processes which die unexpectedly, logging an emergency security syslog
and then shutting down (after chmoding itself to 0 to prevent local
execution of the binary) might be the wisest course of action.  Anyone
want to try modifying sendmail to do that?

Again, I point out some of these examples just to show that if the rule
"anything to add an extra layer of security" is so important, there are
things that can be done that don't require kernel hacks.  Ultimately,
the best solution is to fix the possibility for overruns in the
application code itself.

						- Ted


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

[prev in list] [next in list] [prev in thread] [next in thread]