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?
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.
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.
You are supposed to use memcpy_s() instead. The same kind of _s versions exist for a variety of other functions considered as unsecure.
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
I think that C should leave an option to the programmer to shoot his own foot. manual memory management is safe if done properly.
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.
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.
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.