Memcpy() in secure programming?

问题:

I recently stumbled across an article that claims Microsoft is banning the memcpy() function in its secure programming shops. I understand the vulnerabilities inherent in the function, but is it necessary to ban its use entirely?

Should programs I write be avoiding memcpy() entirely, or just ensuring that it's used safely? What alternatives exist that provide similar but safer functionalilty?

回答1:

Microsoft provides alternatives to memcpy and wmemcpy that validate their parameters.

memcpy_s says, "Hmm, before I read from this address, let me verify for myself that it is not a null pointer; and before I write to this address, I shall perform that test again. I shall also compare the number of bytes I have been requested to copy to the claimed size of the destination; if and only if the call passes all these tests shall I perform the copy."

memcpy says "Stuff the destination into a register, stuff the source into a register, stuff the count into a register, perform MOVSB or MOVSW." (Example on geocities, not long for this world: http://www.geocities.com/siliconvalley/park/3230/x86asm/asml1013.html)

Edit: For an example in the wild of the Your Wish Is My Command approach to memcpy, consider OpenSolaris, where memcpy is (for some configurations) defined in terms of bcopy, and bcopy (for some configurations) is ...

void
     33 bcopy(from, to, count)
     34 #ifdef vax
     35     unsigned char *from, *to;
     36     int count;
     37 {
     38 
     39     asm("   movc3   12(ap),*4(ap),*8(ap)");
     40 }
     41 #else
     42 #ifdef u3b      /* movblkb only works with register args */
     43     unsigned char *from, *to;
     44     int count;
     45 {
     46     asm("   movblkb %r6, %r8, %r7");
     47 }
     48 #else
     49     unsigned char *from, *to;
     50     int count;
     51 {
     52     while ((count--) > 0)
     53         *to++ = *from++;
     54 }
     55 #endif

Edit: Thanks, Millie Smith! Here is what was on the geocities page I linked above:

MOVS

The instruction movs is used to copy source string into the destination (yes, copy, not move). This instruction has two variants: movsb and movsw. The movsb ("move string byte") moves one byte at a time, whereas movsw moves two bytes at a time.

Since we'd like to move several bytes at a time, these movs instructions are done in batches using rep prefix. The number of movements is specified by CX register. See the example below:

:
lds   si, [src]
les   di, [dest]
cld
mov   cx, 100
rep   movsb
:

This example will copy 100 bytes from src to dest. If you replace movsb with movsw, you copy 200 bytes instead. If you remove the rep prefix, the CX register will have no effect. You will move one byte (if it is movsb, or 2 bytes if it is movsw).

回答2:

A chainsaw, if used properly, is safe. Same thing with memcpy(). But in both cases, if you hit a nail, it can fly and hurt you.

In short, memcpy() is required for low-level computing and won't go away, but for high-level programming you don't need it. There is no memcpy() in Python.

回答3:

Don't bother. Microsofts alternatives are not that much better. The main value is that these cause your code to become unportable to Linux. Microsoft is making much more money on the OS they sell to your customers than they're making on the copy of Visual C++ you bought.

回答4:

The article itself describes a safer alternative: memcpy_s, which requires you to specify the maximum length of the target. When that number is provided independent of the amount of bytes to copy, it acts as a barrier to prevent buffer overflow. Of course, you can abuse that by giving the same number to both.

回答5:

Is banning memcpy() in my code making me a better programmer and my application safer or just more incompatible? I'm uncertain, if MS really wants to change anything or just make any new C code incompatible with other compilers. Btw. MS does this trick on many functions and it's quite annoying. strcpy -> strcpy_s -> StringCchCopy.

回答6:

I think that C should leave an option to the programmer to shoot his own foot. manual memory management is safe if done properly.

回答7:

You said it yourself: "Microsoft is banning the memcpy() function in its secure programming shops, I understand the vulnerabilities inherent in the function,"

memcpy() and a plethora of other standard functions are known to cause vulnerabilities, so why would a secure programming shop allow their use when an (albeit incremental) improvement is trivial?

No doubt in their efforts to improve the security of their own products, the code reviews clearly indicated that these functions were responsible for a significant proportion of vulnerabilities, buffer overflows etc. Rather than make wrappers for internal use only they introduced them into the standard library and added a compiler warning (not a ban) for the benefit of all.

回答8:

The alternative is to call memcpy_s

回答9:

If you're using older versions, like C99 or C++98, or on Solaris, you can't use memcpy_s, unless you have the Safe C library installed.

memcpy_s() is a Microsoft-specific implementation that doesn't exist on non-MS implementations, including ANSI, prior to C11, per their own standards.

I'll leave the pro-MS and anti-MS stuff aside, because it's irrelevant.

memmove() is a better solution anyway since it addressed the overlap issue. memmove_s() is more robust, but again, only if you're in C11 or later.

回答10:

You are supposed to use memcpy_s() instead. The same kind of _s versions exist for a variety of other functions considered as unsecure.