[lkml]   [2005]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Sabotaged PaXtest (was: Re: Patch 4/6 randomize the stack pointer)
> and how do you force a program to call that function and then to execute
> your shellcode? In other words: i challenge you to show a working
> (simulated) exploit on Fedora (on the latest fc4 devel version, etc.)
> that does that.

i don't have any Fedora but i think i know roughly what you're doing,
if some of the stuff below wouldn't work, let me know.

> You can simulate the overflow itself so no need to find any real
> application vulnerability, but show me _working code_ (or a convincing
> description) that can call glibc's do_make_stack_executable() (or the
> 'many ways of doing this'), _and_ will end up executing your shell code
> as well.

ok, since i get to make it up, here's the exploitable application
then the exploit method (just the payload, i hope it's obvious
how it works).

int parse_something(char * field, char * user_input) {
strcpy(field, user_input+maybe_some_offset);
int some_function(char * user_input, ...) {
char field1[BUFLEN];
parse_something(field1, user_input);

the stack just before the overflow looks like this:
[other locals]
[saved EBP]
[saved EIP]

the overflow hits field1 and whatever is deemed necessary from
that point on. i'll do this:

[field1 and other locals replaced with shellcode]
[saved EBP replaced with anything in this case]
[saved EIP replaced with address of dl_make_stack_executable()]
[user_input left in place, i.e., overflow ends before this]

dl_make_stack_executable() will nicely return into user_input
(at which time the stack has already become executable).

as you can see in this particular case even a traditional strcpy()
based overflow can get around ascii-armor and FORTIFY_SOURCE. if the
overflow was of a different (more real-life, i'd say) nature, then
it could very well be based on memcpy() which can copy 0 bytes and has
no problems with ascii armor, or multiple overflows triggered from
the same function (think parse_something() getting called in a parser
loop) where you can compose more than one 0 byte on the stack, or
not be based on any particular C library function and then all bets
are off as to what one can/cannot do.

if there's an address pointing back into the overflowed buffer
somewhere deeper in the stack then i could have a payload like:

[saved EIP replaced with the address of a suitable 'retn' insn]
[more addresses of 'retn']
[address of dl_make_stack_executable()]
[pointer (in)to the overflowed buffer (shellcode)]

(this is actually the stack layout that a recent paper analysing
ASLR used/assumed [1]). note that this particular exploit method
would be greatly mitigated by a stack layout created by SSP [2]
(meaning the local variable reordering, not the canary stuff).

i could have also replaced the saved EBP (which becomes ESP
eventually) with a suitable address (not necessarily on the stack
even) where i can find (create) the

[address of dl_make_stack_executable()]
[shellcode address]

pattern (during earlier interactions with the exploited application),
but it requires whole application memory analysis (which you can bet
any exploit writer worth his salt would do).

speaking of ASLR/randomization, all that they mean for the above is
a constant work factor (short of info leaking, of course), in the
ES case it's something like 12 bits, for PaX it's 15-16 bits (on i386).


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:10    [W:0.125 / U:24.940 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site