Re: Buffer Over-runs, was Open source firewalls

[RVK <rvk@prodmail.net>]

Brian O'Mahoney wrote:

> First there are endless ways of stopping DAMAGE from buffer
> over-runs, from code that accepts user data, eg extend buffer, dont
> use dangerous strxxx functions .... so while you can move
> stuff to proxies, and that has been done extensively e.g.
> for sendmail it is a cop-out, far better fix the application;
>
> Next, while all buffer over runs are very bad it is only those
> that stamp on the stack, overwriting the return address stored
> there and implanting viral code to be executed, that are truely
> __EVIL__.
>
> To do that you need to know a lot of things, the architecture
> ie executing x86 code on a ppc will get you no-where, you must
> know, and be able to debug your mal-ware against a stable
> target, and this is why the _VERY_ slowly patched Windoze is
> so vulnerable, and finally you really need to know the stack
> base, top of stack, normally growing downward, and ... be able
> to actually run code out of the stack space;
>
> and if any one of these conditions are not true, eg I compiled
> sendmail with a newer GCC, stack is not executable, ...
>
> the exploit just fails or crashes an app and then you go after
> why?
>
>  
Even in the presence of non-executable stack, Linux Torvalds explains 
that "It's really easy. You do something like this: 1) overflow the 
buffer on the stack, so that the return value is overwritten by a 
pointer to the system() library function. 2) the next four bytes are 
crap (a "return pointer" for the system call, which you don't care 
about) 3) the next four bytes are a pointer to some random place in the 
shared library again that contains the string "/bin/sh" (and yes, just 
do a strings on the thing and you'll find it). Voila. You didn't have to 
write any code, the only thing you needed to know was where the library 
is loaded by default. And yes, it's library-specific, but hey, you just 
select one specific commonly used version to crash. Suddenly you have a 
root shell on the system. So it's not only doable, it's fairly trivial 
to do. In short, anybody who thinks that the non-executable stack gives 
them any real security is very very much living in a dream world. It may 
catch a few attacks for old binaries that have security problems, but 
the basic problem is that the binaries allow you to overwrite their 
stacks. And if they allow that, then they allow the above exploit. It 
probably takes all of five lines of changes to some existing exploit, 
and some random program to find out where in the address space the 
shared libraries tend to be loaded."


rvk

> but your system is not compromised.
>
> One final point, in practice, you get lots of unwanted packets
> off the internet, and in general you do not want them on your
> internal net, both for performance and security reasons, if you
> drop them on your router or firewall then you dont need to
> worry if the remote app is mal-ware.
>
> --
> mit freundlichen Grüßen, Brian.
>
> .
>
>  

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