< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [reSIProcate] Visual Studio 2005 compilation warnings of 1.4 branch


Matthias Moetje wrote:
> Adam,
> 
>> But it will be markedly slower when copying strings into buffers that 
>> are on the order of the correct size, which is by far the more common 
>> case -- you end up scanning the string twice to comply with the behavior 
>> specified for strcpy_s.
> 
> Very true, but I really doubt that it's possible to achieve the
> Behavior of the *_s functions (ie. not to copy anything to the 
> dest buffer if it's not large enough) without iterating through 
> the string two times....

Indeed, *but*, does this actually matter? I suggest that not copying
anything to the destination buffer if it is not large enough is a
feature which sounds good at first glance, but actually just wastes
time, without buying you extra security, in at least most cases.

>> If you want an alternate model to emulate, you're far better off with 
>> strlcpy -- you can perform the same checks as strcpy_s without the 
>> performance penalty (and it doesn't null-fill the buffer like strncpy).
> 
> I read about these strl* functions but I thought that those are 
> OpenBSD specific. If there are free implementations for all relevant 
> functions (not just for strlcpy) then I'd really be fine with 
> using this approach! (not just because it would avoid MSVC compiler
> warnings ;-)

The problem with a portable substitute is that it's quite possibly less
optimized than what the compiler/libc provide for the more traditional
string functions. Certainly that character-by-character copy in the
example strlcpy.c doesn't look very optimized to me!

Perhaps we should pause and consider what we're trying to do here.... it
seems to me that MSVC has added a load of compiler warnings that
complain about any use of functions that *can* be used in an insecure
way - not warnings about actual security problems. Also consider that
this is ares, 3rd-party imported code for which there is non-negligible
benefit in not increasing the delta compared with upstream any more than
it is already, and additionally, one day might get replaced entirely
with a new upstream version. Under those circumstances, my answer would
be to turn off the warnings, and *perhaps* audit the locations that are
warned about, fixing genuine security issues if any are discovered. I
don't think a complete porting to a new set of less standard library
functions is desirable here.

Max.

Attachment: signature.asc
Description: OpenPGP digital signature