4 ms·

Almost every one has a n version you should use, and their man pages will tell you that. strcpy -> strncpy (or strlcpy on BSD) strcat -> strncat (or strlcat o

• tptacek 13y ago
  They told me if I used the n version I'd be safe. They told me the risks were tiny. That all we had to do was practice safe counting. They told me that... ˚sob˚ but they were wrong.
  • fromdoon 13y ago
    Hi, Is there any resource on Web or even any book that documents all the risks. I had once seen a talk given by you .. was good !! Any other such resources out there ??
    • tptacek 13y ago
      I like _The Art of Software Security Assessment_ for this.
  • _telemachus 13y ago
    Good for laughs. Thanks. Now the serious follow up: Ok, what else should someone do? Programs (often) handle text. Apparently, that pretty much means you're fucked. So what is a reasonable way to write such programs?
    • dllthomas 13y ago
      If you're able, don't treat text as zero-terminated char arrays. Ideally, you'd have a well fleshed-out library for encoding-aware ropes.
      • Arnor 13y ago
        Which libraries do you recommend?
        • dllthomas 13y ago
          Unfortunately, I don't know of one. My recent C work has worked with text only in a very limited capacity (parsing and building packets in an ascii format - for the later, vectorized write buffers are a poor-man's ropes). Edited to add: Apparently there is this: http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh.txt http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_source/cordh...
        • oofabz 13y ago
          I recommend bstring for length-prefixed strings in C: http://bstring.sourceforge.net/ http://bstring.sourceforge.net/
          • clarry 13y ago
            Bstring relies on undefined behavior for security. Don't use it if you care about security.
    • cube13 13y ago
      Make damned sure you know what you're doing. That means making sure you have enough memory allocated to avoid overflows, and that any input is sanitized before putting it down. Meaning, if you're using a function that's expecting a null terminated string, make SURE it's null terminated before copying. Or that you know the exact length to pass into a length specified function. The problem isn't necessarily the functions themselves, it's coders who make assumptions that don't pan out to be true.
    • thinkpad20 13y ago
      Do all of your string work with these guys: struct string { char *str; unsigned length; }
      • _telemachus 13y ago
        Let's assume your string struct is solid. Then does that mean you can safely use it with `printf, fprintf, sprintf` (e.g. printf("%s", string->value)? Or must you also write custom versions of those functions? How deep does this rabbit hole go?
        • thinkpad20 13y ago
          You don't have to write custom versions of any of those functions; just use the char pointer in the struct instead of a bare char pointer. Keeping track of the length of your strings gives an easy way to provide the 'n' in all of those 'n' functions, and has other advantages besides. But the use of such a struct in and of itself, of course, provides no guarantees of safety. There is no such thing in C anyway :)
        • dllthomas 13y ago
          You'd probably want "%.*s" or possibly even "%*.*s" if you want it space padded. In principle you can bound your space usage and avoid an snprintf with such constructs; in practice, it's probably better to still use snprintf (if you're using standard-library string functions at all).
• deleted 13y ago
  [deleted]
• cmollis 13y ago
  exactly.
• ledbettj 13y ago
  Keeping in mind that strncpy has it's own problems, like not null terminating the buffer if it would overflow.
  • Nursie 13y ago
    I guess the whole point is don't rely on null terminated strings in your code.
  • lawl 13y ago
    This is why you should use strlcpy()!
  • santosha 13y ago
    The point of the n is that you specify the maximum length that it's allowed to copy. It's slightly harder to mess that up than with regular strcpy.
    • tobiasu 13y ago
      The n in strncpy describes to what size the destination buffer (not string) should be padded with '\0'. This is useful for copying a string into a fixed size buffer that is sent over the network, to give an example. It's not what the programmer generally means when using strncpy. Many programmers are surprised when they learn that strncpy() really writes 1M-strlen("abc") zeros in the 1M char array every time it's called...
      • dllthomas 13y ago
        "The n in strncpy describes to what size the destination buffer (not string) should be padded with '\0'." This is false. From the man page: "The strncpy() function is similar, except that at most n bytes of src are copied. Warning: If there is no null byte among the first n bytes of src, the string placed in dest will not be null-terminated." And the following code prints foo:ar on my system. char buffer[10]; strcpy(buffer, "foobar"); strcpy(buffer, "foo"); printf("%s:%s\n", buffer, buffer+4); Edited to add: huh, scratch that. Obvious error in above test :-P. Testing it with strncat like I had meant to, it seems it is in fact padded, not just (possibly) terminated. Interesting, and very worth knowing if you are trying to move a probably small string to a large buffer under time pressure.
• vezzy-fnord 13y ago
  The alternative to gets() is fgets(). In fact, I'm pretty sure the gets() function is completely deprecated in the C11 standard. However, despite the n functions being generally safer, you're still propagating misinformation by touting them as secure alternatives. The original use of the n functions was to manipulate strings in matters of fixed size arrays. If you don't know what you're doing and just blindly use strncpy() as a strcpy() replacement, you could end up truncating your strings. OpenBSD's l functions, on the other hand, were specifically designed with security in mind.