Board index Linux Kernel

Stack growing and buffer overflows

Stack growing and buffer overflows

Post by Helge Haftin » Wed, 12 Mar 2003 12:10:12




> I like the idea of turning off execute permission on the stack pages.

It has been shown before that this has these disadvantages:
1. More work settting up those access bits   (bloat & perf. degradation)
2. Some programs actually need an exec stack (loss of features)
3. It don't buy you _any_ security at all!   (didn't help anyway)

About (3): Of course it stops some of the current exploits, but there is
a trivial way to "enhance" stack-smashing exploits to work around the
non-exec stack:

You can still overwrite the function's return address, on that non-exec
stack.  The cracker can no longer upload code and make the function
return to that, but crackers don't need to!  All they need is to return
to a place containing exec("/bin/sh") *and such places exist*,
paritcularly in every program using libc.  So writing the the exploit
becomes a little harder, using it is as trivial as ever.

Spend the time fixing broken apps, or get them right from the start.  It
is not as if writing safe C is _hard_.

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 
Top

Stack growing and buffer overflows

Post by =?unknown-8bit?Q?J=F6rn?= Enge » Wed, 12 Mar 2003 14:30:14



> on x86, the stack grows downwards (from higher memory addresses to
> lower memory addresses). This makes buffer overflows attacks easy to
> exploit: if a function uses strcpy() instead of strncpy() to copy
> data [...]

> However, what would happen if the stack was implemented to grow
> upwards [...]

Stack overflows by mistake would go unnoticed, bad.
Stakc overflows in order to gain root privileges take only little more
effort, no change.

Nothing gained, something lost.

J?rn

--
Geld macht nicht glcklich.
Glck macht nicht satt.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 
Top

1. Stack growing and buffer overflows

Hi `who | cut -f1 d' '`,

Lately, I have been reading some articles on buffer overflows. Many of them seem to be caused by using local
variables that are allocated on the stack and then written to with no proper bounds checking. I don't know of
other architectures, but on x86, the stack grows downwards (from higher memory addresses to lower memory
addresses). This makes buffer overflows attacks easy to exploit: if a function uses strcpy() instead of strncpy() to
copy data (or memset or anything else that normally works upwards), due to the downwards nature of the stack
implementation, it's possible to overwrite the function's return address, or even another function local data
waiting in the call stack -> the stack grows downwards, but strcpy() works upwards, thus being able to cross
stack function boundaries (overwritting other functions local data or even its return address).

However, what would happen if the stack was implemented to grow upwards (from lower memory addresses to
higher memory addresses)? With this kind of implementation, if the last function in the call stack invokes
strcpy() over a local variable (allocated onto the stack) without checking bounds, the extra data would not
overwrite neither the own function's return address nor any other function waiting onto the call stack -> the
stack grows upwards and so does strcpy() when writting memory.

I know there are hardware implementation details involved in this issue, like the way PUSH and POP work, but
this is just an idea :-)

Comments on this? Could this be viable? Is the whole idea stupid in general?

Thanks!

   Felipe Alfaro

--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr

Powered by Outblaze
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. WIn98 logon

3. executable stacks and buffer overflows?

4. DHCP client_id for a ms-windows-XP box

5. setuid root / buffer overflows - stack smashing

6. Advice for setting up a firewall

7. Buffer Overflows: Question about the internals of process creation and stack maintenence.

8. konqueror and socks

9. Possibel to implement system , such that Kernel stack grows on top of User Stack

10. double the buffer? - buffer overflows

11. syslogd grows and grows and grows on 2.6/x86

12. why does /var/adm/wtmp grow and grow and grow ...

13. "Cached" grows and grows and grows...


All times are UTC
Board index