[15539] in bugtraq
Re: WuFTPD: Providing *remote* root since at least1994
daemon@ATHENA.MIT.EDU (Theo de Raadt)
Wed Jun 28 19:59:22 2000
Message-ID: <200006272322.e5RNMIv18874@cvs.openbsd.org>
Date: Tue, 27 Jun 2000 17:22:18 -0600
Reply-To: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
From: Theo de Raadt <deraadt@CVS.OPENBSD.ORG>
X-To: Mikael Olsson <mikael.olsson@ENTERNET.SE>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Mon, 26 Jun 2000 21:51:28 +0200."
<3957B440.4114A67A@enternet.se>
> > > 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
publication.
Solaris has now been fixed.
The various standards now document things as BSD snprintf has always
behaved.
> 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
errors.
Trust snprintf. Test it if you wish. If you find an implimentation
that is wrong, slag your vendor publically without showing mercy.
