Banning Functions in C

I came across this post on Bruce Schneier’s weblog on security, actually this is what Steve quoted from the original article:

Microsoft plans to formally banish the popular programming function that’s been responsible for an untold number of security vulnerabilities over the years, not just in Windows but in countless other applications based on the C language. Effective later this year, Microsoft will add memcpy(), CopyMemory(), and RtlCopyMemory() to its list of function calls banned under its secure development lifecycle.

I had to sit on this for a while to really think about it, on the surface it makes sense to me, but the more I thought about it the less sense it made.

Speaking as a C programmer here (amongst the various languages I know), there are some functions you have to use carefully otherwise you will quickly get into trouble, memcpy() is one and there are others. But you usually only get into trouble if you don’t check your lengths and buffers to make sure you don’t exceed a buffer size when you use these functions.

What bothers me is that there are plenty of other ways to get into trouble, such as exceeding the end of an array, or running off the end of a structure, or just exceeding the length of a buffer when reading or writing data. Banning the use of certain dangerous functions will not fix that and may lure the developer into a false sense of security which is worse because it encourages coding which has not been fully thought out which is what we are trying to fix in the first place. C allows the developer a great deal of flexibility and speed but these come at a price.

The way I approached this was to avoid the use of unbounded functions (like strcpy() and memcpy()) unless bounds were checked and safe. I wrote ‘safe’ versions of the string copying functions such as strncpy() and strncat), the versions I have check bounds and forcibly puts a terminating NULL at the end of the string when needed. You can still ‘kill’ yourself but the wrappers take case of 90% of the cases.

Finally I wrote ‘safe’ wrappers around all the functions I use to check all the input parameters for sanity. I have found that certain platforms are more lenient than other when bad parameters are passed, some will return an error and others will just crash.

Advertisements

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: