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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |