3 ms·

Let's see: Scenario 1: a bug in your program leads to incorrect program behavior because strlcpy just did what it was told and the client code didn't detect th

Let's see: Scenario 1: a bug in your program leads to incorrect program behavior because strlcpy just did what it was told and the client code didn't detect the error. Scenario 2: a bug in your program leads to a buffer overflow vulnerability which can potentially lead to remote code execution. I think I know which set of problems I'd rather have.

saurik 13y ago
You are making the assumption that scenario one does not lead to an exploitable vulnerability... the whole point of this complaint is that randomly truncating strings because they don't fit in buffers because you believe "strlcpy is magically better than strcpy" actually causes a different class of potentially-exploitable vulnerability... it doesn't, as the person I responded to claimed, "fail safe".
- __david__ 13y ago
  Yes, it might lead to an exploitable bug, but it seems to me that it's a much lower probability than a buffer overflow leads to an exploitable bug. Surely an API that lowers the percentage of exploitable bugs isn't all bad (even if it's not perfect)? Until about 2 years ago there wasn't really a better solution around...
  - InclinedPlane 13y ago
    It's usually pretty difficult to create an exploitable remote code execution bug in code without very obviously heinous (read: amateur level) code. Whereas with buffer overflows it's fairly trivial. Moreover, in order to exploit a more complex vulnerability an attacker would need to know something about the nature of the vulnerability, making it more difficult to come up with exactly the right steps to exploit it to maximum advantage. In contrast, with a typical buffer overflow you only need to tune how much junk to throw at the buffer before you start getting code to execute, and then you can just inject whatever existing payload you have already. This is so trivial that there are now tools designed to automate the process.
- MaulingMonkey 13y ago
  > You are making the assumption that scenario one does not lead to an exploitable vulnerability Personally, I'm making the assumption that scenario two will lead to a probably exploitable buffer overflow whereas the scenario one might lead to another class of exploitable vulnerability. By significantly reducing how much time I have to spend focusing specifically on the buffer overflows of scenario two, I have more time to spend on the other logical errors that may lead to vulnerabilities in scenario one. It's not fail safe -- nothing is in the most extreme interpretations of the phrase -- but it is fail safe against one specific failure case, which is valuable.
  - saurik 13y ago
    If you are going to switch to some different API in the hope of no longer having an exploitable vulnerability, how about just using a real string library, rather than trading in one class of bug for another one that you are hoping is less dangerous? Preferably, one where you can also store embedded NULL characters in the string, and thereby aren't also subject to strcmp failing to protect you from yet another class of exploit (due to C programs often truncating strings after null characters, which is a pretty common attack surface) due to using null-terminated strings in the first place? FWIW, if people want to say "this API still sucks and users still have to be really careful when using it, but it slightly decreases a specific class of error" that's one thing, but that doesn't mean it "fails safe", nor is the panacea that people make it out to be: it is seriously dangerous for people to keep proselytizing that strlcpy is so fundamentally more safe that it can be used with reckless abandon (which, as I point out in the other comments I've made in this thread, is precisely what has happened due to the dogma that "strlcpy is secure and strcpy is not").
    - MaulingMonkey 13y ago
      > If you are going to switch to some different API in the hope of no longer having an exploitable vulnerability, how about just using a real string library, rather than trading in one class of bug for another one that you are hoping is less dangerous? Sure. Hell, I apply this to entire languages and prefer C# where you generally have to opt into rather than opt out of corrupting buffer overflows, and where finding the length of a native string literal is an O(1) operation rather than an O(N) operation. But 3rd party APIs mean you will at some point have to deal with fixed length character buffers both for reading and for writing. Even in C#, if you ever find yourself needing to do native interop, you'll almost certainly eventually run into them. > nor is the panacea that people make it out to be: it is seriously dangerous for people to keep proselytizing that strlcpy is so fundamentally more safe that it can be used with reckless abandon I think the linked article shows we have a much bigger problem: people simply do not care about security and use strcpy with reckless abandon. I won't say "don't add strlcpy to your banned.h". I won't say, "don't annotate the documentation to point programmers to better alternatives". I won't say, "make use of the function generate warnings or errors in the default settings of your project, standard library, or compiler configuration". But I'm unconvinced that strlcpy is ineffective at harm reduction, and thus that Christoph Hellwig's stance is the correct one.
