5 ms·

What'd be a use case of strncat(s1, s2, SIZE_MAX)? It seems like this would be hard to find in the wild

• mjevans 11y ago
  Imagine you have a user configurable buffer size. Then imagine that the user wants to throw as much ram as it takes at the problem and sets the maximum size to that value. It happens more often than you'd think.
  • Someone 11y ago
    Are or were there systems where one can/could allocate a buffer of SIZE_MAX bytes? I have a hard time thinking of one, except for, possibly, segmented memory architectures where one wants to keep structures in one segment.
• stephencanon 11y ago
  Commonly, a policy declared that all use of `strcat` must be replaced with `strncat` and at one or more locations in a codebase an actual size bound could not be ascertained without more engineering effort than management was willing to spend.
  • dietrichepp 11y ago
    Ah yes, we are absolutely certain that this new code is incorrect, but it doesn't go against corporate policy.
    • stephencanon 11y ago
      The new code is precisely equivalent to the old code (except for the bug report linked here).
• brohee 11y ago
  No use case I can think of, but a credible scenario is an attacker somehow being able to manipulate the size parameter, due to another vulnerability, and then being able to further exploit the overflow. Quite a few recent practical attacks chained what looked like mostly harmless vulnerabilities taken individually.
  • dietrichepp 11y ago
    In this case I'm skeptical. SIZE_MAX may trigger integer overflow, but smaller values are still potential buffer overflows. It would have to be a rather contrived or pathological case in order for the integer overflow to be exploitable. That, and programs shouldn't be using strncpy or strncat anyway, at least 99% of the time.
    • spoiler 11y ago
      I rarely work with cstrings directly, and even then I don't tend to use them (`strcat`/`strncat`) myself; I tend to use `memcpy`/`memmove` instead. However, I'm curious why do you say they shouldn't be used? Is there any other reason, other than the performance overhead?
      • dietrichepp 11y ago
        Basically, strncpy and strncat shouldn't be used because they don't do what you want. You want a NUL terminated string without buffer overflow, but these functions instead work with fixed size strings. They're simply designed to perform a different task. In particular, they put 0…N NUL bytes at the end, but you usually want exactly one NUL byte, no more, no less.
        • __david__ 11y ago
          > In particular, they put 0…N NUL bytes at the end, but you usually want exactly one NUL byte, no more, no less. strncpy() does that but strncat() does not. strncat(s1,s2,size) is usually wrong for a different reason: the size argument specifies how many bytes to copy from s2 to the end of s1 (not including the trailing NULL). This means to not buffer overflow your s1 you need to call it like this strncat(s1, s2, sizeof(s1) - strlen(s1) - 1); ...Which of course everyone forgets. strlcat() is a nice replacement because it does that calculation for you, so you can just do: strlcat(s1, s2, sizeof(s1)); and you won't buffer overflow your s1.
• nly 11y ago
  Underflow, aka: strncat(s1,s2,-1)