Bugtraq mailing list archives
Re: WuFTPD: Providing *remote* root since at least1994
From: deraadt () CVS OPENBSD ORG (Theo de Raadt)
Date: Tue, 27 Jun 2000 17:22:18 -0600
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) saysThere 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.
Current thread:
- Re: WuFTPD: Providing *remote* root since at least1994, (continued)
- Re: WuFTPD: Providing *remote* root since at least1994 Gregory A Lundberg (Jun 27)
- ftpd: the advisory version Lamagra Argamal (Jun 23)
- Re: ftpd: the advisory version Bernd Luevelsmeyer (Jun 25)
- Re: ftpd: the advisory version Sebastian (Jun 26)
- [RHSA-2000:037-05] New Linux kernel fixes security bug bugzilla () REDHAT COM (Jun 26)
- LeafChat Denial of Service Andrew Lewis (Jun 25)
- Netscape Enterprise Server for NetWare Virtual Directory Vulnerab ility Peter Grundl (Jun 26)
- Re: ftpd: the advisory version Bernd Luevelsmeyer (Jun 25)
- Re: WuFTPD: Providing *remote* root since at least1994 Peter Pentchev (Jun 23)
- Re: WuFTPD: Providing *remote* root since at least1994 der Mouse (Jun 25)
- Re: WuFTPD: Providing *remote* root since at least1994 Mikael Olsson (Jun 26)
- Re: WuFTPD: Providing *remote* root since at least1994 Theo de Raadt (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Carson Gaspar (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Casper Dik (Jun 29)
- Re: WuFTPD: Providing *remote* root since at least1994 Eric Hines (Jun 29)
- Re: WuFTPD: Providing *remote* root since at least1994 Mikael Olsson (Jun 26)
- Re: WuFTPD: Providing *remote* root since at least1994 der Mouse (Jun 26)
- Re: WuFTPD: Providing *remote* root since at least1994 Henrik Nordstrom (Jun 27)
- Re: WuFTPD: Providing *remote* root since at least1994 Theo de Raadt (Jun 28)
- Re: WuFTPD: Providing *remote* root since at least1994 Valentin Nechayev (Jun 29)
- Re: WuFTPD: Providing *remote* root since at least1994 Kenn Humborg (Jun 29)
- Re: WuFTPD: Providing *remote* root since at least1994 Hudin Lucian (Jun 29)
- Multiple vulnerabilities in Sybergen Secure Desktop anders.ingeborn () INFOSEC SE (Jun 30)
- Re: WuFTPD: Providing *remote* root since at least1994 Henrik Nordstrom (Jun 27)