 Strsafe.h: Safer String Handling in C
started 7/8/2002; 6:08:58 AM - last post 7/9/2002; 3:19:52 PM
|
|
Dan Shappir - Strsafe.h: Safer String Handling in C 
7/8/2002; 6:08:58 AM (reads: 2086, responses: 9)
|
|
| Strsafe.h: Safer String Handling in C |
|
Poor buffer handling is implicated in many security issues that involve buffer overruns. The functions defined in Strsafe.h provide additional processing for proper buffer handling in your code. For this reason, they are intended to replace their built-in C/C++ counterparts as well as specific Microsoft® Windows® implementations.
Ever the one to embrace and extend Microsoft now targets the good old C std strings library. This is a minor thing when compared to what they've done to most every other programming language in the context of .NET . Still, it'd be interesting to see if the C community accepts the convention of the HRESULT function return value.
Posted to Software-Eng by Dan Shappir on 7/8/02; 6:38:35 AM
|
|
|
|
Jo Totland - Re: Strsafe.h: Safer String Handling in C
7/8/2002; 11:24:14 AM (reads: 1245, responses: 1)
|
|
|
Well, from a C programmer perspective, it's hard to argue that these functions are not in fact better, because they are. Null-terminating the result even if the function failed will give fewer buffer-overruns. And a common result value like HRESULT, makes it much easier to check the result (see the example of the simple, but very useful SUCCEEDED macro).
These functions are easily implemented either by wrapping the functions in the standard library, or writing them from scratch (in either case, it's a simple textbook exercise). If other people than Microsoft want to do so in their own projects (which is probably a good idea, although there exists lots of alternative "safer" C string libraries already), then they are probably going to choose another naming convention. I doubt you will see this in any C standard soon, and I also think it's wrong to call this extend and embrace, it's simply good software engineering.
|
|
Ehud Lamm - Re: Strsafe.h: Safer String Handling in C
7/8/2002; 12:02:21 PM (reads: 1293, responses: 0)
|
|
|
Um, isn't it good software engineering when you choose a good language to begin with?
|
|
Patrick Logan - Re: Strsafe.h: Safer String Handling in C
7/8/2002; 2:45:31 PM (reads: 1206, responses: 0)
|
|
|
I have not looked at this solution in particular, but I came across several safer string libraries back when I was using C.
The one I learned and later wrote again allocated space for the string and the length. The pointer was aimed at the first character. The length field was "above" the pointer and the 0 terminated characters were below the character. This made it easy to take advantage of the std functions in the implementation of the safer library.
|
|
Chris - Re: Strsafe.h: Safer String Handling in C
7/8/2002; 8:08:09 PM (reads: 1187, responses: 0)
|
|
|
Ever security conscious, OpenBSD created some safer alternatives to strcat() and strcpy(). This paper was co-written by Theo de Raadt. It is short and to the point. It describes why even the "safe" strncat() and strncpy() are still difficult to use safely and have unnecessary performance problems.
strlcpy and strlcat - consistent, safe, string copy and concatenation
strlcat() and strlcpy() have since been adopted by the OpenBSD, FreeBSD, NetBSD, and Solaris libc libraries. Surprisingly (?) GNU glibc has does not provide these functions..
|
|
Dan Shappir - Re: Strsafe.h: Safer String Handling in C
7/9/2002; 2:52:19 AM (reads: 1171, responses: 1)
|
|
|
Embrace and extend was definitely tongue in cheek especially when you compare this to what Microsoft has done in the context of .NET . Still when you consider the "standard" safe string functions have been available for a while (as Chris has shown) and yet Microsoft has elected to create its own variant, you get my drift.
The technique proposed by Patrick is the same one used by COM basic strings (BSTR). The upside is obvious - you can use these strings wherever a "standard" string is expected. On the downside type safety is lost because you can't tell them apart from "standard" strings. This problem has bitten many a COM programmer on the arse.
|
|
Ehud Lamm - Re: Strsafe.h: Safer String Handling in C
7/9/2002; 5:35:42 AM (reads: 1217, responses: 0)
|
|
|
Two observations. First, notice that reuse is hard. Choosing from what's available (but isn't really standard) is often harder than designing your own variant (and since nothing is standard, there's no real harm).
Second, notice that the type safety angle is crucial here. You can process strings not via their access routines but simply by giving array subscripts. Since the language doesn't do range checking you are doomed. Cool langugaes (e.g., Ada) allow you to work on slices of arrays, and still enjoy range checking etc.
(By the way, Ada only supports simple, one dimensional slices. In PL/I you could do much more elaborate things - and obfsucate your code to your heart's desire).
|
|
Dan Shappir - Re: Strsafe.h: Safer String Handling in C
7/9/2002; 9:05:49 AM (reads: 1148, responses: 1)
|
|
|
Ah, to check or not to check that is the question. STL explicitly decided not to do range checking because it was assumed that C++ programmers would not accept the performance overhead, minor as it may be (and a smart compiler may be able to remove most of this overhead as well). Still std::string does do range checking when asked to.
And yes, we all know that C/C++ arrays are evil (so sayth the FAQ).
|
|
Ehud Lamm - Re: Strsafe.h: Safer String Handling in C
7/9/2002; 12:38:36 PM (reads: 1186, responses: 0)
|
|
|
Just to clarify (quibble?), the point is that in safe languages the range checking for strings is just a special case of range checking done for all arrays subscripts. It's a type system issue, not a library issue.
|
|
Chris - Re: Strsafe.h: Safer String Handling in C
7/9/2002; 3:19:52 PM (reads: 1127, responses: 0)
|
|
|
I often wonder why strcat() and friends still exist. Since safer alternatives exist (strncat() and strlcat()), why not remove the dangerous functions from the libc headers? Or at least move the prototypes for the dangerous functions to a new header file with an obvious name, such as "bufferoverflow.h" or "securityrisk.h"?
I know Microsoft always favors backwards compatibility over safety, but GNU glibc and Linux could probably get away with dropping some backwards compatibility. If GNU is Not Unix, shouldn't it be encouraging known best practices rather than following dangerous Unix "standards"?
|
|
|
|