Microsoft To Banish Memcpy()

kyriacos notes that Microsoft will be adding memcpy() to its list of function calls banned under its secure development lifecycle. This reader asks, "I was wondering how advanced C/C++ programmers view this move. Do you find this having a negative impact on the flexibility of the language, and do you think it will restrict the creativity of the programmer?"

Comments

No - there are plenty of safer alternatives

[MerlynEmrys67]

Just like removing printf, scanf, and most other copy/string functions. There are safe versions of memcpy that work just fine and are just as easy to use...
Lame story (Trying for flamebait here?)

Re:No - there are plenty of safer alternatives

[Anonymous Coward]

I'd say it's a good move - passing the size of the destination buffer is usually not that complicated.

Are you high? It already takes a size argument. If this were about strcpy(3), then you'd have a point, but I do not think memcpy(3) means what you think it means.

I'm not saying you can't get yourself into trouble with inappropriate use of memcpy(3), but buffer overruns aren't the go-to threat every time.

NAME
memcpy - copy memory area

SYNOPSIS
#include <string.h>

void *memcpy(void *dest, const void *src, size_t n);

DESCRIPTION
The memcpy() function copies n bytes from memory area src to memory area dest. The memory
areas should not overlap. Use memmove(3) if the memory areas do overlap.

Re:No - there are plenty of safer alternatives

[Chris Burke]

Just like removing printf, scanf, and most other copy/string functions. There are safe versions of memcpy that work just fine and are just as easy to use...

There's nothing unsafe about printf (since compilers started doing format type checking), as long as you don't use user input as the format string. To print user input, you use printf("%s", user_input).

strcpy() is unsafe because you don't know how many bytes you are going to be copying. strncpy() is completely safe as long as you aren't brain dead and set the 'n' to the size of the destination buffer (as opposed to strlen(src) which would be brain dead) and then slap an '\0' into the last index of the dest. sprintf, same deal, just use snprintf and tell it the max bytes it can print.

So what's unsafe about memcpy()? You explicitly specify the number of bytes to copy. If that number of bytes is greater than the known size of the destination buffer, then you've got a problem that simply adding a second 'size of dest' paramater to the copy won't fix because you already screwed the pooch on figuring that out now didn't you?

