Re: ssh-1.2.26 buffer overflow patch

[achurch () DRAGONFIRE NET (Andy Church)]

> Note lines 538-539 of login.c are:
>
>        log_msg("putuserattr S_LASTTTY %.900s failed: %.100s",
>            ttyname, strerror(errno));
>
> Also note that ttyname is generated by pty_allocate() at line 101 of
> pty.c from system calls on *all* systems.  (It is the "namebuf"
> parameter.)  And further note that ttyname is declared as a static
> buffer of 64 bytes at sshd.c:2732.

     Just for the record, I did go back and check this later, and
discovered this myself (and was about to mention it in another post to
Bugtraq, but changed my mind).  My point was that if you're going to use
%.NNNs to limit the length of strings, you need to be careful that you
actually stay within whatever buffer size you're using.  Finding even one
exception--and even one that can't be exploited--is disturbing, because
you start wondering if there might be others you haven't found yet.

     There is, of course, the possibility that some version of somebody's
libc doesn't handle %.NNNs correctly and happily writes out super-long
strings.  I seem to remember this being the case in an ancient version of
Linux (or some other?) libc, which may be why I've never used it myself.

     In either case, snprintf() saves you from overflows.  Unless you've
got one of the versions of libdb with the bogus snprintf() that just calls
sprintf(), but then you're royally screwed anyway.

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