- InclinedPlane 13y ago
  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.

saurik 13y ago

You are making the assumption that scenario one does not lead to an exploitable vulnerability... the whole point of this complaint is that randomly truncating strings because they don't fit in buffers because you believe "strlcpy is magically better than strcpy" actually causes a different class of potentially-exploitable vulnerability... it doesn't, as the person I responded to claimed, "fail safe".

__david__ 13y ago
Yes, it might lead to an exploitable bug, but it seems to me that it's a much lower probability than a buffer overflow leads to an exploitable bug. Surely an API that lowers the percentage of exploitable bugs isn't all bad (even if it's not perfect)? Until about 2 years ago there wasn't really a better solution around...
- InclinedPlane 13y ago
  It's usually pretty difficult to create an exploitable remote code execution bug in code without very obviously heinous (read: amateur level) code. Whereas with buffer overflows it's fairly trivial. Moreover, in order to exploit a more complex vulnerability an attacker would need to know something about the nature of the vulnerability, making it more difficult to come up with exactly the right steps to exploit it to maximum advantage. In contrast, with a typical buffer overflow you only need to tune how much junk to throw at the buffer before you start getting code to execute, and then you can just inject whatever existing payload you have already. This is so trivial that there are now tools designed to automate the process.
MaulingMonkey 13y ago
> You are making the assumption that scenario one does not lead to an exploitable vulnerability Personally, I'm making the assumption that scenario two will lead to a probably exploitable buffer overflow whereas the scenario one might lead to another class of exploitable vulnerability. By significantly reducing how much time I have to spend focusing specifically on the buffer overflows of scenario two, I have more time to spend on the other logical errors that may lead to vulnerabilities in scenario one. It's not fail safe -- nothing is in the most extreme interpretations of the phrase -- but it is fail safe against one specific failure case, which is valuable.
- saurik 13y ago
  If you are going to switch to some different API in the hope of no longer having an exploitable vulnerability, how about just using a real string library, rather than trading in one class of bug for another one that you are hoping is less dangerous? Preferably, one where you can also store embedded NULL characters in the string, and thereby aren't also subject to strcmp failing to protect you from yet another class of exploit (due to C programs often truncating strings after null characters, which is a pretty common attack surface) due to using null-terminated strings in the first place? FWIW, if people want to say "this API still sucks and users still have to be really careful when using it, but it slightly decreases a specific class of error" that's one thing, but that doesn't mean it "fails safe", nor is the panacea that people make it out to be: it is seriously dangerous for people to keep proselytizing that strlcpy is so fundamentally more safe that it can be used with reckless abandon (which, as I point out in the other comments I've made in this thread, is precisely what has happened due to the dogma that "strlcpy is secure and strcpy is not").
  - MaulingMonkey 13y ago
    > If you are going to switch to some different API in the hope of no longer having an exploitable vulnerability, how about just using a real string library, rather than trading in one class of bug for another one that you are hoping is less dangerous? Sure. Hell, I apply this to entire languages and prefer C# where you generally have to opt into rather than opt out of corrupting buffer overflows, and where finding the length of a native string literal is an O(1) operation rather than an O(N) operation. But 3rd party APIs mean you will at some point have to deal with fixed length character buffers both for reading and for writing. Even in C#, if you ever find yourself needing to do native interop, you'll almost certainly eventually run into them. > nor is the panacea that people make it out to be: it is seriously dangerous for people to keep proselytizing that strlcpy is so fundamentally more safe that it can be used with reckless abandon I think the linked article shows we have a much bigger problem: people simply do not care about security and use strcpy with reckless abandon. I won't say "don't add strlcpy to your banned.h". I won't say, "don't annotate the documentation to point programmers to better alternatives". I won't say, "make use of the function generate warnings or errors in the default settings of your project, standard library, or compiler configuration". But I'm unconvinced that strlcpy is ineffective at harm reduction, and thus that Christoph Hellwig's stance is the correct one.
InclinedPlane 13y ago
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.