5 ms·

Wrong, I make a clear example of the copy() function being broken, give a demonstration of fuzzing it to break it, and show how to do it yourself. And, if you

by zedshaw 15y ago

Wrong, I make a clear example of the copy() function being broken, give a demonstration of fuzzing it to break it, and show how to do it yourself. And, if you think the copy() function is valid, then you also think strcpy() function is valid, and therefore you don't know what you're talking about. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows.

angersock 15y ago
Dude, stop saying it's broken. For higher level languages where we have intelligent string objects, yeah, bounds checking is assumed--but this is something originating in assembly-level stuff. If you call it with broken memory, of course it won't work correctly. You're doing a good job spreading knowledge--don't spread misinformation. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows. If strcpy() was truly buggy and unpredictable in its implementation, it wouldn't be nearly so useful as an attack vector. Be accurate--strcpy() is unsafe, not buggy. Sheesh.
- thebigshane 15y ago
  I think he meant the use of strcpy() is buggy.
- zedshaw 15y ago
  No, it's defective and buggy. You can't prove logically that the while loop inside will end given any random input. An implementation with a length will end given any input. That is a bug. If you wrote code like that then I'd flag it as a bug, so how is it that strcpy is somehow reclassified as "unsafe" but yeah totally not a bug? It's so poorly designed that it should be considered wrong, buggy, defective, unsafe, and removed. To go around saying "it's totally alright" when even Microsoft, bringer of more virii than a whore house, has deprecated it: http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%2... Is idiotic thinking. Go ahead and come up with all the distinctive classifications you want, it's a defect to use strcpy because it's buggy, and copy() in that code is the same.
  - unwind 15y ago
    So, how does one of the "safe" string-copying functions work safely given "any random input"?
    - jballanc 15y ago
      By requiring that the length of the string be given as one of the arguments, just like strlcpy does.
      - zvrba 15y ago
        And how are you going to make sure that the length specified is correct?
        jballanc 15y ago
        This is a borderline straw-man argument. Size (length) is one of the few things that you must be very aware of and control when programming C. You cannot "malloc" without knowing the length to malloc. You cannot create an array on the stack without knowing its size. In each case, you may not use the full memory allocated, but at least you can set an upper bound on the memory that you own. Thus, however you created or ingested the string to copy (and the memory to copy it to), you will have an upper bound on how much memory it is safe to copy.
        zvrba 15y ago
        This is about maintaining invariants, and I interpret the "any random input" from the parent question as "input that breaks the preconditions the function expects of its inputs." With str* functions the assumptions are that the string is null-terminated and stored within a memory block of large enough size. When providing string+length, "any random input" means that, e.g., length may be arbitrary; maybe it became garbage as a consequence of series of unfortunate integer overflows (when did you last check for those when checking that len1+len2 < buffer_size ?). So, how DO you write a string-handling function that can safely handle ANY random input?
- LnxPrgr3 15y ago
  Zed's Twitter killfile must be a mile long if this got me into it: https://gist.github.com/9efed904a1ea0902c7c7/213de692d29fddea1ecf43e1a1bbe50665562097 https://gist.github.com/9efed904a1ea0902c7c7/213de692d29fdde... He's right though. This really is a silly argument. Your life will almost certainly be better if you forget strcpy exists. Really, C strings are broken in general. Computing their length is O(n) when it could be O(1), and a missing null terminator results in undefined behavior (a crash if you're lucky). Worse, copying an oversized string into an undersized buffer results in a buffer overflow, which gets you a nice mention here: http://www.kb.cert.org/vuls http://www.kb.cert.org/vuls. strcpy is about as safe as a hand grenade: you'll be fine if you know what you're doing, but God help you if you don't! Realistically, if you're reading "Learn C The Hard Way," you don't know what you're doing yet. Don't use strcpy. For that matter, you're human. You screw up sometimes. We all do. Don't use strcpy without a damn good reason. Is there ever a legitimate reason to use strcpy over strncpy?
ori_b 15y ago
There's a difference between 'difficult to use correctly' and 'broken'. It would be a good idea for you to learn it.
simias 15y ago
First, there's no need to be aggressive. I don't really get what you're trying to say. I would understand if you said that strncat is broken (since it can output non \0 terminated strings, unlike the non-standard strlcat, breaking the principle of least astonishment) but I fail to see the problem here. It's just garbage-in/garbage-out: strcpy expects a C string, and the char array you give it is not a C string, so it fails by triggering an undefined behaviour. The function has no way to detect this problem, so it's not even laziness. Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem.
- wazoox 15y ago
  > First, there's no need to be aggressive. He isn't aggressive, he simply is the inimitable Zed Shaw :) > The function has no way to detect this problem, so it's not even laziness. His point : therefore you should not use this function, but strlcpy instead. Or course the K&R has the excellent excuse of predating about every alternative secure version of strcpy. > Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem. I don't think that you could easily forge such a string using Pascal standard functions, but last time I wrote Pascal there was neither syntax highlighting in the editor nor hard drive in my PC. Anyway, strlcpy should be immune, because it will truncate whatever string of bytes to the required length, see: http://www.manpagez.com/man/3/strlcpy/ http://www.manpagez.com/man/3/strlcpy/ It doesn't preclude any implementation error (preperly a bug), of course.

