1. 6
  1.  

  2. 1

    Good old friend strcpy :)

    In 2017, no less…

    1. 2

      The problem is that manuals do not tell you what to do, they just list warnings and do not supply any hints on how you should navigate those obstacles safely.

      1. 3

        One could always try reading the referenced pages in the see also section.

        1. 1

          “they just list warnings and do not supply any hints on how you should navigate those obstacles safely.”

          It’s an arguable criticism where maybe they should link to that. I mostly agree if they describe the problem they should automatically point to a solution in a direct, obvious way. If space permits, describe it with an example immediately as in secure, coding guides. Alternatively, recommend a secure coding guide. :) Let’s test the counterpoint, though, that it should be easy enough to find for a worried developer willing to look into the matter.

          “No bounds checking is performed. If the buffer dst is not large enough to hold the result, subsequent memory will be damaged. “

          Direct implication: check the size of the input first if worried about preventing errors. That’s at least the obvious part. The worried programmer might also type strcpy into Google with words such as security, vulnerability, crash, or so on to understand what the problem might be. I just tested that in DuckDuckGo to find a search for “strcpy vulnerability” gives these links as the first, two results:

          https://stackoverflow.com/questions/21121272/how-to-mitigate-the-strcat-and-strcmp-vulnerability

          https://stackoverflow.com/questions/1258550/why-should-you-use-strncpy-instead-of-strcpy

          That should give them plenty of information. So, maybe we just need to teach programmers to always type the thing they’re curious about followed by specific words into Google or DuckDuckGo that are likely to bring up relevant information. Words I’ve used to good effect include bugs, vulnerabilities, prevent, and mitigate/mitigation. People might have gotten too lazy to do this and/or forgotten how to search properly since Google is so good now. It’s not as good as people think, though, where my old techniques from old engines still pay off.

          1. 2

            The other point is the OpenBSD manual is not intended to be a learn to program in C tutorial. It describes the functions available, (hopefully) simply and accurately, noting caveats as necessary. I think our philosophy is closer to do no harm than solve all problems.

            Really, I have a hard time imagining a novice programmer reading that page, but knowing nothing of the territory. If you don’t know what strcpy is, how did you find the man page in the first place? If you were pointed at strcpy by some other tutorial, shouldn’t that be the document corrected?

            1. 1

              You make a great point. Given that and what can Google finds, the reasonable assumption for the new programmer is probably that they learn the language, read some resources on secure coding, and then the docs are just giving a reminder of the risk. It’s not far from a formal spec, either, where it’s warning a precondition on size is necessary for correctness. We similarly wouldn’t expect a language tutorial in a formal spec.