Slashdot Mirror

← Back to Stories (view on slashdot.org)

Microsoft To Banish Memcpy()

Posted by kdawson on from the good-riddance dept.

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?"

35 of 486 comments (clear)

  1. No - there are plenty of safer alternatives by MerlynEmrys67 · · Score: 5, Insightful

    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?)

    --
    I have mod points and I am not afraid to use them
    1. Re:No - there are plenty of safer alternatives by Anonymous Coward · · Score: 4, Insightful

      safe versions - if you prefer to blindly program away, not worrying about where your objects end up in memory. But - what is "safe"? Is there any replacement for properly testing all I/O from all possible sources?

    2. Re:No - there are plenty of safer alternatives by Anonymous Coward · · Score: 5, Informative

      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.

    3. Re:No - there are plenty of safer alternatives by Chris+Burke · · Score: 5, Informative

      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.

      --

      The enemies of Democracy are
    4. Re:No - there are plenty of safer alternatives by Anonymous Coward · · Score: 5, Insightful

      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.

    5. Re:No - there are plenty of safer alternatives by FlyingBishop · · Score: 5, Informative

      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.

    6. Re:No - there are plenty of safer alternatives by Duhavid · · Score: 5, Insightful

      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.

      --
      emt 377 emt 4
    7. Re:No - there are plenty of safer alternatives by makomk · · Score: 4, Interesting

      If you're a competent programmer then nothing is unsafe, but obviously there are a lot of stupid programmers out there who make fundamental mistakes fucking with memory when they don't understand what they're doing. What Microsoft is trying to do here is to eliminate a low hanging fruit of software security that has led to hundreds if not thousands of buffer overflow conditions and associated vulnerabilities/exploits.

      The trouble is, it doesn't. Banning functions like strcpy made sense, because they were nearly always unsafe to use. On the other hand, if you're memcpying too much data for the destination, there's probably something more fundamentally wrong with your code. This, at best, conceals the bug by truncating the copy - leading to unpredictable issues later in execution instead.

    8. Re:No - there are plenty of safer alternatives by George+Reilly · · Score: 4, Informative

      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).

      %n writes to the stack. It's disabled by default in VS2005 onwards. More at http://weblogs.asp.net/george_v_reilly/archive/2007/02/06/printf-n.aspx and http://julianor.tripod.com/bc/formatstring-1.2.pdf

      --
      /George V. Reilly
    9. Re:No - there are plenty of safer alternatives by Chris+Burke · · Score: 4, Insightful

      What Microsoft is trying to do here is to eliminate a low hanging fruit of software security that has led to hundreds if not thousands of buffer overflow conditions and associated vulnerabilities/exploits.

      They might be trying, but they are failing, because the mistake that leads to the error in the first place (miscalculating destination buffer size) has the same effect (buffer overrun) whether you use memcpy() or memcpy_s().

      --

      The enemies of Democracy are
    10. Re:No - there are plenty of safer alternatives by James+Skarzinskas · · Score: 5, Funny

      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.

    11. Re:No - there are plenty of safer alternatives by parlancex · · Score: 5, Insightful

      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.

    12. Re:No - there are plenty of safer alternatives by jd · · Score: 5, Insightful

      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.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  2. malloc() and free() by Anonymous Coward · · Score: 5, Funny

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

  3. No mention of memmove... by pthisis · · Score: 5, Informative

    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).

    --
    rage, rage against the dying of the light
  4. They should go one better... by Smidge207 · · Score: 5, Insightful

    ...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=

    --
    Is it just my observation, or is eldavojohn an idiot?
    1. Re:They should go one better... by Creepy · · Score: 4, Informative

      The problem is memcpy returns a void *. If this is dynamically cast, it needs to be checked at runtime and may even be set to a value the programmer never intended (say unsigned 16 bit values instead of unsigned 8 bit characters). It may be an issue with updating the code - say the code was originally written for 8 bit ASCII and got updated to, say UTF-16 (16 bit). A dynamically cast void* doesn't care what the size is, it just shoves the values in the buffer. This may work fine in basic testing even, because you never overflow the buffer with 1-2 characters, and maybe even gets past a QA team, but once you go past 1/2, you've got a buffer overrun.

      As I understand it, __restrict wouldn't work in a C++ program using dynamic_cast because it doesn't know the size at compile time (sorry, I'm not sure what is done in C as I haven't kept up with the language, so I have to use a C++ example). My guess is memcpy_s does runtime bounds checking (it isn't specified on the memcpy_s page, maybe the security ref - too busy to read it though).

  5. First they take my gets.. by adonoman · · Score: 5, Funny

    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.

    1. Re:First they take my gets.. by Anonymous Coward · · Score: 5, Funny

      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.

  6. What an idiotic idea. by Anonymous Coward · · Score: 5, Informative

    Someone already explained this better than I could.

  7. Re:Python is done by Rycross · · Score: 4, Informative

    No its not. This is only banned under Microsoft's Security Development Lifecycle, which means you only care about this if you're following those set of development guidelines. Its still in the language. And you can always use memcopy_s:

    Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer.

  8. Re:Isn't security the programmer's responsibility? by Anonymous Coward · · Score: 5, Informative

    you didnt read.

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

  9. Re:Should have been done 30 years ago. by james_shoemaker · · Score: 4, Insightful

    Why? I can see some justification on the strXXX functions where you don't know how many bytes are going to be copied unless you call strlen first, but in memcpy you pass how many bytes to copy in as a parameter. So this is to protect programmers who can't do math?

  10. the worst offender is main() by JeanBaptiste · · Score: 5, Funny

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

    1. Re:the worst offender is main() by Khashishi · · Score: 4, Funny

      you mean WinMain()

  11. Silly and useless by ugen · · Score: 4, Insightful

    This is nothing like sprintf. In sprintf there is no way to know how much data will be created ahead of time, so limit on buffer size is useful to make sure there is no buffer overrun.

    With memcpy it is *precisely* known how much data will be copied. It is right there, 3rd parameter. If a developer can't do "if (sizetocopy = sizeofdstbuffer)", it is just as unlikely that he will be able to properly state that additional parameter that specifies the destination buffer size.

    Of course if Microsoft is so concerned with security, why the heck did it take them years to add snptinf()? All this is is another attempt to make crossplatform development that much harder (much like all those "obsolete" POSIX functions that will barf warnings unless you use a cryptic define).

    That said, if this silliness ever becomes a rule, I have an easy solution:
    #define memcpy(dst, src, size) memcpy_s((dst), (src), (size), (size))

    Problemo solved, now let's go actually write some real code.

  12. When will MS learn? by coppro · · Score: 4, Insightful

    This is not the first time MS has done this. They have plenty of other standard functions that they have deprecated.

    Yes, you read that right. Microsoft is deprecating parts of an ISO Standard all by themselves. Not that this should surprise anyone. I would have absolutely no objection to them proposing to WG14 to deprecate those functions; heck, I'd encourage it! But besides going out and deciding to 'deprecate' parts of the standards, the replacement functions actually violate those same standards.

    And the warnings are irritating. You can't write a nice cross-platform library without either spewing tons of warnings or having to put in a bunch of #defines to shut the compiler up. And if you do that, your users get irritated if they depend on these warnings because you just turned them off (and of course, if you don't, they'll complain that your library is unsafe).

    Screw Microsoft.

    1. Re:When will MS learn? by theCoder · · Score: 4, Insightful

      In case anyone is curious, this is the type of thing that coppro is talking about:

          c:\Program Files\Microsoft Visual Studio 8\VC\include\io.h(318) : see declaration of 'close'
          Message: 'The POSIX name for this item is deprecated. Instead, use the ISO C++ conformant name: _close. See online help for details.'

      Now, as far as I know, no ISO body has deprecated functions like close(2), open(2), read(2), and write(2). And I've always heard that methods that start with an underscore are internal compiler functions and shouldn't be called directly. I don't know why the MS compiler writers think they can do this, but it is really annoying to get hundreds of warnings like this when compiling. In addition, it hides legitimate warnings that could indicate real problems.

      As to the article in question, I can't think of any good reason why memcpy(3C) would be considered unsafe, since it specifies the amount of memory to copy. Sure, you could use it to copy outside the bounds of dst, but that's just calling it incorrectly. It's not like sprintf(3C) where you could easily accidentally write outside the bounds of the string.

      --
      "Save the whales, feed the hungry, free the mallocs" -- author unknown
  13. Stop protecting me from me! by BitZtream · · Score: 4, Interesting

    As a competent developer, I get extremely annoyed by this sort of shit.

    Removing/banning memcpy doesn't change a damn thing cause the first thing I do with things that have to compile in VisualStudio now is add the following defines which turn this shit off:

    _CRT_SECURE_NO_WARNINGS
    _CRT_NONSTDC_NO_DEPRECATE

    If the remove that option I'll simply add memcpy to my standard MS compatibility library that deals with all the other bullshit MS decides to do.

    You can't fix stupid. Stop trying. People fuck up VB and C# apps just as much as the fuck up C and C++ apps. So they don't do it with a buffer overflow, they do it by shear stupidity. You'll be more secure by taking away languages that allow non-programmers to pretend to be programmers than making it harder on those of us that are just going to work around what you do anyway.

    You're not going to fix broken shitty apps with exploits by removing functions, the functions aren't the problem they do exactly as they are told (or atleast they are supposed to :). You need to fix the programmers who can't clarify what they want done.

    http://www.xkcd.com/568/
    Second pane:
    You'll never find a programming language that frees you from the burden of clarifying your ideas.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  14. easy fix by Chris+Snook · · Score: 4, Insightful

    Just write a one-liner that replaces all calls to memcpy with a call to memcpy_s, duplicating the size parameter.

    I'm only half-joking. This is exactly how people will (mis)use memcpy_s. If you want safe memory access, you need to ban the entire C language. For those cases where you need C, you'll just have to make sure your programmers know what they're doing.

    --
    There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
  15. How to easily ... by DemoLiter3 · · Score: 4, Insightful

    How to easily make your code compliant with the new safety requirements:

    #define memcpy(dest,src,len) memcpy_s(dest,len,src,len)

    1. Re:How to easily ... by cool_story_bro · · Score: 5, Informative

      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.

      --
      You must wait a little bit before using this resource; please try again later.
  16. The wole thing is just a bunch of nonsense by LanceUppercut · · Score: 5, Insightful

    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.

  17. Lock in from Microsoft by wandazulu · · Score: 4, Interesting

    There have been several suggestions to replace memcpy with memcpy_s as the safer alternative. That's fine, I guess, if memcpy_s is part of the ANSI/ISO standard for C, which as far as I know, it is not; just like all the *_s functions.

    Microsoft says your code is safer when using the *_s, but it will no longer be portable, it'll be Microsoft-only. They put in a warning in the compiler from VS2005 onwards about using "unsafe" functions, and that you should use *_s, which is a pain because you have to disable it as the project level, there doesn't seem to be anywhere that I've found that can just turn it off permanently. Even using the STL that comes with VS2008 will generate these warnings, even if you never do any explicit memory stuff yourself.

    Microsoft did the same thing with the _* functions; a lot of them are just wrappers around their ANSI-compliant versions (_sprintf -> sprintf), but are also not portable; I worked with a guy who wrote/tested all his C code in VS6 then gave it to me to port to Unix and VMS, and the compilers would choke on not having these particular functions.

    Microsoft is trying to get lock-in at the language level instead of providing a good set of Win32 API-based functions that make using memcpy() unnecessary.

  18. The goto threat == Raptors by beathach · · Score: 4, Funny

    Foolish mammal, they cannot be defeated so easily. http://xkcd.com/292/