[PLUG] Worms that attack Linux...

[Michael C. Robinson]

On Sun, 2003-11-09 at 23:02, Grish wrote:
> Michael C. Robinson wrote:
> 
> >What I don't get is how someone can do damage through
> >your web server.  Web servers aren't supposed
> >to be able to cause side affects on the machine they
> >are running on.  How are people getting web servers
> >on remote sites to run arbitrary code?
> >
> 
> Uh... Do you know what buffer overflows are?
> 
> You may have a lot to learn...
> 
> http://www.insecure.org/stf/mudge_buffer_overflow_tutorial.html
> http://www.insecure.org/stf/smashstack.txt

Well, I've known for a long time that C has some very poor
functions as far as no bounds checking goes.  I guess what
I don't get is why the system can't do bounds control and
catch an overflow attempt of any program running on it.
I thought in a Unix environment that users were kept
successfully within their own memory space.  One trick would
be to give prorgams enough room to overflow some in order 
to catch the problem.  I have a hard time following assembly 
code.  I guess the major point is that if you don't check data 
someone gives you it can be arbitrarily well conceived code 
that when it overflows some buffer it loads into it'll execute.  
In high level languages such as C++, overflow comes up and can 
be dealt with by good programming.  J Nix's course wasn't very 
good on this topic, this is one reason why I didn't go on 
to the Beowolf clustering section.

When you overflow a buffer don't you usually overwrite it 
from the beginning or top, rollover so to speak?  If an 
odometer rolls up to all nines it will flip to all 
zeroes, this is one form of overflow.

One thing I don't get, why does the stack grow down on
IA-32 from a fixed address?  This seems horrendously
limiting.  I never did get why it's supposedly better
to be on the stack than in RAM on an IA-32 machine 
since the stack isn't on the processor unless it's 
in cache memory.  Is it faster to access RAM from 
address zero on a PC than from other locations?

How many programs have been stack overflow audited
in Linux distributions?  Is there a way to run a 
virtual machine to audit for stack overflow?  Don't 
know how much that can help, if you overflow your 
virtual machine's memory space you'll probably 
still have your host system affected.  Seems the 
only answer is a compiler that actively breaks bad 
code before it executes, seems like it would be 
tricky to write one that smart.  Coming up with 
an executable analyzer that can catch binaries 
with stack overflow problems is something that 
might be doable.  If a stack overflow or seg 
fault happens, how does the exploit still manage 
to execute?  If only the OS could catch that 
an instuction will overflow soon enough to 
prevent the damage that can do.

-- 
-----------------------------
Michael C. Robinson

Associates of General Studies 
PCC March 2003.
-----------------------------