embedded software boot camp

C’s strcpy_s(): C11’s More Secure Version of strcpy()

Thursday, August 31st, 2017 by Michael Barr

Buffer overflows are a well-known port of entry for hackers and attackers of computerized systems. One of the easiest ways to create a buffer overflow weakness in a C program has long been to rely on the strcpy() function of the C standard library to overwrite data.

There’s a decent explanation of the problem at http://www.thegeekstuff.com/2013/06/buffer-overflow/. But the nutshell version is that you have a buffer of size X somewhere in memory that your code uses strcpy() to overwrite new nul-terminated strings. If an attacker can somehow feed a string longer than X bytes to your function then data beyond the bounds of the original array will be overwritten too: thereby rewriting code or data that serves some other purpose.

You should know that the new C11 update to the C programming language provides for a replacement “safe” version of this function, which is named strcpy_s(). The parameter lists and return types differ:

char *strcpy(char *strDestination, const char *strSource);

versus:

errno_t strcpy_s(char *strDestination, size_t numberOfElements, const char *strSource);

The new “numberOfElements” parameter is used by strcpy_s() to check that the strSource is not bigger than the buffer. And, when there is a problem, an error code is returned.

The Microsoft Developer Network website is one source of additional detail on this and other of C11’s “safe” functions.

5 Responses to “C’s strcpy_s(): C11’s More Secure Version of strcpy()”

  1. Daniel Lundin says:

    The C11 Annex K “bounds-checking interface” that includes this function is however optional to implement. As far as I know, no mainstream C standard lib has implemented it yet.

    In particular, MS Visual Studio has not done this. Their C compiler is still to this day struggling with compliance to the 18 year old C99 standard. However, Visual Studio has supported many functions with similar names as those in Annex K, as non-standard extensions. The MS versions are not necessarily compatible with the C11 versions. Overall, be very sceptic about anything MS says when it comes to C standard compliance, because they are notorious for ignoring the C standard themselves.

    The “strcpy() is insecure” debate has raged forever on C forums. The consensus among C veterans seems to be that strcpy() is just fine – simply check the size of the data before you call the function. It is a well-documented and safe function, unlike for example strncpy().

  2. Chris McErlean says:

    Pardon my ignorance, but how does “strcpy_s” differ from the existing library function “strncpy”?

  3. Steve says:

    Doesn’t strncpy() accomplish the same thing?

  4. Ron says:

    While a secure version of strcpy is great – don’t we already have one with strncpy in the GNU world? Why can we not use the same one? What are the subtle differences?

  5. Jeff Skaanland says:

    Since several people have asked:

    strncpy:
    1. Doesn’t guarantee nul termination; it’s just that you won’t overflow your input buffer.
    2. Does guarantee that every byte of the destination str will be written either with data preceding srcs nul termination, or nul characters. Perhaps not ideal for embedded if buffers and source lengths have large size differences.

    stlcpy:
    1. Guarantees nul termination.
    2. Won’t overflow the destination buffer.
    2. But doesn’t protect against segment faults if the source isn’t nul terminated. (It returns the length of the source string.)

Leave a Reply