Re: Problem exploiting a CGI overflow

[sin <sin () innocence-lost net>]

> The problem here is that some bytes in the shellcode are converted into
> 0x20. Namely, 0x0b (execve syscall number) is converted into 0x20 (gtty
> syscall number -- an unimplemented syscall), screwing up the execution of
> your shell.

hehe, yea that could be a problem. I didn't even think to check.


> The following special bytes pose similar problems: 0x09 ('\t'), 0x0a
> ('\n'), 0x0c ('\f') and 0x0d ('\r'). You should try to exploit the cgi
> with a special shellcode (note that you may also need to close stdin and
> re-open the tty -- see http://www.0xdeadbeef.info/code/gets-linux.c).

It seems like if bash is the one converting the characters, that you
should be able to bypass the problems by changing the exploit to call
execve() with argv/envp setup. Am I incorrect here?

As for not being able to return into envp like that, seeing as it's a CGI,
it seems like that would depend on the method used by the webserver, IIRC
get variables end up in the enviroment, and post variables come from
stdin, so if it used get, it seems like you would be able too.



--

There are only two choices in life. You either conform the truth to your desire,
or you conform your desire to the truth. Which choice are you making?
On Wed, 24 Nov 2004, Marco Ivaldi wrote:

> The problem here is that some bytes in the shellcode are converted into
> 0x20. Namely, 0x0b (execve syscall number) is converted into 0x20 (gtty
> syscall number -- an unimplemented syscall), screwing up the execution of
> your shell.
>
> $ strace ./post2 <buffer
> [...]
> read(0, "", 4096)                       = 0
> gtty(0xbffff7ec, 0xbffff7f4)            = -1 ENOSYS (Function not
> implemented)
> _exit(0)                                = ?
>
> The following special bytes pose similar problems: 0x09 ('\t'), 0x0a
> ('\n'), 0x0c ('\f') and 0x0d ('\r'). You should try to exploit the cgi
> with a special shellcode (note that you may also need to close stdin and
> re-open the tty -- see http://www.0xdeadbeef.info/code/gets-linux.c).
>
> Since i suppose you wanna build a remote exploit, ret-into-envp is useless
> here (i.e. you can't stuck your shellcode into the environment). Moreover,
> i don't think chained ret-into-libc may be feasible...
>
> I don't have enough time to play with that any further, but i hope you'll
> be able to find a viable solution ;)
>
> Cheers,
>
> --
> Marco Ivaldi
> Antifork Research, Inc.   http://0xdeadbeef.info/
> 3B05 C9C5 A2DE C3D7 4233  0394 EF85 2008 DBFD B707