locked
Size parameter of secure C library functions RRS feed

  • Question

  • The secure C library functions usually have a parameter to specify the size of a buffer you are writing to. For example,

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

    the parameter numberOfElements specifies the size of strDestination, the buffer being written to. But what if the first parameter specifies an offset within the buffer? For example,

    char chBuffer[48];

    strcpy_s(chBuffer, 48, "This is the string");

    and then

    strcpy_s(chBuffer+18, 48, " written to the buffer.");

    In the second call to strcpy_s, should the argument to the second parameter specify the declared size of chBuffer, or should it specify how much space remains in chBuffer when the argument to the first parameter specifies an offset within chBuffer? In the second call to strcpy_s, the remaining space in chBuffer is 30 characters. Should the argument to the second parameter be 30, instead of 48?

    Wednesday, March 27, 2013 10:23 PM

Answers

  • In fact, if you test your code example you will find
    that using 48 as the size on the second strcpy_s will
    result in a stack corruption error when a Debug build
    is run. This occurs because in a Debug build the security
    enhanced functions such as strcpy_s fill the buffer with
    a special character (0xFD or 0xFE) before any copying
    takes place. This is done to help catch cases where
    the wrong buffer size has been supplied.

    So if you use:

    char chBuffer[48];
    strcpy_s(chBuffer+18, 48, " written to the buffer.");

    then 48 bytes starting at chBuffer+18 will be overwritten
    with this special character, corrupting the stack after
    chBuffer before any copying even occurs.

    - Wayne
    • Marked as answer by Elegentin Xie Thursday, April 4, 2013 8:02 AM
    Thursday, March 28, 2013 1:15 AM

All replies

  • You need to pass 30.   It doesn't know about what part of the allocation exist prior to the first arg.

    Wednesday, March 27, 2013 10:28 PM
  • Yes, I would expect strcat_s to keep track of how much space is left in the destination buffer. My question was about the secure C functions in general, where the size of a destination buffer is specified. For now I am going to assume that Ron Natalie's answer is correct, and that strcpy_s takes whatever value I pass to the first parameter as the address of a buffer whose size is specified in the second parameter, ignoring the address in the declaration of the buffer.
    Thursday, March 28, 2013 12:02 AM
  • In fact, if you test your code example you will find
    that using 48 as the size on the second strcpy_s will
    result in a stack corruption error when a Debug build
    is run. This occurs because in a Debug build the security
    enhanced functions such as strcpy_s fill the buffer with
    a special character (0xFD or 0xFE) before any copying
    takes place. This is done to help catch cases where
    the wrong buffer size has been supplied.

    So if you use:

    char chBuffer[48];
    strcpy_s(chBuffer+18, 48, " written to the buffer.");

    then 48 bytes starting at chBuffer+18 will be overwritten
    with this special character, corrupting the stack after
    chBuffer before any copying even occurs.

    - Wayne
    • Marked as answer by Elegentin Xie Thursday, April 4, 2013 8:02 AM
    Thursday, March 28, 2013 1:15 AM