Re: WuFTPD: Providing *remote* root since at least1994

From: Theo de Raadt (deraadt@CVS.OPENBSD.ORG)
Date: Wed Jun 28 2000 - 01:22:18 CEST

  • Next message: Gregory Neil Shapiro: "Re: [TL-Security-Announce] Linux Kernel TLSA2000013-1"

    > > > Not to mention that could still be overflowable. snprintf() doesn't
    > > > null terminate.
    > >
    > > Then IMO it's broken - what's your reference for thinking it doesn't?
    > > The only snprintf manpage I have at hand (NetBSD's) says
    > There was quite a bit of discussion about the behavior of snprintf()
    > a while ago; can't quite remember on which list it was though.

    Various lists. In summary, Chris Torek, Casper Dik, Todd Miller and I
    talked to various standards commitees who had published faulty
    documentation, and we had them repair things.

    Various groups had published draft documentation which showed that the
    documentation authors never did any testing of what they were writing.
    At the time we looked into it, only one operating system behaved the
    exact way that they had documented it (Solaris) and that was because
    Solaris had implimented their broken specification after draft

    Solaris has now been fixed.

    The various standards now document things as BSD snprintf has always

    > The consensus was that "(default libs of) different OSes behave
    > completely differently", so if you want to be cross-platform
    > (or cross-major-version), you can't assume that snprintf() terminates.
    > You need to do a mystring[sizeof(mystring)-1]='\0' after the call
    > to be on the safe side.
    > And, no, this wasn't just "lame OS" standard behaviour; it differs
    > between different unix dialects.
    > I also _think_ I remember posts saying that ANSI C doesn't require
    > snprintf() to null terminate. (Don't quote me on that though)

    Please consider very carefully where advice like that leads us. If we
    don't fix stupid documentation errors like that quickly, and we start
    advising people to not trust the calls they make, we will eventually
    end up with a complete mess of code which is far worse than if we were
    to just remedy the situation. I mean... if you really want internet
    programmers to write worse code, there is no better way than to loosen
    up the specifications for the most important functions to the point
    where they are uesless; it leads to a world where each programmer
    spends their life writing gobs of checking code and makes even more

    Trust snprintf. Test it if you wish. If you find an implimentation
    that is wrong, slag your vendor publically without showing mercy.

    This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 10:13:16 CEST