BT

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.

Hello stranger!

You need to Register an InfoQ account or or login 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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT