Re: Buffer Over-runs, was Open source firewalls

[RVK <rvk@prodmail.net>]

Arjan van de Ven wrote:

>On Fri, 2005-07-15 at 12:11 +0530, RVK wrote:
>
>  
>
>>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."
>>    
>>
>
>except this is no longer true really ;)
>
>randomisation for example makes this a lot harder to do.
>gcc level tricks to prevent buffer overflows are widely in use nowadays
>too (FORTIFY_SOURCE and -fstack-protector). The combination of this all
>makes it a LOT harder to actually exploit a buffer overflow on, say, a
>distribution like Fedora Core 4.
>
>
>  
>
Still is very new....not every one can immediately start using gcc 4.

rvk

>>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/
>>    
>>
>.
>
>  
>