Messages in this thread | | | From | James Dutton <> | Date | Thu, 19 Oct 2023 00:22:33 +0100 | Subject | Is strncpy really less secure than strscpy ? |
| |
Is strncpy really less secure than strscpy ?
If one uses strncpy and thus put a limit on the buffer size during the copy, it is safe. There are no writes outside of the buffer. If one uses strscpy and thus put a limit on the buffer size during the copy, it is safe. There are no writes outside of the buffer. But, one can fit more characters in strncpy than strscpy because strscpy enforces the final \0 on the end. One could argue that strncpy is better because it might save the space of one char at the end of a string array. There are cases where strncpy might be unsafe. For example copying between arrays of different sizes, and that is a case where strscpy might be safer, but strncpy can be made safe if one ensures that the size used in strncpy is the smallest of the two different array sizes.
If one blindly replaces strncpy with strscpy across all uses, one could unintentionally be truncating the results and introduce new bugs.
The real insecurity surely comes when one tries to use the string. For example:
#include <stdio.h> #include <string.h>
int main() { char a[10] = "HelloThere"; char b[10]; char c[10] = "Overflow"; strncpy(b, a, 10); /* This overflows and so in unsafe */ printf("a is %s\n", a); /* This overflows and so in unsafe */ printf("b is %s\n", b); /* This is safe */ printf("b is %.*s\n", 10, a); /* This is safe */ printf("b is %.*s\n", 4, a); return 0; }
So, why isn't the printk format specifier "%.*s" used more instead of "%s" in the kernel?
Kind Regards
James
| |