0

We are developing one scheduler application in the C Programming language. We are using the HP-UX environment to compile and deploy the code. During the yearly external audit of application, we received one report that contains following number of observations.

  1. Dangerous functions: strcpy, strlen, strcat etc.

  2. Buffer overflow: memcpy

  3. Buffer overflow format string: sprintf, snprintf etc.

  4. Format string: printf, sprintf etc.

They also give the general recommendation — Contains some safe functions that is:

  1. strncpy_s

  2. strnlen_s

  3. strncat_s

  4. memcpy_s etc..

Now, the problem is there no such library available for HP-UX environment. Above given functions are supported only in the Windows environment.

  1. Is there any alternative available for dangerous functions in Linux environment?
  2. How we can mitigate buffer-overflow format string and format string category?
Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278
useradmin1234
  • 101
  • You can see what these functions do at e.g. https://en.cppreference.com/w/c/string/byte/strncpy. You might be able to find free implementations with an appropriate license, but they're also so trivial that you could just write them yourself if performance isn't critical. – Nate Eldredge Feb 26 '20 at 06:10
  • For 2, not sure what to say except "keep track of how big your buffers are and don't overflow them" and "don't use untrusted strings as printf format strings". – Nate Eldredge Feb 26 '20 at 06:11
  • 3
    The recommendation they gave are fairly meaningless IMHO. – n. m. could be an AI Feb 26 '20 at 06:53
  • Anybody who suggests those Annex K 'safe' functions to someone not exclusively targeting Windows using the MSVC toolchain shouldn't be listened to. – Shawn Feb 26 '20 at 08:06

1 Answers1

1

See Do you use the TR 24731 'safe' functions? for a discussion of the demerits of the _s functions.

Functions such as strcpy() are safe if (and only if) you know how big the source string and the target strings are. If you don't know, you're playing with fire.

Buffer overflows with memcpy() are outright bugs in your program; you can't use it reliably if you don't know the sizes, or that the buffers do not overlap (memmove() is safer; it handles overlaps). There's an argument to say "you don't need strcpy() or strcat() etc because if you have enough data to use them safely, you can use memmove() or memcpy() instead". On the whole, strlen() is pretty safe — as long as you pass it a string. If you don't know whether you're dealing with strings, then you've got lots of problems; you must know that you're dealing with strings to call the string manipulation functions.

Note that the strncpy() and strncat() functions are not safe. The problem with strncpy() is that it does not null terminate the string if the source is too long. The problem with strncat() is that passing sizeof(dst) as the size of the destination is wrong, even if the string is empty; it has one of the weirdest, most bug-prone interfaces of any extant C function — gets() is no longer counted as extant. If you know the sizes of everything, you don't need them. If you don't know the sizes, using them won't make you safe.

Using sprintf() is unnecessarily dangerous; using snprintf() should be safe as long as you get the size correct and pay attention to data truncation by testing the return value. Check to see whether asprintf() and vasprintf() are available — and consider using them if they are.

Format string vulnerabilities arise where you have:

printf(fmtstr, value1, value2);

where the fmtstr argument can be controlled or influenced by the user. If you can determine where the format string comes from and know it is safe, then there isn't a problem, and it can help with the internationalization of your code. If you can't determine that the format string is safe, you are running risks. How serious those risks are depends on the context in which it is used. If the user root will be running the code, which seems likely for a scheduler, then you must be meticulous. You may be able to be a little more blasé if the users running the code will not be root, but it is difficult to ensure that no-one ever runs the code as root.

You're right that the _s functions are not available except on Windows. The external auditors have been downright unhelpful — suggesting the use of functions that are not available on the target platform is counter-productive. There is room to debate whether using the _s functions is sufficient, Microsoft notwithstanding. They can be misused, just as any function can. See the N1967 paper referenced in my answer to the TR 24731 question. (There are later papers available from the C standard committee's web site at http://www.open-std.org/jtc1/sc22/wg14/ which don't entirely agree with N1967 — N2336 from the Pre-London 2019 mailing, for example. I'm not sure I entirely agree with N2336.)

Consider whether strlcpy() and strlcat() are available and could/should be used for strcpy(), strncpy(), strcat(), strncat().

Jonathan Leffler
  • 730,956
  • 141
  • 904
  • 1,278