by zedshaw 15y ago

angersock 15y ago

Dude, stop saying it's broken. For higher level languages where we have intelligent string objects, yeah, bounds checking is assumed--but this is something originating in assembly-level stuff. If you call it with broken memory, of course it won't work correctly. You're doing a good job spreading knowledge--don't spread misinformation. Everyone who is aware of secure C coding knows strcpy() is buggy and the cause of most buffer overflows. If strcpy() was truly buggy and unpredictable in its implementation, it wouldn't be nearly so useful as an attack vector. Be accurate--strcpy() is unsafe, not buggy. Sheesh.

thebigshane 15y ago
I think he meant the use of strcpy() is buggy.
zedshaw 15y ago
No, it's defective and buggy. You can't prove logically that the while loop inside will end given any random input. An implementation with a length will end given any input. That is a bug. If you wrote code like that then I'd flag it as a bug, so how is it that strcpy is somehow reclassified as "unsafe" but yeah totally not a bug? It's so poorly designed that it should be considered wrong, buggy, defective, unsafe, and removed. To go around saying "it's totally alright" when even Microsoft, bringer of more virii than a whore house, has deprecated it: http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%29.aspx http://msdn.microsoft.com/en-us/library/kk6xf663%28v=vs.80%2... Is idiotic thinking. Go ahead and come up with all the distinctive classifications you want, it's a defect to use strcpy because it's buggy, and copy() in that code is the same.
- unwind 15y ago
  So, how does one of the "safe" string-copying functions work safely given "any random input"?
  - jballanc 15y ago
    By requiring that the length of the string be given as one of the arguments, just like strlcpy does.
    - zvrba 15y ago
      And how are you going to make sure that the length specified is correct?
      - jballanc 15y ago
        This is a borderline straw-man argument. Size (length) is one of the few things that you must be very aware of and control when programming C. You cannot "malloc" without knowing the length to malloc. You cannot create an array on the stack without knowing its size. In each case, you may not use the full memory allocated, but at least you can set an upper bound on the memory that you own. Thus, however you created or ingested the string to copy (and the memory to copy it to), you will have an upper bound on how much memory it is safe to copy.
        zvrba 15y ago
        This is about maintaining invariants, and I interpret the "any random input" from the parent question as "input that breaks the preconditions the function expects of its inputs." With str* functions the assumptions are that the string is null-terminated and stored within a memory block of large enough size. When providing string+length, "any random input" means that, e.g., length may be arbitrary; maybe it became garbage as a consequence of series of unfortunate integer overflows (when did you last check for those when checking that len1+len2 < buffer_size ?). So, how DO you write a string-handling function that can safely handle ANY random input?
LnxPrgr3 15y ago
Zed's Twitter killfile must be a mile long if this got me into it: https://gist.github.com/9efed904a1ea0902c7c7/213de692d29fddea1ecf43e1a1bbe50665562097 https://gist.github.com/9efed904a1ea0902c7c7/213de692d29fdde... He's right though. This really is a silly argument. Your life will almost certainly be better if you forget strcpy exists. Really, C strings are broken in general. Computing their length is O(n) when it could be O(1), and a missing null terminator results in undefined behavior (a crash if you're lucky). Worse, copying an oversized string into an undersized buffer results in a buffer overflow, which gets you a nice mention here: http://www.kb.cert.org/vuls http://www.kb.cert.org/vuls. strcpy is about as safe as a hand grenade: you'll be fine if you know what you're doing, but God help you if you don't! Realistically, if you're reading "Learn C The Hard Way," you don't know what you're doing yet. Don't use strcpy. For that matter, you're human. You screw up sometimes. We all do. Don't use strcpy without a damn good reason. Is there ever a legitimate reason to use strcpy over strncpy?

ori_b 15y ago

There's a difference between 'difficult to use correctly' and 'broken'. It would be a good idea for you to learn it.

simias 15y ago

First, there's no need to be aggressive. I don't really get what you're trying to say. I would understand if you said that strncat is broken (since it can output non \0 terminated strings, unlike the non-standard strlcat, breaking the principle of least astonishment) but I fail to see the problem here. It's just garbage-in/garbage-out: strcpy expects a C string, and the char array you give it is not a C string, so it fails by triggering an undefined behaviour. The function has no way to detect this problem, so it's not even laziness. Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem.

wazoox 15y ago
> First, there's no need to be aggressive. He isn't aggressive, he simply is the inimitable Zed Shaw :) > The function has no way to detect this problem, so it's not even laziness. His point : therefore you should not use this function, but strlcpy instead. Or course the K&R has the excellent excuse of predating about every alternative secure version of strcpy. > Pascal strings embed the count within the string, but then you could forge a bogus pascal string with an incorrect size and trigger the same kind of problem. I don't think that you could easily forge such a string using Pascal standard functions, but last time I wrote Pascal there was neither syntax highlighting in the editor nor hard drive in my PC. Anyway, strlcpy should be immune, because it will truncate whatever string of bytes to the required length, see: http://www.manpagez.com/man/3/strlcpy/ http://www.manpagez.com/man/3/strlcpy/ It doesn't preclude any implementation error (preperly a bug), of course.