Are there any free implementations of strcpy_s and/or TR24731-1?

Question

I have an old project that is mixed C and C++. It makes extensive use of C strings and of strcpy,strcat,strncpy,strncat etc. I've uncovered a number of buffer overflows, and I'd like to use more secure functions, such as strcpy_s. MSVC includes those functions, but I need something that will work on various platforms - linux, osx, and windows at the least.

I do know of strlcpy, but as plenty of people have noted (example), it really isn't an improvement.

---

So: Are there any free implementations of strcpy_s, strcat_s, etc, or of the entire TR24731-1?

I need something that's either public domain or BSD, but if you know of implementations under other licenses, go ahead and list them - I'm sure someone else will benefit.

Solution 1

Try with the Safe C library. It's under the MIT license and according to this list implements the functions you're looking for:

The Safe C Library provides bound checking memory and string functions per ISO/IEC TR24731. These functions are alternative functions to the existing standard C library that promote safer, more secure programming

Solution 2

You can use memcpy and memset etc, which are portable and safer than string functions.

Solution 3

Why not using strncpy and strncat? Contrary to strlcpy and strlcat, they are standard C functions. These functions are not perfect but you can use them safely.

And also note that the bounds-checking _s functions are optional in the current Standard.

Comments

[Joey Adams]

Is the MIT license okay? It's basically BSD-3 without the third clause, if I'm not mistaken.

[Mark]

Yes, MIT is fine. I forgot to mention it. Thx :)

[Dietrich Epp]

You may be interested in using mudflap on Linux. From the documentation: "Modules so instrumented should be immune to buffer overflows, invalid heap use, and some other classes of C/C++ programming errors." It is enabled by -fmudflap on GCC, requires installing the mudflap library, but probably should be avoided for the C++ parts.

[ShadowRanger]

As an alternative, avoiding a separate library, you can abuse the (standard as of C99) snprintf to accomplish the task correctly/safely (if possibly ever-so-slightly slower due to format string handling). A bad strncpy(dst, src, dstlen) can convert directly to a good snprintf(dst, dstlen, "%s", src);; it even returns the number of characters written, so you can test for truncation (if the return value is >= dstlen, the output was truncated).

[Stephen Canon]

strncpy and strncat have some issues that make it hard to use them safely and efficiently; they do not guarantee NUL termination of the destination buffer, but they also do more work than is required for safety in always writing n characters even if the string is much shorter.

[ouah]

@StephenCanon but you can use them safely.

[wildplasser]

Strncpy and stncat are never a solution. They are even worse than the problem. Combined, they are even worse. (strncpy can result in an unterminated string if there is insufficient space, strncat can write at dest[len] )

[ouah]

@wildplasser yes, don't forget to - 1 for strncpy and strncat and null terminate the string yourself for strncpy. But these two functions, even if we admit they are badly designed, do what they are expected to do from the specifications.

[Mark]

The project already uses strncpy and strncat in some places. I've edited the question, but I meant for those functions to be implied by the 'etc'. Those functions can be safely used, but it can be difficult. The code I'm working with can be pretty hard to follow, so it's not always obvious how big a string can possibly be. I want functions that will fail noisily when there are problems, and it is my understanding that the *_s functions will do just that.

[wildplasser]

Having to remember to add/substract 1 is a recipe for disaster. Best is still IMHO to only use the memxxx() functions and keep a manual count, or use snprintf() (which is stable since c99)

[Stephen Canon]

This is an excellent suggestion. Calling strlen once and then using explicit-length memory operations is a very nice way to deal safely with strings.

[Mark]

Good find! I spent quite a bit of time trying to coax an answer out of The Google, but didn't have any luck.

[Massimo Fazzolari]

performance can be the problem programminginadarkroom.blogspot.it/2012/02/…

[P.P]

@MassimoFazzolari That's a poor way of benchmarking. In each of those memcpy calls there's a call to strlen(). With optimizations enabled, both memcpy and strcpy gave me the same time for that code (as compiler likely to loops as they repeatedly overwrite the same string). Without any optimization and replacing strlen(in) with 12 showed memcpy is twice as fast as strcpy.