[8421] in bugtraq
Re: Some revelations about ssh and stackpatch
daemon@ATHENA.MIT.EDU (Andy Church)
Thu Nov 5 12:26:50 1998
Date: Wed, 4 Nov 1998 13:05:46 EST
Reply-To: Andy Church <achurch@DRAGONFIRE.NET>
From: Andy Church <achurch@DRAGONFIRE.NET>
To: BUGTRAQ@NETSPACE.ORG
>> execl("/path_to_sshd/sshd","AAAAAA....[about 2000]",0);
>> 'Cos I have stackpatch applied I saw something very strange in my
>> logs:
>> Nov 2 16:29:52 emsi <BUFFER OVERRUN ATTEMPT>[21738]: log: Server listening on port 22.
>> Nov 2 16:29:52 emsi <BUFFER OVERRUN ATTEMPT>[21738]: log: Generating 768 bit RSA key.
>> Nov 2 16:29:53 emsi <BUFFER OVERRUN ATTEMPT>[21738]: log: RSA key generation complete.
>
>"<BUFFER OVERRUN ATTEMPT>" means that syslog() in (Linux) libc does not
>like your argv[0], this is not a feature or bug or anything of sshd
Just for completeness, I should note that you can apparently
overflow sshd via log_msg() if you give it a super-long argv[0]. Relevant
code: (sshd.c:642-644)
execvp(saved_argv[0], saved_argv);
log_msg("RESTART FAILED: av[0]='%s', error: %s.",
saved_argv[0], strerror(errno));
Here, sshd tries to restart after getting SIGHUP. If argv[0] is an exploit
string, then trying to execvp() it will presumably fail, and the next call
to log_msg() will (if you haven't updated log_msg() to use snprintf()) dump
your exploit code onto the stack. saved_argv isn't referenced anywhere
else in sshd except to set it equal to av at the top of main(), and I
didn't see anywhere that modified av[0]. But unless your sshd is setuid
root, I can't see a way to exploit it.
Hm, that execvp() call looks a bit suspicious... wasn't sendmail
changed some time back to avoid relying on $PATH?
--Andy Church | If Bell Atlantic really is the heart
achurch@dragonfire.net | of communication, then it desperately
http://achurch.dragonfire.net/ | needs a quadruple bypass.
