Re: Non-executable stack
Re: Non-executable stack
- Subject: Re: Non-executable stack
- From: Pelle Johansson <email@hidden>
- Date: Wed, 2 Apr 2003 16:32:04 +0200
tisdagen den 1 april 2003 kl 05.54 skrev Jim Magee:
Besides, all this is on the assumption that you have to execute code
on the stack. More common (from a PowerPC hack perspective) is to
just change link register values saved on the stack to trick the
program into running code that already exists (the blr instruction is
used to both call and return from a function). The only stuff that
has to be on the stack is the argument data and the stomped address.
Jumping to the well-known address for the system() library routine
should do nicely. ;-)
A very limited approach. You already need to have stdin and stdout as
the right descriptors for example. Good enough for local exploits I
suppose.
In fact, arranging to execute code just written on the stack is fairly
tricky on the PowerPC. You have to manually synchronize the icache to
the dcache. Finding code to do that in an existing application (since
you can't reliably execute even it from the stack until you run it)
and then getting a branch back to your code is much less likely to be
successful. I can only imagine that was one of the thoughts behind
the processors lack of granular no-execute permissions. Most data
pages "behave" that way often enough (because of the cache issues) to
sway hackers into other means (like the one I described above which
would not be helped by no-execute permissions on any data).
I've found this to not be true in practise. At least if the stack is
not already in the dcache (which is likely if you've been sleeping
inside a read() or similar), the code will load just fine. If you are
restricted to not having any null bytes in your code, it's a bit harder
(the icache has to be flushed), but it can simply be solved by putting
a sufficiently large loop in your code, forcing a context switch before
the rest of the code is run.
Out of curiosity, I've always wondered why the ABI grows the stack
downwards. It seems to be just as easy to grow it upwards, which would
make buffer overflows much harder, if not impossible.
And for the record, no I'm not a hacker, I just have an interest in
these things.
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.