Date: Wed, 4 Nov 1998 10:48:53 -0800 (PST) From: Marc Slemko <marcs@znep.com> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: FreeBSD-security@FreeBSD.ORG Subject: Re: [rootshell] Security Bulletin #25 (fwd) Message-ID: <Pine.BSF.4.03.9811041039590.11835-100000@alive.znep.com> In-Reply-To: <Pine.BSF.4.01.9811041946050.780-100000@aniwa.sky>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Nov 1998, Andrew McNaughton wrote:
> On Wed, 4 Nov 1998, Nicholas Charles Brawn wrote:
>
> > Well I just grabbed 1.2.26 and did:
> > find . -exec grep sprintf {} \; |wc -l
> >
> > And came up with 138 lines. Just having sprintf() in your code is not
> > indicative of a vulnerability, but it's still a high number.
>
> ssh is commonly used for piping substantial ammounts of data, and can
> probably claim good reasons for using the faster non-bounds-checking
> routines in many of these cases. Doesn't apply to low volume things like
> the logging routines though.
NO!
Get all ideas of bounds checking only being suitable for "low volume"
things out of your mind. First, if ssh is using sprintf for any bulk data
copies then it is horribly broken anyway. Second, by the very nature of
bulk data copies you have to have fixed bounds on the size of the data you
are copying.
Functions that do bounds checking, like snprintf() are not have any
significant performance drawbacks in 99.9% of the cases. There are far
more differences between sprintf implementations than between sprintf and
snprintf.
In fact, on FreeBSD sprintf() and snprintf() both call the same function,
the only difference is that sprintf sets _size to INT_MAX while snprintf
sets it to what you tell it.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.03.9811041039590.11835-100000>