Unsafe C functions and the replacement

Question

Please correct me if I'm wrong, I research in the site but can't find any consolidated post for this problem. There are many unsafe functions in C that can lead to buffer overflow and they have the safe functions to replace them. I have a few:

• gets() === replace by === fgets()
• sprintf() === replace by === ?
• strcat() === replace by === ?
• strcpy() === replace by === strncpy()
• vsprintf() === replace by === vsnprintf()

Also, I stuck with the unsafe byte copy and unsafe byte input code below. How can I fix the problems? Why does this code have vulnerability?

int copy_buf (char *to, int pos, char *from, int len)
{
    int i;
    for (i=0;i<len;<i++){
         to[pos] = from [i];
         pos++;
    }
    return pos
}

For the byte input, is the fread() unsafe function? Why does the buffer overflow happen here?

short read_chunk(FILE fil, char *to)
{
    short len;
    fread(&len, 2, 1, fil);
    fread(to, 1, len, fil);
    return len;
}

Answer 1

strncpy is not a safe replacement for strcpy. In fact, these functions are unrelated, despite the unfortunate similarity in the naming. Safe replacement for strcpy is a non-standard function strlcpy provided by some *nix implementations as an extension. Usage of strncpy for "safe" string copying is an immediate sign of incompetent code.

Another group of unsafe functions (albeit unsafe for a different reason) are functions from ato.. group: atoi, atof, atol and so on. These functions trigger undefined behavior in case of overflow. Their safe replacements are functions from strto... group: strtol, strtod and such.

There's nothing "unsafe" about your copy_buf function in a sense that it provides the calling code with all means necessary to perform a safe call to copy_buf. The responsibility to pass the correct values in this case is placed on the caller.

Your read_chunk function is much more dangerous, since the calling code has no way of knowing how big the buffer is supposed to be. There's no perfect solution for this function that would work well with a buffer passed from outside. It makes sense to at least make the calling code to pass the size of the buffer as well. This will allow read_chunk to make sure the buffer is not overflowed. Also, read_chunk should inform the calling code about incomplete reads. You should provide the caller with means to complete the read.

Answer 2

Here is the List of Some unsafe C Functions with their replaced New Function

• strcpy -> strncpy -> strlcpy/strcpy_s
• strcat -> strncat -> strlcat/strcat_s -strtok
• sprintf -> snprintf
• vsprintf -> vsnprintf
• gets -> fgets/gets_s
• makepath -> _makepath_s (MSDN)
• _splitpath -> _splitpath_s (MSDN)
• scanf/sscanf -> sscanf_s (MSDN)
• snscanf -> _snscanf_s (MSDN)
• strlen -> strnlen_s (MSDN)

Certain functions behave in dangerous ways regardless of how they are used. Functions in this category were often implemented without taking security concerns into account. The gets() function is unsafe because it does not perform bounds checking on the size of its input.

An attacker can easily send arbitrarily-sized input to gets() and overflow the destination buffer. Similarly, the >> operator is unsafe to use when reading into a statically-allocated character array because it does not perform bounds checking on the size of its input. An attacker can easily send arbitrarily-sized input to the >> operator and overflow the destination buffer.

The code below calls gets() to read information into a buffer.

char buf[24];
printf("Please enter your name and press <Enter>\n");
gets(buf);
...
}

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition

You can read More about Dangers in C/C++ further here..

1. http://www.dwheeler.com/secure-class/Secure-Programs-HOWTO/dangers-c.html
2. http://www.dwheeler.com/secure-programs/
3. http://courses.cs.washington.edu/courses/cse341/04wi/lectures/26-unsafe-languages.html