Re: security enhacement to C runtime library (XXX_s)
- From: websnarf@xxxxxxxxx
- Date: 21 Apr 2007 19:48:15 -0700
On Apr 5, 4:31 am, "artun" <muratar...@xxxxxxxxx> wrote:
Hello,
In the below link MS announces a security update to the C runtime
library which most of the group members are possibly aware of:
http://msdn2.microsoft.com/en-us/library/8ef0s5kh(VS.80).aspx
As far as I could understand with this still non-standard approach,
the error is detected in more details. So by using a XXX_s version of
a runtime library function we can have more detailed knowledge about
the source of the error that causes the security defect. However, if
our code is a cross platform standard C code we loose the standard.
Correct. From a practical point of view, all updates to the ANSI C
standard, including future proposal are, at this point, is the same
category as non-portable compiler specific extensions. This library
proposal is no exception.
I want to discuss if this security enhancement covered in XXX_s like
functions is still necessary.
Can we achieve the same security by by giving the length (i.e. using
snprintf instead of sprintf) with some loose of extra knowledge?
Mostly, yes. And conversely this library can lose its supposed safety
by putting wrong values for these lengths, (or overly large lengths
such as RSIZE_MAX that lead to a "do nothing" for the length check).
You should not be deceived by the name of this proposal, remember that
Microsoft has a very active PR department. Though, the library does
propose a few functions that solve the re-entrancy issue.
Objectively speaking this proposal changes the way in which buffer
overflow errors occur rather than going to any trouble to solving
them. Every buffer overflow error that was made before can still be
made, its just that the results might be different. There are also
new error modes introduced -- namely mismatching the length with the
buffers.
You see, buffer overflows basically happen because people want to use
strings in C the way they are used in every other programming
language. But the programmer makes some sort of error in which they
have ignored or omitted considerations for the limits of the C-style
strings. This proposal is trying to make these limitations more
apparent, and thus they think they are addressing the problem. But,
it doesn't address the core issue which is that programmers want to
use strings in C like they do in every other language.
So the remaining question becomes: how can we increase the programmer
safety (perhaps by making a proposal for strings that more closely
matches what programmers want) with strings in C while remaining
portable? The answer is in my last signature link.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
.
- Follow-Ups:
- Re: security enhacement to C runtime library (XXX_s)
- From: Douglas A. Gwyn
- Re: security enhacement to C runtime library (XXX_s)
- From: Nick Maclaren
- Re: security enhacement to C runtime library (XXX_s)
- References:
- security enhacement to C runtime library (XXX_s)
- From: artun
- security enhacement to C runtime library (XXX_s)
- Prev by Date: Character constants
- Next by Date: Re: security enhacement to C runtime library (XXX_s)
- Previous by thread: Re: security enhacement to C runtime library (XXX_s)
- Next by thread: Re: security enhacement to C runtime library (XXX_s)
- Index(es):
Relevant Pages
|
Loading
