[15503] in bugtraq
Re: WuFTPD: Providing *remote* root since at least1994
daemon@ATHENA.MIT.EDU (der Mouse)
Tue Jun 27 18:45:22 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <200006262001.QAA03177@Twig.Rodents.Montreal.QC.CA>
Date: Mon, 26 Jun 2000 16:01:43 -0400
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
To: BUGTRAQ@SECURITYFOCUS.COM
>>> snprintf() doesn't null terminate.
>> Then IMO it's broken [...]
> There was quite a bit of discussion about [this] [...]
> You need to do a mystring[sizeof(mystring)-1]='\0' after the call to
> be on the safe side.
As I remarked to someone else privately (that message wasn't sent to
bugtraq), there comes a point where you have to say "your system's
version of foo() is so broken I'm not going to try to work around its
bugs".
And - IMO, of course - an snprintf that doesn't NUL-terminate is past
that point.
> I also _think_ I remember posts saying that ANSI C doesn't require
> snprintf() to null terminate. (Don't quote me on that though)
Well, IIRC snprintf() isn't specified by ANSI C at all, which would
make this technically true but rather misleading.
Of course, it's been a while since I made any effort to bring my
knowledge of ANSI/ISO C up to current, so this could well have changed.
Regardless of what ANSI may say, though, I still consider it a serious
bug for snprintf() to fail to NUL-terminate, except when the size
parameter is zero.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
