Re: Some revelations about ssh and stackpatch

[achurch () DRAGONFIRE NET (Andy Church)]

> > 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.