3 ms·

> 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 le

> 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.

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.