Secure C and the universities - trained for buffer overflow

Question

Hi!

I recently finished a university course in C. Therefore I lack experience, of course.

Some universities tend to teach their students secure programming, or at least some elements. There's even a video (taken from here).

Being in C, copying strings, requires - as far as I know - strcpy or string.h functions. How do you use it securely in every-day programming? Do you have some functions, which handle allocation to prevent buffer overflows? There's the CERT secure coding standard for C. It's offering examples and compliant solutions:

int main(int argc, char *argv[]) {
  /* ... */
  char prog_name[128];
  strcpy(prog_name, argv[0]);
  /* ... */
}

And their alternative is:

int main(int argc, char *argv[]) {
  /* ... */
  char *prog_name = (char *)malloc(strlen(argv[0])+1);
  if (prog_name != NULL) {
    strcpy(prog_name, argv[0]);
  }
  else {
    /* Couldn't get the memory - recover */
  }
  /* ... */
}

Taken from here, 2nd example.

But as far as I get it that's just more challenging, more code, more work. Why does no one change the library itself? Or at least why does no one provide a secure alternative library or functions, which handle this in the right way?

Thanks for reading, wishi

Answer 1

Actually, Microsoft did provide secure alternatives to the CRT functions. Everybody I know hates them though and disables the warning that you shouldn't use the old functions. If you want something secure, maybe you should use C++. And then either STL strings or something like Qt.

Well, or you go to platforms like .NET or Java, which usually doesn't suffer from these problems (your app might crash, but no way to inject code into your app through a buffer overflow).

Edit: With Data Execution Prevention / NX enabled (default for Vista and .NET), this shouldn't be a problem for traditional platforms as well.

Answer 2

The Posix function for this (available on nearly every system) is strdup(). strcpy() is used if you don't want to allocate new memory and already have a buffer you want to use, but then you better known how big that buffer is and if the string fits in it. If you don't know if the string fits, there is strncpy() that just copies a given number of characters. So you can limit the copied amount to your buffers size.

And besides of that, there are lots of sting libraries that manage string sizes in different ways.

And since you tagged it C++: There is std::string that does all the memory management for you and doesn't give you these problems.

Answer 3

Use strncpy:

#define BUFSIZE 127
int main(int argc, char *argv[]) {
  /* ... */
  char prog_name[BUFSIZE + 1];
  strncpy(prog_name, argv[0], BUFSIZE);
  progname[BUFSIZE]= '\0';
  /* ... */
}

There are *n* versions for most str* functions.

Answer 4

the l (strlcpy, strlcat) functions from OpenBSD are usually better than the n functions, they are both faster and easier to use securely, but they are nonstandard. However, they are BSD licensed so you can include a known good implementation in any program so you can be both cross platform and secure.

For Windows, if you don't care about portability, you can use *_s functions.

Answer 5

int main
(
    int argc, 
    char *argV[]
) 
{
   char prog_name[128];
   if (strlen(argV[0]) < sizeof(prog_name))
   {
       strcpy(prog_name, argV[0]);
   }
   else
   {
       printf("%s is too large for the internal buffer\n", argV[0]);
   }

   return 0;
}

Answer 6

Thanks for these helpful answers. ;)

Answer 7

Maybe you would find useful reading answers to this question

Answer 8

If I understand correctly, your real question is why the API functions are not made more secure.

One reason reason is that C library is legacy (too late to change it now).

The main reason, however, is that the library is designed to be minimalistic, so that it does the bare minimum and it is the user's responsibility to ensure that it is called correctly. If it was doing any excessive checks, then a price would be paid every time it is called, even if the user can assure for other reasons that no problem is going to occur. This is very very common in many APIs.

That being said, there are enough libraries that provide safer alternatives, they're just not part of the standard library. Also, many people who do higher level stuff work with C++, that has standard class libraries for many of those things.