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