Microsoft excommunicates memcpy()

Microsoft has previously outlawed copying functions such as strcpy(), strncat() and gets() from the Security Development Lifecycle (SDL), because they don't check the size of the memory block to be written to, very frequently causing buffer overflows that endanger security. The same fate now threatens to overtake memcpy().

As its name suggests, this C function serves to copy data from one memory area to another. For security reasons, Microsoft has, for some time, been advising against its use. It seems that this year this recommendation is to be upgraded to an outright ban and it will also apply to CopyMemory() and RtlCopyMemory().

Rules of this kind are automatically enforced in Redmond. Specifically, this means that Microsoft's developers can no longer check code into the version management system if it calls any of the banned functions, even if the code has been sufficiently secured. Microsoft suggests memcpy_s() as a replacement function. This takes the size of the destination buffer as an additional parameter, and also checks whether the number of bytes to be written exceeds it.

Yet this time things aren't quite as straightforward as Microsoft would like us to believe. Unlike previously outlawed functions like strcpy() that don't provide for any length parameters, with memcpy() a developer already has to state the number of bytes to be written: memcpy(dst, src, len). In the replacement function, the size of the destination area is added, so ideally a call would look like this:

memcpy_s(dst, sizeof(dst), src, sizeof(src));

However that might prove to be no more than wishful thinking. Felix von Leitner, a security expert specialising in code reviews, says developers who don't care about security will be more likely to sidestep the block in case of doubt by simply transforming memcpy(a,b,c) into memcpy_s(a,c,b,c). He says memcpy() is already sufficiently secure for developers that take the security of their programs seriously. He criticises Microsoft's approach, warning that bugs can't be eliminated by prohibiting dangerous APIs.

Another problem, though it probably matters less to Microsoft, is that the replacement function is not standardised. For instance, glibc, the C library used on Linux systems among others, doesn't contain memcpy_s(). That creates another obstacle for software developers who work on platform-independent developments, or who'd like to port Windows programs to other platforms.

(crve)