2 ms·

Can you give examples of how incorrectly using strlcpy leads to vulnerabilities as severe and as common as buffer overflow? Thanks.

saurik 13y ago
This question is difficult to answer, because in its curtness it fails to ask the real question, which is "does claiming this function solves the security problems of strcpy lead to more of fewer exploitable vulnerabilities". People really need to be paying much more attention to their strings, and preferably using real string libraries rather than these low-level memory primitives as if they were a high-level string library. People also need to be paying close attention to these APIs in all cases where they use them: you don't get a "free pass" to write a bunch of string manipulation because you are using these l-function variants. We then also have to take into consideration that actual stack overflows are nowadays rare with strcpy due to compilers being able to automatically swap in __strcpy_chk whenever sizeof the stack buffer is known at compile-time. Humorously, swapping strcpy out for strlcpy in these cases will take a situation where the program aborts when the buffer overflows (which isn't perfect, of course, as you might be able to use that to DoS part of a system that you need to temporarily go away while you attack something else) and replaces it with strings that randomly truncate their values at different points in your program's logic. Heap-allocated buffers are still problems, but are also much more difficult to deterministically exploit. However, randomly truncated filenames, usernames, or keynames offer tons of opportunities to mess with program logic: get a system to verify properties of one path (which can be made arbitrarily long using a cyclic symlink) and then access another one, for example (which is incredibly common due to everyone's misconception that you can use a buffer of size MAXPATHLEN to store a complete path...).
- Skinney 13y ago
  I've read over several of your answers, and what your arguments boil down to (as far as I can tell) is that people use these functions wrong. While true, incorrect use can lead to an incorrect program, and that people's opinions of these functions thus need to change, does this mean that we shouldn't use this functions? If the goal is to reduce the possibilities of buffer overflows, wouldn't it be better to use these functions? Isn't it actually easier to find bugs involving strings, than bugs involving overflows? These functions do solve a real issue. Of course, people not using the functions correctly should be made aware of that fact, but still, avoiding buffer overflows > bugs due to short strings.
- InclinedPlane 13y ago
  I definitely agree, and the point about __strcpy_chk is an excellent one. However I still get the feeling that switching from strcpy to strlcpy is a pretty substantial and easy win even while the battle to get people to use bstrings or what-have-you continues apace. Perfect should not be the enemy of good, or at least better. Let's get the unwashed masses washed first before we get them pedicured and into tuxedos.

saurik 13y ago

This question is difficult to answer, because in its curtness it fails to ask the real question, which is "does claiming this function solves the security problems of strcpy lead to more of fewer exploitable vulnerabilities". People really need to be paying much more attention to their strings, and preferably using real string libraries rather than these low-level memory primitives as if they were a high-level string library. People also need to be paying close attention to these APIs in all cases where they use them: you don't get a "free pass" to write a bunch of string manipulation because you are using these l-function variants. We then also have to take into consideration that actual stack overflows are nowadays rare with strcpy due to compilers being able to automatically swap in __strcpy_chk whenever sizeof the stack buffer is known at compile-time. Humorously, swapping strcpy out for strlcpy in these cases will take a situation where the program aborts when the buffer overflows (which isn't perfect, of course, as you might be able to use that to DoS part of a system that you need to temporarily go away while you attack something else) and replaces it with strings that randomly truncate their values at different points in your program's logic. Heap-allocated buffers are still problems, but are also much more difficult to deterministically exploit. However, randomly truncated filenames, usernames, or keynames offer tons of opportunities to mess with program logic: get a system to verify properties of one path (which can be made arbitrarily long using a cyclic symlink) and then access another one, for example (which is incredibly common due to everyone's misconception that you can use a buffer of size MAXPATHLEN to store a complete path...).

Skinney 13y ago
I've read over several of your answers, and what your arguments boil down to (as far as I can tell) is that people use these functions wrong. While true, incorrect use can lead to an incorrect program, and that people's opinions of these functions thus need to change, does this mean that we shouldn't use this functions? If the goal is to reduce the possibilities of buffer overflows, wouldn't it be better to use these functions? Isn't it actually easier to find bugs involving strings, than bugs involving overflows? These functions do solve a real issue. Of course, people not using the functions correctly should be made aware of that fact, but still, avoiding buffer overflows > bugs due to short strings.
InclinedPlane 13y ago
I definitely agree, and the point about __strcpy_chk is an excellent one. However I still get the feeling that switching from strcpy to strlcpy is a pretty substantial and easy win even while the battle to get people to use bstrings or what-have-you continues apace. Perfect should not be the enemy of good, or at least better. Let's get the unwashed masses washed first before we get them pedicured and into tuxedos.