Microsoft To Banish Memcpy() 486
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?"
Stop protecting me from me! (Score:5, 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/ [xkcd.com]
Second pane:
You'll never find a programming language that frees you from the burden of clarifying your ideas.
Re:Not for C++ (Score:3, Interesting)
= never modifies the right-hand side of the equal sign, only the left hand side.
std::auto_ptr would like a word with you. This was one of the dumbest decisions the committee made.
Re:Think about it (Score:3, Interesting)
The idea that smart people don't make mistakes is thoroughly ridiculous.
They make mistakes, they don't make that mistake.
Smart people recognize that they make mistakes, so they create systems that help them catch and prevent their own mistakes. If you're foolish enough to believe that you can't make mistakes, then you should just turn off all the warnings on the compiler and not bother with lesser workarounds like redefining a single symbol.
That's not the issue. The new function is still relying on the programmer not making a mistake. What makes you think that anyone who would make a mistake on the number of bytes to copy wouldn't make a mistake on the size of the buffer? Alternatively, what happens if the src buffer size isn't large enough? Do we need to add another length parameter here?
I have nothing against making a language safer, but if the language can't ensure the size of the buffers itself (and it can't in this case), relying on the programmer to pass in the correct number is exactly as safe as relying on the programmer to do the bounds checking. Exactly as safe, no safer.
Re:Let Java do it for you. (Score:2, Interesting)
Until you're trying to do something for which Java has no standard API. Last time I checked, USB joysticks were like this. There is JInput, but if you include JInput in your distribution, your project is no longer 100% Pure Java and will not run as an applet.
But your C/C++ code is never able to be run as an applet, while Java code might. So, on these grounds Java is better.
Or unless your target platform is incapable of running managed code. Some handheld platforms have only 4 MB of RAM, not enough for a JIT compiler and the bytecode in addition to the translated code except in trivial examples that act a generation old.
And for that we have Java ME edition.
Okay, there are devices that are even more tiny in which C or assembly is the only option. I've also dealt with a processor that couldn't be programmed in C without extensive non-standard C extensions. Either way, this is a small minority of situations -- there is no one solution that suits all purposes.
And per Apple's developer agreement, the only managed language that can run on an iPod Touch is JavaScript in Safari.
And they allow just any old C code to run?!!
Or unless your existing program's model [wikipedia.org] is written in an unmanaged language, and you want to reuse the old code so that you can be sure that the model is bit-for-bit accurate. How hard is it to automatically translate C code to, say, C++/CLI?
Eeek! Don't do this!
If you want bit-by-bit accuracy, you absolutely don't want to try translating C code to C++! You even have to worry about changing C compilers if you are doing that. (And yes, I have worked with C code which would break if we used a different compiler. It was not fun.)
What you should be thinking of doing is to write an interface between the existing model code and your new one. This can be done in both C++ and Java. When the new code has to manipulate the model, it goes through this interface and calls the old code to do the necessary operation.
Re:No - there are plenty of safer alternatives (Score:2, Interesting)
In the same way that having a seat belt and an air bag in my car, doesn't change my driving habits
I consider myself a safe driver. Seat belts and air bags don't really affect my driving habits either (as far as I know). But what If there was a 7 inch (~18cm) spike sticking out of your steering wheel and 100lbs (~45kg) of high explosives attached to both bumpers, would your driving habits change? Me? Maybe. Sometimes a little danger can make things a little safer. I once heard of a study that showed some poorly painted and poorly lit roads had an increased accident rate when lighting was added and the yellow lines were re-painted. Apparently people began speeding b/c of the perceived increase in safety. I don't remember the source. Maybe Uncle Google can help me later, but I have to get back to work now.
Re:Should have been done 30 years ago. (Score:4, Interesting)
If you haven't tried Ada yet, I highly suggest looking into it. It keeps track of data sizes, types, etc... for the programmer but it will also let you get close to the hardware like C does. It's often used for safety critical software such as that used in aviation.
Unfortunately I can't recommend using Ada to develop windows apps. It's technically possible but you end up importing C library functions to do it. And if you're going to do that, you might as well just use a native development environment that is better suited to the task.
Re:Let Java do it for you. (Score:3, Interesting)
And for [platforms with small CPU and small RAM] we have Java ME edition.
That is, if your platform vendor offers a port of Java ME.
If you want bit-by-bit accuracy, you absolutely don't want to try translating C code to C++! You even have to worry about changing C compilers if you are doing that.
I already test my code on GCC targeting x86 and ARM. Or did you mean compilers that a hobbyist looking to start a business can't easily afford?
What you should be thinking of doing is to write an interface between the existing model code and your new one. This can be done in both C++ and Java. When the new code has to manipulate the model, it goes through this interface and calls the old code to do the necessary operation.
Mostly I was thinking about trying to port an existing video game to a phone that runs Java ME MIDP or a game console that runs XNA, while preserving frame-for-frame accuracy of the physics. You can't run the old model on such hardware because you don't have the certificate to digitally sign native code. Or did your "interface" include communication over a network to a server running the model?
Re:Shooting themselves in the foot. (Score:4, Interesting)
Now, all that's going to happen is that programmers are going to write their own memcpy-like routines using a quicky for-loop or something. It'll be just as bug prone, and harder to detect via automated source code analysis.
Not to mention it'll be slower. memcpy is one of the most optimized functions in any C library. It's frequently handled as a compiler intrinsic, that can do stuff like unroll short copies, generate optimal machine code, etc.
Re:No - there are plenty of safer alternatives (Score:5, 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.
Lock in from Microsoft (Score:5, 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.
Re:When will MS learn? (Score:3, Interesting)
Wrong, wrong, wrong.
open, close, etc.. are not in ISO C++. Functions not in the spec (vendor-specific) are supposed to have an _ in front.
Any function you can think of (including strcpy) is "safe" if the developer specifies correct parameters. Whoopdy Do. That doesn't mean it's something that's easily verified by runtime checkers, static analysis, etc... That's why it's deprecated - it's easy to perform additional safety checks if you include both the source and destination sizes.
Re:No - there are plenty of safer alternatives (Score:2, Interesting)
Re:Shooting themselves in the foot. (Score:4, Interesting)
Actually, memcpy in and of itself is slow. Hand writing your own asm version of memcpy using extended cpu functions is a lot faster as memcpy itself is usually kept basic enough to work on any cpu, including the older cpu's without MMX, SSE, etc.
glibc contains specific implementations for sparc32, powerpc32, powerpc64, i386, i586, cris, i860, rs6000, and m68k. I don't know where you got your idea.
Re:No - there are plenty of safer alternatives (Score:4, Interesting)
>Or, better yet, if security really was the goal, develop a C-like language that was secure by design?
Or, better yet, if security really was the goal, use Ada.
There, fixed that for you :o)
Re:No - there are plenty of safer alternatives (Score:4, Interesting)
So why is strncpy in the banned function list?
Because strncpy() is as bad as strcpy(). The problem lies in the fact that if the source string is longer than the destination len, then strncpy simply stops the copy without writing a NULL. The next str* function used on the string is likely to crash.
Please ban them (Score:3, Interesting)
(I have 20+ years proffesional programming experience, a good chunk of it in C/C++, and in recent years have spent a lot of time debugging other peoples code, especially ported, re-ported and generally hacked around code !)
IMHO a lot of the posts here are missing the point when they say, "these functions are safe, you just need to check the size before hand" etc. The fact is, in the Real World, not everyone is an ace-programmer, deadlines loom, mistakes get made. Problems do not appear in testing, but can further down the line. IMHO a language simply should *not allow* the programmer to do crazy things. Potential buffer overflows, de-referencing null pointers etc should not get past the *compiler*.
To be honest I do not have a prefered language to suggest, but I do not think that tweaking C is the answer, but better, high level, languages are needed.
Re:Please ban them (Score:2, Interesting)
Thank you for a sensible post. I agree that the only real solution has to be some abstraction or alternate mode for memory access that prevents the problem outright. C and C++ not only make it possible, but extremely easy to trash memory.
The people claiming that the problem is programmers who are incompetent or stupid and believing that they are superhuman genius programmers who are somehow immune from errors are living under a delusion. You are not a beautiful and unique snowflake. We are all human and imperfect. I have seen many intelligent and competent programmers write incorrect code. I have personally written code with errors. We need to move beyond unproductive blame assigning mentalities to achieve real solutions or we will never be able to advance the state of software. Realistically, the prima donnas will continue on and other people will actually do something.
memcpy_s is not a step forward for numerous reasons already mentioned. strncpy provides functionality that strcpy does not, namely a bound on its region of effect. memcpy was already bounded and neither memcpy_s or strncpy can prevent bad parameters from causing memory corruption. Hardware support like the NX/ED bits to mark pages as not executable are a good advancement on the security front, but still do not prevent data corruption. Complete removal of memory access like many languages do solves the problem with a high performance cost. Emerging techniques like STM may be able to incorporate data safety while maintaining hardware efficiency.