[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.025 / U:2.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site