> 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: [...] [field1] [other locals] [saved EBP] [saved EIP] [user_input] [...] 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: [...] [shellcode] [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). [1] http://www.stanford.edu/~blp/papers/asrandom.pdf [2] http://www.trl.ibm.com/projects/security/ssp/ - 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/