memcpy() Is Going to Be Banned

by Abel Avram on May 21, 2009 |

The memcpy() function has been recommended to be banned and will most likely enter Microsoft’s SDL Banned list later this year. memcpy() joins the ranks of other popular functions like strcpy, strncpy, strcat, strncat which were banned due to their security vulnerability through buffer overruns.

A number of Microsoft security updates were issued over time because of memcpy(): MS03-030 (DirectX), MS03-043 (Messenger Service), MS03-044 (Help and Support), MS05-039 (PnP), MS04-011 (PCT), MS05-030 (Outlook Express), CVE-2007-3999 (MIT Kerberos v5), CVE-2007-4000 (MIT Kerberos v5), and others.

The functions to be banned by Microsoft are memcpy(), CopyMemory(), and RtlCopyMemory(). To start banning these functions one should add the following #pragma line to a header file and the compiler will issue a warning every time it encounters one of them:

#pragma deprecated (memcpy, RtlCopyMemory, CopyMemory)

or, alternatively for C++, by using the next line:

#define _CRT_SECURE_WARNINGS_MEMORY

or, for GCC, by using the next one:

#pragma GCC poison memcpy RtlCopyMemory CopyMemory

The recommended function to be used instead is memcpy_s() which has the following signature in VC++ 2008:

errno_t __cdecl 
    memcpy_s(
        _Out_opt_bytecap_post_bytecount_(_DstSize, _MaxCount) 
                void * _Dst,
        _In_ rsize_t _DstSize, 
        _In_opt_bytecount_(_MaxCount) const void * _Src, 
        _In_ rsize_t _MaxCount
    );

memcpy_s() is not error prone because one might specify a longer destination size than it is actually allocated leading to the same security vulnerability as memcpy().

The SDL complete list contains many banned functions calls along with recommended functions to be used instead. Some of them are:

Description	Banned function	Recommended function
String copy	strcpy, wcscpy, _tcscpy, _mbscpy, StrCpy, StrCpyA, StrCpyW, lstrcpy, lstrcpyA, lstrcpyW, strcpyA, strcpyW, _tccpy, _mbccpy	strcpy_s
String concatenation	strcat, wcscat, _tcscat, _mbscat, StrCat, StrCatA, StrCatW, lstrcat, lstrcatA, lstrcatW, StrCatBuffW, StrCatBuff, StrCatBuffA, StrCatChainW, strcatA, strcatW, _tccat, _mbccat	strcat_s
Sprintf	wnsprintf, wnsprintfA, wnsprintfW, sprintfW, sprintfA, wsprintf, wsprintfW, wsprintfA, sprintf, swprintf, _stprintf	sprintf_s
Tokenizing	strtok, _tcstok, wcstok, _mbstok	strtok_s
Scanf	scanf, wscanf, _tscanf, sscanf, swscanf, _stscanf	sscanf_s
Numeric conversions	_itoa, _itow, _i64toa, _i64tow, _ui64toa, _ui64tot, _ui64tow, _ultoa, _ultot, _ultow	_itoa_s, _itow_s
Gets	gets, _getts, _gettws	gets_s

SDL has offered a header file (banned.h) to be included in order to get warnings for all the banned functions. As an alternative method, one can use the /W4-C4996 compiler option in VS 2005 or later.

Related Editorial

Why NoSQL - Three Trends Disrupting the Database Status Quo

Building Content-Driven Apps - Couchbase and Elasticsearch for Content and Metadata Stores

From Killer Apps to App Killers: The Devastating Effect of Architecturally Complex Defects

Impact of Java EE Frameworks on the Structural Quality of Applications

Making the Shift from Relational to NoSQL

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

nag by Seb R Posted

nag by Seb R

I'll shoot anyone I see doing this in GCC:
#pragma GCC poison memcpy RtlCopyMemory CopyMemory

The main reason is obvious: memcpy_s is not part of the C standard, and will never likely be. Microsoft would love to be the C standard, I'm sure, but they haven't even implemented C99 yet so what do us -actual- C programmers care about them?

memcpy, strcpy, strncpy, strcat and strncat are all perfectly safe providing you check the length of the input to make sure it can fit into the buffer provided, and/or provide a correct length argument. Those who believe it is unsafe due to previous exploits need to reconsider where they place blame: the machine, or the user defining what the machine shall do.

"Of course, you can easily make a call to memcpy_s() insecure by getting the buffer sizes wrong." Exactly! They are equally safe, providing the programmer(s) take the effort to provide correct input. They are equally unsafe when the programmer(s) using them neglect to provide correct input.