Re: [boost] [iostreams][vc8]deprecetedstandardlibrarymemberfunctions; fatal linker error [OT]

From: Martyn Lovell (martynl_at_[hidden])
Date: 2005-07-07 23:38:19

Pete,

Thanks for the feedback. We too spent some time debating the granularity of
deprecation. We do understand that different developers will take different
positions on which functions are 'dangerous'. What we wanted to do was draw
on our experience of real security holes we've fixed and deprecate the
functions which are a common source of security problems. This ensures that,
by default, we're not encouraging developers to use functions which we know
to be unsafe. 

Gets may be the very unusual case here - an API which it is almost
impossible to use safely. However, both fopen and strcpy share a similar
property - that it is possible to use them safely, but easy and common to
misuse them. Strcpy has the obvious well-understood buffer overrun risks,
while fopen has the similarly well-understood file-access-permissions
problems.

The list of functions we chose to deprecate was honed after working with
developers inside and outside of Microsoft, after looking at lots of code
fixes made to resolve security problems and after considering the impact of
each deprecation on the codebase of your application. It's changed
significantly during the lifetime of the project as we've received feedback
- we've both added and removed deprecations. Personally, I would not want to
use any of the current deprecated functions in an application that I wanted
to ship and secure. Because the cost of ensuring they are used correctly is
much higher than the cost of using the safer ones to start with.

Giving deprecation-subsets based on specific security problems would not
have been easy (since some functions have more than one problem), and would
have complicated the use of this feature significantly. Instead, we decided
to support a default set of deprecations that match our understanding of
what is 'unsafe', and then allow you to create your own deprecations if you
don't like ours. If you have your own list of functions to deprecate, you
can always replace ours. Because #pragma deprecate is a general compiler
feature, you can deprecate any sub or superset of functions that you wish
to. It's also very easy for you to distribute a header file with your
preferred set of deprecations for all your projects. 

If we find there are common deprecation-subsets that we don't support, then
we'd definitely want to revisit the issue of deprecation-subsets in our next
version. However, our experience so far has been that customers either want
more deprecated than we have (for example, because they also want to
deprecate some Win32 functions, or some library functions), or they don't
want any deprecation at all (for example, because they are writing portable
POSIX code).

If you have specific functions that you think should not be deprecated, we'd
definitely be interested to hear which they are and why. We are still in the
phase of the product where we can respond to feedback, and as was noted
elsewhere in this thread, we've recently found a couple of cases where we
had wrongly deprecated something.

> The choice between portable but "deprecated" and non-portable but secure 
> isn't very appealing either, but that's a separate issue. 

This is definitely an issue we want to address better in future. We have
already been working thru standardization to try to ensure there are
portable and safe choices available.

> I'd prefer the undeprecated version of sprintf to be snprintf instead of 
> sprintf_s, and the undeprecated version of swprintf to be swprintf (the 
> standard version of which wasn't insecure, only the Microsoft nonstandard 
> variation was.) 

First I should note that in VC8 for the first time we provide a
standard-conformant swprintf (with the extra int parameter, and the other
standard-conformant behaviours). We also provide a #define to revert to the
'old' VC7 swprintf.

Second, I think it's important to note that neither C99 snprintf nor C90
swprintf are safe - because both allow the highly-risky %n construct. At the
last C standard committee meeting we had a representative from CERT who
reemphasized to us how important it was to address the %n issue, which has
been exploited in the real world.

Third, even if you ignore the %n issue, our experience with strncpy has
taught us that these functions need two integer parameters, not one, so that
programmer-intended truncation can be distinguished from buggy buffer
overrun. 

snprintf_s addresses both of these issues. 

---
Let me end by encouraging you to turn on deprecation for a project you care
about, and see whether it deprecates anything inappropriate. I'd be
delighted to get any feedback you might have on our default deprecations, so
that we can ensure we've got the correct list. 
Thanks again,
Martyn Lovell
Development Lead
Visual C++ Libraries