Yes memcpy() doesn't work if src and dest overlap. When that's happening, you typically know about it (you've got some clever in-situ array modification going on) and can use memmove(). memmove(), on the other hand, is equally unsafe if you can't properly specify the number of bytes to copy.

Bottom line: There's no such thing as a "safe" copy in C when we're assuming the programmer can't figure out the destination buffer size.

Re:No - there are plenty of safer alternatives

[Anonymous Coward]

It's a psychological thing. Having a separate parameter for the size of the destination buffer forces the programmer to think about what that size is. Too often programmers call memcpy passing the size of the data that needs copying and forget to check that the destination is big enough. And that's why we see so many buffer overflows.

If you never make this mistake continue to use memcpy. I don't care and neither does Microsoft.

Re:No - there are plenty of safer alternatives

[FlyingBishop]

That's physically impossible, even given infinite time. Read up on the halting problem.

However, programming a framework in which we may rule out certain things, for example a process jumping over and altering the OS, is perfectly possible. It just has to be verified through reasoning, rather than testing. The unit testing methodology is really the problem here. You cannot unit test everything.

Don't get me wrong, testing is a good start, but it's no proof of security, and a proof of security, while very hard, is possible. Kudos to Microsoft.

And to expand on the GP for those that didn't RTFA, they replaced Memcpy with a memcpy that forced you to state the size of the destination buffer, which is a constant time operation, and a much needed one. So this only forces C coders to make their code a little more clear.

And when you're being intentionally unclear to the computer in addition to the reader, your code has no place in a secure production setting.

Re:No - there are plenty of safer alternatives

[Duhavid]

It still will not help.

If they are a sloppy enough programmer not to look at what is going on, and to ensure the size of the destination, they will be sloppy enough to use the same dratted variable in both spots, drool all over the keyboard and move on to the next sloppy bit of code.

Re:No - there are plenty of safer alternatives

[James Skarzinskas]

In an effort to "one-up" Microsoft, Apple promises to replace their own memcpy() with one that not only does not require a size for the destination buffer, but does not require a destination buffer at all. While Apple programmers call the move "totally pointless" and "absolute proof of functional retardation", Steve Jobs has simply responded, sagely, that the future of Apple development is through so-called "intuitive APIs". It just works.

Re:No - there are plenty of safer alternatives

[parlancex]

I know you were kidding, but I'd like to point out that the internal implementation of memcpy on many platforms will be much faster than the equivilent C using a loop for large copies, including x86/64 due to the use of architecture specific instructions designed to facilitate the operation that most compilers probably don't use even on the highest optimization levels.

Re:No - there are plenty of safer alternatives

[jd]

Whilst you are correct, if Microsoft is going to essentially replace the standard C library with one that has an incompatible API, why not just call it a new library and have done with it?

Or, better yet, if security really was the goal, develop a C-like language that was secure by design?

By simply making things awkward for people to write portable code, all they do is ensure that there are multiple code bases for projects (which increases the opportunity for error) or ensures that people won't write portably. Which is a more likely goal, given who we are talking about.

malloc() and free()

[Anonymous Coward]

Those are also dangerous functions. And also array indexing! That should also be eliminated.

No mention of memmove...

[pthisis]

Do you find this having a negative impact on the flexibility of the language, and do you think it will restrict the creativity of the programmer?"

You can replace memcpy entirely with memmove (the latter is slightly slower and handles overlaps), and nothing in the article suggests that memmove is banned.

But, no, it shouldn't hurt creativity--they're introducing a memcpy_s, which is the same aside from taking a size parameter for the destination. That's something that is generally easy to track in new code (obviously this secure developement lifecycle is not backwards compatible).

They should go one better...

[Smidge207]

...and pop up a message box asking the user to confirm they want to copy the memory, and if they press OK then they should have to enter a captcha.

Seriously though, how is it supposed to make your code safer if you pass the size you think your destination buffer is? With memcpy, that size is implicitly greater or equal to the copy size and it's the caller's responsibility to make sure this is the case. Putting bounds checking into the copy function is ridiculous if you're responsible for passing the bounds yourself, and it goes against basic good design. I'm surprised they aren't passing the source buffer size too, just to be extra safe. Also, what happened to the __restrict keyword? It's strangely absent from the memcpy_s function declaration.

=Smidge=

First they take my gets..

[adonoman]

First they came for gets, then they took scanf and strcpy, now they want memcpy? Outrageous! How are virus writers going to be able to take advantage of buffer overflows if I'm continuously keeping track of how big my buffers are? I may have to start lying about their size just to give hackers a chance.

Re:First they take my gets..

[Anonymous Coward]

First they came for gets, And I didn't speak up because I didn't use gets
Then they came for scanf, And I didn't speak up because I didn't use scanf
Then they came for strcpy, And I didn't speak up because I didn't use strcpy
And then... they came for memcpy... And by that time there was no one left to speak up.

What an idiotic idea.

[Anonymous Coward]

Someone already explained this better than I could.

Re:Isn't security the programmer's responsibility?

[Anonymous Coward]

you didnt read.

MSFT is banning it from their development process, not the language, use it as much as you like.

the worst offender is main()

[JeanBaptiste]

Most any security problem can be traced back to this function.

The wole thing is just a bunch of nonsense

[LanceUppercut]

Firstly, the specification of C anf C++ standard library is governed by the corresponding standard commitee. Microsoft has absolutely no authority to "banish" anything from neither C nor C++. They can deprecate it in their .NET code, C# etc., but it has absolutely no relevance to C and C++ languages. So, why would the author of the original question direct it to "advanced C and C++" programmers is beyond me. In general, C and C++ programmers will never know about this "interesting" development.

Secondly, the tryly unsafe and useless functions in the C standard library are the functions like "gets", which offer absolutely no protection agains buffer overflow, regardless of how careful the develoiper is. Functions like 'memcpy', on the other hand, offer sufficient protection to a qualified developer. There's absolutely no sentiment against these functions in C/C++ community and there is absolutely no possiblity of these functions to get deprecated as long as C language exists.

Re:How to easily ...

[cool_story_bro]

He didn't say "how to make your code safe." He said "how to make your code comply with the safety standards." Rarely are the two the same. It's perfectly possible to safely use memcpy(), just like it's perfectly possible to abuse about a billion other system calls.