Unsafe at any speed: Memcpy() banished in Redmond

Memcpy() and brethren, your days are numbered. At least in development shops that aspire to secure coding. Microsoft plans to formally banish the popular programming function that's been responsible for an untold number of security vulnerabilities over the years, not just in Windows but in countless other applications based on …

[Kevin McMurtrie]

Can't fix C hacking

If the code was written properly, there'd already be bounds checking on the memcpy() count parameter. The real problem is that C can't associate sizes with pointers by itself. There's nothing to stop coders from using memcpy_s() with the wrong destination size, be it accidentally or intentionally. It will still crash the same way it did before.

[Jach]

Problem with the coders, not the language

Banning parts of a language because they could be dangerous or used unsafely is frankly ridiculous. It's a reason Java doesn't have real operator overloading and multiple inheritance. It's a weak argument people use to bash PHP (because it's easy to pick up and lots of idiots who shouldn't be programming in the first place use it).

[jake]

Whatever.

C is a low level language, one step up from assembler. Some of us like C because of that. All this article tells me is that Microsoft (and others, not picking on MS specifically) employs a bunch of low-cost kids with no coding street-smarts to do the "dumb heavy work" making up the bulk of the code ... which in turn explains the crap code that pervades today's world of home computing.

It ain't t'language, lad, tis t'lad using t'language. (Or the t'Lady, with respect to Miss Bee.)

[jf]

SDL turns out to be a list of banned APIs and a lot of useless rhetoric

Repeat after me, Banning APIs does not fix the underlying problem, Banning APIs does not fix the underlying problem, Banning APIs does not fix the underlying problem.

As someone who has had the chance to read a lot of proprietary code the problem is largely more or less what Kevin said-- theres nothing to stop you from using the wrong destination size. Only *one* team I've seen use the API correctly, everyone else does-- well exactly what ATL does in the following screen shot: http://www.innocence-lost.net/atl-generated.jpg.

[Kevin Whitefoot]

Why is buffer overflow a problem?

Surely the operating system and the hardware can allocate space in such a way that data buffers are not executable and that the code of a program is not writeable. So why is this still a problem? Isn't the ability to mark memory blocks with flags controlling these things supposed to be a feature of proper operating systems and processors? I have vague memories of reading many years ago about the memory management features of mainframe computers that mention things like this. See also http://developer.amd.com/documentation/articles/pages/3312005143.aspx for instance.

[Glen Turner]

Cheap rhetoric

Last time I checked Linus wrote a kernel, not a C library or a compiler.

[Mike Pellatt]

Nitpicks

memcpy() et al aren't "commands" , they're "functions"

Neither are they part of the "C" language - they are part of the "C" run-time support library, and these function calls aren't defined by the "C" language

[Ben]

They should go one better...

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

[Tom]

wrong thing to ban

#include win*

or its equivalent in any language until MS unequivocally states it will not try to own any of your code at a later date.

[F Seiler]

new size parameter ..err, what?

The memcpy i used so far has always had three parameters - destination, source AND number of bytes to copy.

How will adding *another* size indicator help avoid buffer overruns ? If the programmer was wrong in specifying a proper and safe bytes-to-copy parameter, are the chances really any larger to get it right in a second guess ;)

*note: memcpy is distince to the basic strcpy et co in this. Vanilla strcpy does *not* take a paramet specifying how much to copy, in the hope there will be a '\0' in the source before the destination buffer overflows. strncpy cures this.

[Tam Lin]

In actual usage, however ...

int foo(char *inbuff)

{

char buff[12];

char ams[] = "Ai'nt microsoft smrat?";

/* Specifying the source size twice makes us mostest secure */

memcpy_s(buff, sizeof(ams), ams, sizeof(ams));

or

/* This error logic you've seen before. */

if (memcpy_s(buff + 32, sizeof(buff), ams, sizeof(ams))) printf("Disk full");

finally;

/* Caller allocated inbuff based on available RAM; We *KNOW* it's big enough, but we don't know its exact size. This fix allows us to kill warnings.

NOTE: already tried memcpy_s(inbuff, sizeof(inbuff), ams, sizeof(ams)), it didn't work for some reason, probably another compiler bug */

memcpy_s(inbuff, 999999, ams, sizeof(ams));

}

Kevin is right - of course it will "work" in certain cases. In those cases it has probably been implemented thousands of times already (likely as a macro). But replacing the original memcpy() gives a misplaced and dangerous sense of security where none actually exists.

In order to understand the strcpy/strlcpy strcat/strlcat benefit, you first have to understand why and how it works, then you have to follow the rules. But buffers don't have rules, and slapping on another size parameter for security is like slapping a non-matching fake chrome exhaust pipe on your ricer to make it go faster and sound better. So, yeah, Linus and DrPepper probably will pick it up.

[Torben Mogensen]

It's a start...

But I have to agree with Kevin that the core of the problem is using C, which checks nothing at runtime at not enough at compile time.

An alternative could be Cyclone (http://cyclone.thelanguage.org/), which shares a lot with C but has advanced features don't have and, more importantly, avoids many types of safety holes and bugs caused by C's lack of checking.

C# is also better than C in terms of safety and features. Microsoft is already using C# for a lot of things, but it is tied strongly to the .NET platform, so it can't be used for generic Windows programs or operating system modules. And for .NET, I would choose F# over C# any day.

[Maksim]

This is insane

What's up with this trend of 'making life easier and safer'? If somebody wants to use safe alternatives - fine. But why do we need to _force_ people out of fast low-level stuff?

It's like 'yeah, you know, 99% of the programmers are idiots, really, who can't be trusted with dangerous stuff'. Only in ten years time there won't be anybody who can program your framoworks, libraries and OSes at all with that approach. Things are bad enough as it is, nine out of ten candidates whom I interview already do not know how computer works.

Arrrgh!

[Ru]

You can't stop a determined idiot

I note that openbsd did similar things by mandating use of their strlcpy and strlcat functions in the kernel instead of the usual strcpy and strcat, but still leave the old versions of the function available to ease application porting.

It helps that they have significant amounts of buffer overflow and stack smashing protection enabled by default in their version of gcc, significantly reducing the risks of an overflow.

[raving angry loony]

A.F.T.

I'd just like to say one thing.

About. Fucking. Time.

You'd think by now they would have written an appropriate bullet-proof wrapper for the function. I'm frankly shocked they haven't already done this, and the fact that they haven't explains so much about the lack of quality of their products.

[Anonymous Coward]

"It's a question worth asking"

No it isn't a question worth asking. It's entirely possible to use memcpy safely, just as it's entirely possible to use memcpy_s (etc) wrongly.

Does the author or the people making these suggestions have any experience of Bill's current family of _s "improvements"? They're rubbish.

Why should slightly changing the name and the calling sequence turn carp programmers and carp designs into safe programmers and safe designs?

Only a poor craftsman blames his tools, and programming is a craft not a science.

What a daft concept, what a daft article.

[Andraž Levstik]

Hmmm what does Linus have to do with this?

He has the kernel... not the C library(glibc). And this sounds like part of the C library not the kernel...

Or do you mean not using it in the kernel?

[Anonymous Coward]

@ Kevin

Read the article mate (also why the ms hate?)

Its to do with security, nothing to do with crashes, basically saying its a lot harder to cause security issues with the new function so use that instead.

[Anonymous Coward]

Wrong approach

You cant rely on the compiler or new functions to make your code secure. The only way to make code secure is to really understand what you are doing. Replacing memcpy with memcpy_s is silly and only leads to a false sense of security.

[Alan Jenkins]

Is this a joke?

Yeah, the FA is pretty clear it doesn't make the operation any safer - it's more about forcing the programmer to consider the destination buffer size.

Also, it's a nice way of saying "to achieve this certification, you must audit all your existing memcpy calls", in a verifiable way. Again, it's easily bypassed by

sed -i *.c s/memcpy\((.*), (.*), (.*)\)/memcpy_s(\1, \3, \2, \3)/

but if you're really that short-sighted, there's nothing that could help you :-).

They seem to be missing a trick though. You should also be looking to try and replace memcpy() with structure assignment. Most C programmers don't even realise you can do that.

Incidentally, C99 does have support for array _parameters_ with an associated size. I think the syntax is "char a[*]".

[Neil B]

Ultimate Solution

# pragma deprecated (The C Language)

[Paul Clark]

memcpy() is already bounded

I don't get this at all... The problem with strcpy() which causes so many overflow vulnerabilities is that the amount copied depends on the unpredictable C-string length of 'src', but memcpy() has an explicit length. Allowing that length to be greater than the size of 'dest' is sheer stupidity, not just laziness, and memcpy_s() won't protect you from that.

But who in Microsoft other than kernel/driver folk (who ought to know better, and who will resent the redundant comparison) is working in pure C anyway?

[jeffrey]

Well

If people use memcpy properly in the first place it wouldn't be a problem

[Anonymous Coward]

This is evidently another MS error.

System time on their publicity machine must have been reset to April 1st.

The comment by Kevin McMurtie is quite correct, you'll still be able to break things in the same way as before by passing dodgy parameters to memcpy_s()

They could declare a structure which began with a pointer and which then held the length of the data in bytes. Passing the structure (overridden natch) to any function would work and they could keep a count of the size of the data the pointer was looking at using the other variable. That might help...

A more sensible step for MS to take might be simply to hire programmers who knew how to use pointers. Oh, and if their developer turn-around wasn't so high, they'd have developers who were more intimiate with the code which would mean less bugs (of any type) would slip through.

...it goes without saying (so I'll say it anyway) that if their OS was more than a patch fix on a bug fix on a pile of half-arsed cludges they'd get on better anyway. Isn't it about time they got rid of the biggest flaw in their code - the design (or lack of). I'm talking about things like the registry... it's a joke.

[Neil Barnes]

Extend, embrace, extinguish...

I assume that MS have at least *heard* of K&R? Perhaps they'll be banishing the assembler next on the grounds that you can do anything...

Hopefully, #define _CRT_SECURE_NO_DEPRECATE will continue to work?

[M. Poolman]

title

memcpy(dst, src, sizeof(*dst))

might help. Better to use abstract data types with dedicated copy functions. If done properly problems like this will be manifest at compile time, not run time.

JM2CW

[Andrew Moore]

Sheesh

Who does unchecked memcpys?

Oh yeah, Microsoft programmers...

[alain williams]

How will an extra parameter help ?

The 3rd parameter is the number of bytes that you want to copy, so having another size ... what does it add ?

[lennie]

they're thinking ahead

@kevin: well at least they're trying something. its better than doing nothing don't you think?

[Dave]

Size?

Last time I looked, memcpy has a length parameter, unlike strcpy. Admittedly it's obscured by the size_t so there's a bit of brain work required to convert to bytes for real buffer size, but it's there. I assume the new function has an explicit check (i.e. slower) to accomplish the same thing at runtime but can still be broken by a programming error in specifying buffer size.

[Critical]

What?

"The command is already supported in Microsoft's Visual C++, but according to Ullrich, native support doesn't yet seem to be available in the GCC compiler."

What's it got to do with the compiler? memcpy and friends are in glibc.

If you don't want people to call stuff insecurely, you need to train them to go about development in a considered manner. Just passing the destination size is not good enough to prevent buffer overflows, as it still relies on the programmer passing the right size.

If people aren't willing or able to think about stuff at that level, then they're better off using a higher-level language that would provide more safety anyway.

[Mark Wills]

Hmmm.....

"Its drawback comes when the source to be copied contains more bytes than its destination, creating overflows that present attackers with opportunities to ...."

Hmmm,,, I think that's the symptom, rather than the cause.

There's nothing wrong with memcpy(). It reads a word from a source, and writes it to a destination, decrements a counter, and continues if the counter !=0

In other words, it does what it is supposed to do. The problem is that programmer did not bounds check before the memcpy was executed.

A simple if block around the memcpy is all that's needed.

Mark

[Anonymous Coward]

memcpy ain't the only way of writing to memory

If you want to trash some memory, C provides endless ways of doing so. Anyone who thinks banning memcpy() will solve their security problems is fooling themselves.

[Anonymous Coward]

What I don't see can't harm me

And what do they imagine is happening inside the code that they're too detached from the detail to know about?

Bulk memory shifting!, and you'd better be doing it with memcpy that uses the correct processor instructions because doing it in a loop is slow and crappy and incompetent and no more secure.

This is what AMD sued Intel for making their memcpy slow, and why processors have instructions built in to do it:

http://www.amd.com/us-en/assets/content_type/DownloadableAssets/AMD-Intel_Full_Complaint.pdf

Code is like sausage, if your sausage is crap it's better to not know what's in it, and kid yourself it's grade A meat. Redmond produce a lot of this kind of sausage.

On the other hand the best sausage comes from the people who know what the pig that went into it had for breakfast.

[Jonathan]

Stupid question...

I know that Steve refers to Steve Jobs of Apple and Linus refers to Linus Torvalds of Linux. Who does Larry refer to?

[Anonymous Coward]

Re: Can't fix C hacking

I guess you didn't actually read the blog (or, maybe you did and are trying to look clever!)

From the blog:

"Of course, you can easily make a call to memcpy_s() insecure by getting the buffer sizes wrong. The following code is no better than memcpy():

memcpy_s(dst,len, src,len);

You’ve been warned!"

...

[John Smith]

"notoriously dangerous C commands"

Perhaps that should read "Notoriously dangerous stdio function library calls."

IIRC there are safer more restricted versions of memcpy which have safety built in. They are also part of the stdio library.

But maybe using them would demand too much thinking time when a release date is looming.

I'd love to see some stats on this in live code, like Windows for example. And how many of those could actually be banished by a replacement macro IE where the unlimited nature of this function is not actually necessary.

Thumbs up as better late than never.

[Andrew]

You know what will happen...

What, my code doesn't complie? Hmm....

#define memcpy(dst, src, sz) memcpy_s(dst, sz, src, sz)

Problem solved.

[Anonymous Coward]

This is insane

Anyone clueful will already be checking the amount you're copying (the "count" parameter to memcpy()) fits in the destination buffer before making the call. So there is no advantage to these new functions.

Similarly for many of the other functions which they've already "deprecated".

This is just another Microsoft attempt to fragment the C and C++ languages, so people writing for Windows write in Microsoft-only "safe C" rather than real portable C. This makes it harder for people to write cross-platform applications, or to port their apps from Windows to Linux/Mac. And they get to spin it as "Microsoft caring about security!" too.

[Anonymous Coward]

Obviously...

..we wouldn't want people learning to program properly would we.

[Andrew]

Security Theatre

This seems fairly pointless. The reason strcpy is dangerous is that the number of bytes which it attempts to copy, is not specified by the calling function at all - rather it is determined by the contents of the copied memory. Whereas memcpy always copies exactly the number of bytes that the calling function anticipates. I'm not sure there are many cases in which this will crash where memcpy_s would have helped?

[Eddie Edwards]

fopen_s

I get memcpy_s but wtf use is fopen_s? That function doesn't write to the string buffer.

Bored of that VC warning about this stuff. Esp. with clients that *insist* that warnings were always *actually* meant to be errors. Yay for breaking all legacy C code!

[Anonymous Coward]

@kevin

I'd have to agree, the destination argument is irrelevant.

The proposed M$ fix is not really that helpful as it both makes the code non-portable (completely by accident I'm sure) and doesn't make it any safer as the above poster explains.

A much better way is to arrange that your calls are truncated at the limit of the

destination buffer using the sizeof operator, hence allowing the compiler to "associate sizes with pointers".

It's portable, pure ANSI and works a treat.

void

my_func(FOO *dest, BAR *src)

{

memcpy(dest,src,sizeof(dest));

}

TTFN

[Joe Montana]

WTF?

the memcpy function already has a parameter to specify how many bytes to copy:

void *

memcpy(void *dst, const void *src, size_t len);

Destination, Source, Length...

If you add a 4th parameter, people will just put the length parameter twice, so if the specified length is wrong then it's wrong.

[David Hicks]

Leave my C alone!

C is a beautiful, wonderful language that sorts the men from the boys and no mistaking.

Sure, there are other ways to get things done quicker, but when you absolutely, positively have to squeeze every last ounce of performance out of something, well, there's no other way to go (except assembly and maybe C++).

Yes, you can shoot yourself in the foot, or the head, with ease. But that's what makes the language so flexible. Take away my ability to treat everything as a piece of memory filled that I can stomp all over as I like and you take away some of my power to make things go fast.

[Anonymous Coward]

Notjing to do with C

I agree with that. memcpy can be called from within even VB. Its an adjunct.

Anyhow, its stupid to ban these things. More annoyance and intrusive "warnings" from MS who regard us as if we're all slightly backward children who can't be trusted with sharp things.

[Jason Bloomberg]

Next step, ban pointers

There comes a point, if you are having to curtail programmers from doing something potentially damaging, where you have to consider that you are perhaps using the wrong programming language, or the wrong programmers, or both.

That said, this isn't a bug or problem with C itself but in the libarary. Even then it's not really a bug or problem, only when it's used improperly does the issue arise.

C allows plenty of damage to be done and it amazes me that it has gained such widespread acceptance. It is used in many circumstances where programmers would be better off using something else. Industry only has itself to blame for using the wrong tools for the job.

[Ken Hagan]

An own goal

Microsoft tried to get this through the ISO standardisation process. They failed, because there simply isn't any benefit in asking programmers to write an argument twice. Clearly they didn't learn anything from the experience.

This affects no-one outside the Microsoft campus. It won't improve security. It will simply reduce the portability of their code and make them less able to import code written by others. Fine. It's your funeral.

[Anonymous Coward]

Why is everyone moaning about it not helping

The blog shows a suggested way of doing it , and a way that would be just as insecure. If you still do the insecure way when theres something in there to help avoid errors and overflows then your the idiot not MS :P

P.S. Can't el reg just do something to auto convert M$ to MS , would help make your readership look generally less retarded.

[Dan]

So what happens with the super-safe version of memcpy?

You truncate the source data into the destination buffer then something else somewhere else in the program either can't make sense of it or goes through the data with a pointer and gallops off into the sunset as the data terminator didn't get copied across or trashes the stack or causes a page fault or etc...

I think the best idea would be knowing how to program in the first place...

[Mo]

@sed gawk

Er, I think you want sizeof(*dest).

Unless you're only planning on copying the same number of bytes as make up a pointer to FOO.

[Anonymous Coward]

@You know what will happen...

I'd much rather see

#ifdef _USE_SHITTY_MS_MEMCPY_S

printf("Ha ha - you\'re using C++ for dummies. I bet you live with your mum and masturbate over MMPORPGs.\n");

memcpy_s(dest,sz,src,sz);

#else

printf("Clever boy (or Ms Bee), you\'re not giving in to the creep of idiocy into low level languages. I bet you even use inline assembly here and there. We should chat over a drink.\n);

memcpy(dest,src,sz);

#endif

Even if I did use VC I can guarantee I'd undef that (or its equivalent!!)

[Jon]

Re: Stupid question...

Larry Wall (perl) I should imagine - not sure what it's got to do with him either...

[Rich]

OpenBSD

OpenBSD addressed this years ago. Nice to see the rest of the world finally catching up.

[Anonymous Coward]

@@kevin

"A much better way is to arrange that your calls are truncated at the limit of the destination buffer....memcpy(dest,src,sizeof(dest));"

Careful sed, that code will fault if the source buffer is too small and the source is at a page protection edge.

Although, yes MS's fix does not fix that problem either, and worse it introduces a partial-copy failure where a truncated buffer is copied when a full one is expected,.... a bugger to find, leading to some subtle fault in future. I'd prefer it to fault as it does when you do bounds checking in debug mode and miscalculate your buffer size.

There is no substitute for calculating the length of your buffers correctly and this is just security theatre for middle managers.

I bet a bunch of middle managers wanting to look busy to avoid being sacked, will now be rushing around to get code changed to be compliant without understanding what they're doing.

i.e. it's just a __min, and if the size of the buffer is calculated correctly then adding the second parameter can only make it incorrect, it CANNOT make it MORE correct. i.e. changing working code can only break it since there was nothing real to mend.

#define memcpy_s(dst,src,sizedst,sizesrc) memcpy(dst,src,__min(sizedst,sizesrc))

[Stephen Channell]

iAPX432 and all that

Surely the whole point of the additional size parameter is to allow the function implementation to find the header block in the heap memory manager (which will hold address and size) and verify that the buffer is big enough for the size of the source.

memcpy_s looks daft when the two size_t parameters are the same.. but if the element-count is 20, half way through a 2^20 buffer.. passing the actual buffer size gives a *hint* to the heap manager (especially LFH) to find the header for checking..

BUT WHAT’S THAT GOT TO DO WITH THE TITLE?

macho posturing about the safe use of pointers and stupid programmers misses the real point which is about safety of running application code (some software gets to kill people when it fails).. and how you verify at runtime whether some code is fit to run in a safety/security sensitive environment.

Ultimately we’ll want hardware support for all this safety checking.. and that is when Intel will dust of the spec for the iAPX-432 “Ada processor”.. and we’ll ALL regard memcpy in the same way we now regard 2-digit years in COBOL programs

[Richard]

Tchah

Treating the symptom and not the disease, I'd say.

[Anonymous Coward]

@sed gawk

> void my_func(FOO *dest, BAR *src) {

> memcpy(dest,src,sizeof(dest));

> }

Sheesh. sizeof(dest) is either 4 (on 32 bit machines) or 8 (on 64 bit machines).

The memcpy_s() this safe-coding theatre.

Buffer overruns happen with non-terminated strings, over-long strings, off-by-one arithmetic and generic WTF programming.

The first two come from sloppy coding: What do you mean you trusted the user to be reasonable? Validate input, use fgets() not gets(), assume the user or machine at the other end of the connection is out to get you.

Off-by-one arithmetic errors (and their closely related ilk) are common programming errors. Is "memcpy(foo+32, bar, sizeof(foo)-32); foo[sizeof(foo)] = 0;" correct? How many errors apart from the intentional one? memcpy_s() won't help this one jot. It'll mean you need to know the size of bar so you're not copying garbage, but it won't help any with the common problem.

WTF errors are where the author had total brain failure at the time the code was written. It works in the common cases and fails spectaularly in the very rare cases. memcpy_s() and similar "safe" functions don't help at all either.

Safe code doesn't come from "safe" programming languages, it doesn't come from "safe" functions, and it doesn't come from well-meaning draconian edicts. It does come from people who have been taught how to write safe code and if you expect people who have been taught by being given an "avoid" list then expect the worst.

I'm eternally glad I'm in a position to fix Linux problems and that I don't have to use Windows at all.

[The Fuzzy Wotnot]

Labour strike again!

<Daily Mail mode on>

It's the nanny state gone mad! Political Correctness gone mad!

If someone wants to shoot their slav...servan...ermm...housekeeping staff, he should be allowed to!

Same applies to computers, if someone want so do something stupid, they should bally well allowed to! I didn't fight in 6 world wars for this government or any other to dictate what I can and can't do in my own country!

[Dr. Mouse]

Simple solution

If you are a programmer, use C, check your work, acheive fast, efficient programs.

If you are a script kiddie, use a language which checks everything for you.

Seriously, although everyone makes mistakes, this is just indicative of the dumbing down of society. It's like the warning lables on coffee cups at starbucks et al, saying "Contents may be hot." IT DAMN WELL BETTER BE IT'S COFFEE!!

That warning should be replaced by a standard notice on the door saying "If you are an idiot, do not enter." Similarly "If you are not a competent programmer, do not use C"!

[Anonymous Coward]

@Mike Pellatt, re: Nitpicks

> Neither are they part of the "C" language - they are part of the "C" run-time support library, and

> these function calls aren't defined by the "C" language

Well, actually they are defined by the language. Section 7 of the ISO C spec defines the C runtime library and the functions that it contains. Memcpy is one of those functions. (And section 7 is in the normative part of the spec.)

But many of the functions in libc are not defined by the language, e.g. open(), close(), read(), write(), socket(), bind(), connect(), etc. Perhaps this is what is confusing you?

[Simon B]

Error checking anybody? ffs how difficult is it!

"Its drawback comes when the source to be copied contains more bytes than its destination, creating overflows" Dumb ass who invented this language then, never heard of error checking? WTF can't C- - go "source file" meet "destination", is destination big enough? yes? carry on! no? sorry, can't do that. Not fucking brain surgery is it. Why is it simple things called error checking are never part of programming languages?

[Anonymous Coward]

@sed gawk

You've allocated a large destination buffer to copy into. => Performance degradation

You're copying to an offset of dest. => Buffer overflow

Use Scala. End of . :D

[Anonymous Coward]

@Ultimate Solution

Not so - a better solution:

# pragma deprecated ( people who don't know what they are doing )

# pragma deprecated ( code not tested sufficiently for its intended environment )

Language choice can then be determined (more intelligently) by other factors (e.g. libraries, frameworks, toolchain, available skillsets ...).

[Francis Fish]

There are a ton of 3rd party libraries that make things safe

As in, you don't call memcpy any more but use the library wrapper, they do runtime checking that prevents buffer overflows and array out of bounds.

Plus there's a C++ smart pointer library that does the same thing for pointers.

Serious people doing realtime stuff have always used these tools.

WTF haven't MS (and Oracle used to have lots of this in their database too too, and probably still do) licenced these libs (cost wouldn't even raise a ripple on their bottom line) and saved the rest of us lots of problems? Because they are marketing/sales driven and probably wouldn't let people spend on the tools. Sun and HP probably do use them, being engineering companies who understand engineering.

Also real programmers put "assert" in really critical places (oh, flame war!!!)

[Anonymous Coward]

A question worth asking?

'It also wondered aloud when "Larry, Steve, and Linus" plan to issue similar security edicts in their products. It's a question worth asking.'

Is it worth actually asking if Dan understands programming?

This is not a "security edict". Its MS just trying to fool people into thinking that they are fixing a problem caused by sloppy programming.

Of course telling your programmers not to be lazy and not to write sloppy badly put together code would be too simple wouldn't it.

[Andy Davies]

@Kevin Whitefoot

Well said.

I don't know enough C but I know enough programming:

this is a function, a function returns a result

<pseudocode>

result = mycopy(aa, bb)

if result = BUFFOFLO ...

# or if you prefer:

try

mycopy(aa, bb)

catch BUFFOFLO

# etc. - make up your own syntav

</pseudocode>

Oh, and anyway in the higher level languages I've used src is truncated if longer than dest

AndyD 8-)#

[Anonymous Coward]

"I bet you even use inline assembly here and there ..."

" I bet you even use inline assembly here and there"

Like, is there anything wrong with that as well? Clearly, the whole world has changed around me completely and no one has bothered to tell me.

All these so-called "new rules" and restrictions in the world of programming. My, my. Who'da thunk it?

If people haven't the balls to tackle concepts like memcpy, strcpy or pointers, do the world of programming a favour and get a job in McD's. Or better, teaching IT to those poor tragics doing these new-fangled "computer science" degrees which I keep hearing about.

I blame the parents.

[Hayden Clark]

Outsource the porting work

... this will ensure that

int getDataIntoBuffer(socket * src, void * buff)

WON'T get changed to

int getDataIntoBuffer(socket * src, void * buff, int bufLen)

and ALL the structures that contain buffer pointers WONT have corresponding buffer lengths added.

and whenever a buffer is reallocated ALL the buffer length values WON'T get updated.

If you've underquoted for the work - you'll just be memcpy_s(src,len,dst,len)'ing with the best of 'em.

Oh yes.

And then we download the new secure "patched" version.

[Anonymous Coward]

@Error checking anybody? ffs how difficult is it!

"how difficult is it! "

LOL You don't really understand much about C or C++ do you? And btw its got nothing to do with files....

[Anonymous Coward]

memmove

Funny they forgot that one...

[Michael Brown]

Use Java

End Of.

[Joe M]

Competent; 2: having requisite or adequate ability or qualities

Anyone who cannot copy memory precisely, using whatever language or library, should not be programming a computer. Moving data around IS programming. If you can't count you can't program.

If you can program, you can program in any language. If you can't, giving you Java or Lava or Shmava to hack ain't gonna help. If the compiler and runtime have to babysit you because you can't be trusted to count to 255 (or was that 256?) what the hell are you doing there anyway.

Overall I am sick and tired of people blaming languages for all the problems of the world. The problem is people, people.

You can either program or you cannot. My reading of the industry is that less than 10% of professional programmers are properly trained and understand exactly what they are doing, and about half should look for other avenues of employment. (I know this because along the way I employed a few of those by mistake.) Not a pretty picture.

That's the real reason why we have things like “buffer overflow” exploits, a problem which should have disappeared about a month after it was raised as a security issue, and did so for competent programmers. But the code jockeys still don't get it! (Hint: It is 256 after all! And add one for good luck.)

Microsoft adding one more idiotic restriction to try to reign in the cowboys is about as useful as trying to market edible condoms. ( It's late, I'm tired, I couldn't think of anything else and condoms are in the news here in .au.)

@Jake 05:26 GMT

You are not quite correct. I dealt with some MS programmers a while back in Redmond and they were not kids. They were exceptional software professionals who knew exactly what they were doing. Microsoft doesn't get it wrong because of the technical people it employs. Try taking pot shots at the marketers, hype merchants, slimy strategists who want to control the world and the other cheating, lying swine up there.

@Torben Mogensen 07:14 GMT

“But I have to agree with Kevin that the core of the problem is using C, which checks nothing at runtime at not enough at compile time.”

It's not a C problem Torben. One uses a language as given. A good programmer understands the strengths and limitations of the chosen language and gets on with producing a safe, functional, tested product.

@James 20:43 GMT

“The only real solution to real code stability and security is to stop using insecure languages and ensure people you employ are competent enough to fully understand the implications of *every* line of code they write.”

James, there is no such thing as an “insecure language”. There are however “insecure programmers” who do not understand the implications of what they are doing.

[IndianaJ]

Who does Larry refer to?

Why, Larry Hagman of course. aka JR from Dallas and also, incidentally, inventor of the semi-colon.

[Arthur Klassen]

Quick! Someone lock the barn door!

Never mind that the horses have all found a bunch of loose planks out back where they can get in or out at will. The only one inconvenienced by Yet Another Lock is... the farmer.

A classic case of learning the wrong lessons from history.

cheers...ank

[Michael Nielsen]

Sigh

The reason there isn't checking done in memcpy, and related programs, contrary to the "safe" languages is that there is a huge performance hurdle, when you can end up running nearly double the amount of instructions that are to be fired off.

If you add a small amount of overhead, in very basic and fundamental building blocks, you will end up multiplying that overhead, by millions before you're finished, resulting in a huge performance overhead.

In the name of safety and efficiency, new "Safe" programming languages are invented, the resource usage increases many times, as well as the over head - virtually all in the name of safety.

Though the time to write a program is somewhat decreased, the performance is not increased as much as the physical machine performances would indicate.

Thus the idea of taking low level functions such as memcpy and adding overhead, is going to negatively impact the system upwards, I really doubt it's going to solve the problem.

Essentially memcpy(dest,src,size) is a more efficient implementation of

for (i = 0; i < size; i++) {

*(dest++) = *(src++)

}

so what is the extra parameter going to be, a pre check, on the size ? Additionally the memcpy_s is not going to prevent programming errors, as there are so many ways of doing it.

The original idea was here is an efficient way of copying memory, but be careful with it, you need to know what you're doing. This means that the functions you use, won't add overhead to the system, only the programmer will do so.

Safe languages add massive overheads inside the language, in addition to what the programmer adds - thus sluggish and slow programs.

[Anonymous Coward]

@Greg Fleming

Read my fucking post you idiot - I was congratulating the programmer who had the sense to use the real memcpy rather than wimping it up with microsofts memcpy for babies.

Clearly there's nothing wrong with using inline assembler - I love it.

Learn to read - I'm a little worried you program, given that you have the inability to read a simple enough piece of code!!

[Sarah Bee]

Re: @Greg Fleming

Alright, AC, cool your boots a little please. It's Friday afternoon and I'm sure we would all like to coast weekendwards with the minimum of aggro.

[Anonymous Coward]

@Kevin Whitefoot re "why is it a problem"

You're starting from the right place but you haven't got the full picture.

Data execution prevention and related technology means you can't execute a piece of memory which is marked (by the OS and memory management) as data.

But what about things like return addresses on the stack? They're not instructions, but they control where the program goes. A suitable exploit (in the "stack smashing" (??) class) consists of finding a return address to overwrite, together with a piece of writable storage into which you can write the exploit payload and then execute it by clobbering the return address appropriately. If you don't fancy return addresses, how about pointers to functions, which are relatively widely used in C++ virtual functions and other such trendy/clever stuff.

There are other variations but that's the basic way you turn the class of error called buffer overflow (which might otherwise just be an inconvenience) into an actual exploit. Lots of OSes have these kinds of errors and exploits, in fact even VMS was shown (at DEFCON 16) to have one in this class not too long ago, much to the amazement, nay disbelief, of the faithful.

Crap article though.

[Anonymous Coward]

@Why is everyone moaning about it not helping

The answer to your question is, "Because it doesn't help". See, this ...

> " The blog shows a suggested way of doing it , and a way that would be just as insecure. If you still do the insecure way when theres something in there to help avoid errors and overflows then your the idiot not MS :P "

... is exactly what we already have with memcpy anyway: it can be done in any number of "suggested" ways that are safe, or you can be an idiot and do it an insecure way, and guess what happens?

The exact same will happen with memcpy_s as happens with memcpy. Therefore it makes no difference and doesn't help.

[Anonymous Coward]

Patents

Golly, I sure hope Redmond doesn't try to patent this important security breakthrough; for which no examples of prior art exist. That might make it "impossible" to write "secure" code.

[Anonymous Coward]

Re:Re: @Greg Fleming

Sorry Sarah, I didn't mean to get quite so riled up. I've had a terrible week and I'm not entirely sure what is stopping me from pouring the gin I have in my desk drawer into my tea. It is after all only 90 minutes from official pint time.

In fact having had a direct response from you has cheered me up no end (not in a sexual way you understand - you're too lacking in the penis area for me. At least that's what I think...?)

[Anonymous Coward]

@ AA Tuesday 12th May 2009 12:24 GMT

I wasn't actually picking a fight with you AA (not at all in fact) its just that this particular quote has in fact been leveled at myself and others and I can't fathom why its anybody's concern. As you would see I wasn't @AA I was @ "I bet you even use inline assembly here and there ..."

Perhaps I should have qualified that a bit better.

If certain programming practices are frowned upon by others then its rather like picking a fight over shoe colour.

Anyhow, I'm not a "fucking idiot". I've been at this game for 26 years and have learned a few cool tricks along the way. I'm bemoaning the fact that programming is suddenly considered dangerous, Like everything else these days.

Sheesh. I don't pick fights. Take a stress pill and chill, bitch.

[Sarah Bee]

Re: Re:Re: @Greg Fleming

Ahh, you can resist the gin if I can continue to resist the biscuit Lewis has put on my desk. And it is nearly the weekend.

Maybe I should try this approach more often. Fluffy goodness and nicies for all!

[Doug]

The Safe C Library

"The Safe C Library provides bound checking memory and string functions per ISO/IEC TR24731. These functions are alternative functions to the existing Standard C Library"

See safe_lib.h .. of Dr. Dobbs Feb 2009

http://www.ddj.com/cpp/214502214

This reminds me of when Microsoft patented SUDO ..

http://taint.org/2004/08/20/024522a.html

[Anonymous Coward]

@Andy Davies: "I know enough programming"

"I don't know enough C but I know enough programming:"

The pseudocode which follows shows that, whatever your other skills may be, you know just enough about this kind of programming to make yourself look very very very foolish in front of people who do have a bit more of a clue on the subject at hand.

Your post also shows that you don't even have the common sense to realise you're perhaps way out of your depth and should therefore probably post as AC. Are you in line for a management job by any chance? Or maybe a Microsoft Certified person of some flavour?

I'm not even going to bother trying to explain how badly you've misunderstood the concept of a buffer overflow, as I need to be somewhere else before Christmas; if anyone else wishes to, good luck to them.

Have a good weekend; perhaps you could spend a few minutes of it reading about what a buffer overflow really is.

[Josh]

When will Linus, Larry, and Steve issue similar Edicts? Anwser: NEVER

They don't need to. Unix type OSes have exception handlers that don't let buffer overflows and the like compromise a machine like they've been doing on Windows since Win95 at least.

[Dustin]

WOW! There are some ignorant smart people making comment here.

I am no programmer, even with some scripting experience. One thing I noticed about the comments here was the fact that many of you are not realizing that banning the function at the compiler level, enforced with a warning, is not the same as disabling its functionality. This is identicle to having a service not installed or port listening after a clean OS install. Its precautionary. Where is the uproar over not having FTP running on a server a first boot? You can install it later if need be. If 95% of coders out there are lazy and unknowledgeable about proper coding and this is giving MS is bad rep......then MS has every right to try and enforce a policy that will lead to a better Mom and Pop end user experience. Let us all not forget that we It or development profesionals (or enthusiests for that matter) are but a small number of the global computing population. This has been the case since the Internets was established and will forever more be the case.-D

[Herby]

Microsoft.....Security.....Coding Standards.....

Is this a humor column or something? Those words together usually make me laugh.

As for "banned" things: doing this usually makes everyone VERY devious in ways to work around the banned item, no matter how "good" it is. We here in the USA tried to ban alcohol, and you know what that did. These "great ideas" (I use the term loosely!) are just the latest in a series of "feel good" promotions. We all know that it will do nothing to enhance the security of the coding, no matter what the language.

About the only thing that MIGHT help is a tactical nuclear strike close to Redmond, Washington (after the residents are warned so they can get out). The buildings and copies of Windows sources need to be wiped off the face of the earth, not the people responsible for them. Those need to go into some other line of work ("would you like fries with that?").

Yes, a humor article.

[Name]

What's new in this?

I thought as a industry we banned all unbound buffer copy (e.g. using strncpy() instead of strcpy() etc.), and the POSIX version of memcpy() has length of buffer as a third argument

http://opengroup.org/onlinepubs/007908799/xsh/memcpy.html

I guess, M$ is still behind the curve. Welcome to secure computing!

[Sooty]

just remember

the whole purpose behind the creation of c, was to create a high performance language at the expense of safety. It really is supposed to be a few steps above assembler code.

You could add bounds checking to the function, but that defeats the purpose of using c in the first place. Ie. if you know you won't go outside of the bounds, its faster not to check, if you aren't sure if you'll go outside of the bounds or not, you chose the wrong tool for the job.

[Anonymous Coward]

@ Josh

"Unix type OSes have exception handlers that don't let buffer overflows and the like compromise a machine like they've been doing on Windows since Win95 at least."

Again this is all news to me. Do you actually program?

I program with *nix and their familiar associated tools and I can overflow buffers real good with the best of 'em!

The OS has nothing to do with it, bud. It's just as easy to wreak havoc with sloppy C or C++ or assembler (or anything) on Linux & Unix as it is with Windows. There's good and bad code on ALL platforms. *nix does not a competent programmer make.

[Anonymous Coward]

Oh, so it's the language's fault, not the idiot using it, huh

I'd say it's amazing, but very few idiotic things that come out of Redmond these days amaze me anymore. This is just another blatant statement of how M$ wants to coddle the inept developers that are being churned out while stepping on the toes of us -real- developers that know how to use such functions properly. Um, don't blame the language - blame the idiot who has no clue how to use it. Besides, isn't that why they made .NET?! Who needs to write tight, clean code anymore - any a$$ can program now thanks to the wonderful world of .NET and "garbage collection". Having written in a number of programming languages, garbage collection still does not impress me; it is an excuse for not keeping track of the resources you allocate and for allowing the developer to write $h!t code. Personally, I like to know when my variables and system resources go out of scope and are released back to the system, but then again, I was taught how to do it properly. This whole cr@p about memcpy() vs memcpy_s() is from the same pile of bunk. If you know how to do it right in the first place, you shouldn't need added bounds checking. That's called good design - but that assumes that the person writing the code understands such a concept. Chances are, if they work in Redmond, they've never heard of it before.

[Anonymous Coward]

@Dustin

(Sorry Sarah - I'm not letting this one pass!!)

"I am no programmer" - probably a bad start to your post.

Your FTP example is quite apt. Most people don't need an FTP server running on their machine, so they have to enable it if they want it. The point is they install it or they don't.

It's much like choosing a programming language - if you want the ability to do smart things at a low (yet -some might say- more readable than assembler) they use a language, such as C, that lets you do that. If however you feel incapable of ensuring you do that properly then use a language that takes care of it all for you in a safe worry free way.

What most people are objecting to - quite rightly - is this bastardisation of C (well, libc). They probably shouldn't be using any kind of memcpy if they can't use the original one properly.

[Eddie Edwards]

@ Ben

"Also, what happened to the __restrict keyword? It's strangely absent from the memcpy_s function declaration."

It's correctly not on there since memcpy / memcpy_s arguments are allowed to alias.

[Anonymous Coward]

A title is required.

@Kevin Whitefoot

"Isn't the ability to mark memory blocks with flags controlling these things supposed to be a feature of proper operating systems and processors? I have vague memories of reading many years ago about the memory management features of mainframe computers that mention things like this"

Yes, a M/F will not allow you to address memory outside your own application space and corrupt OS memory, also the M/F (well IBM ones anyway) don't have a stack in the same way that a PC has, so no pollution of return address by overflowing the buffer in the stack, note it is still possible to corrupt the return address, but again you can't access memory outside your own application address space. In addition, the M/F doesn’t have an Outlook address book to be hijacked for sending spam.

I like Andrew (09:27 GMT) solution, probably is what will happen

I also agree with AC 09:32 GMT, this is just microshaft trying to make windoze C different from ANSI C.

I once hade to convert some Borland C to Microshit C code. It took a couple of crashes to realise that the parms were in a different order. Standard library code my arse.

Yes, those were the days, why use DOS/BIOS to write to the screen, just memcpy chunks of screen memory, real programming I tell you.

Paris, who knows how to deal with dangling pointers

[jake]

@Jonathan; @Joe M

Jonathan: Larry Ellison.

Joe M: I've worked with quite a few ex-MSies. Some were competent, most were not. The ones that were came to Microsoft with years of industry experience. The ones that were not came to Microsoft straight out of college/university. Not certain why, but that's what I've seen. YMMV.

[Jim]

memcpy()

This is bollocks. Did anyone ever hear of size_t n? These people are idiots. The problem is that the coders don't bother to check the size in the code relative to the buffer. Banning memcpy is not going to do a damn thing to make software more secure. What we need to do is ban stupid developers who don't bother to size check data before they move it. It's rather hard to imagine how you can create a function that can read the mind of the developer and also determine how much virtual memory is available at a given moment. If you could do that the computer could just develop its own code.

[WinHatter]

M$ecurity AHAHAHAH

@Peter, right you are ... with M$ it's putting a MASSIVE padlock to heavy for the structural strength of the door and anyway there is a man-sized cat door.

plus you can always remove most of the safeguards from the C/C++ headers to poke where you should not. And anyway someone will make available the very same function and last assembler is still accessible from C.

[Richard Day]

Two things...

1. Write your code properly

2. Test your code properly

The first is easy, the second is hard. Microsloth seem to have a problem doing either with any success. They've been the biggest offenders in buffer overrun problems to such an extent that you can use the term 'buffer overrun' in conversations without getting blank looks for normos.

So it's a bit fucking rich for them to tell us not to use it 'cos it's unsafe. Unsafe in their hands maybe, not in mine.

Bill cos ... well it's just all his fault, innit?

[Anonymous Coward]

100 comments...

100 comments and no one has a freaking clue what they are talking about. Has anyone here ever even used VisualStudio in the recent past? Has the author?

MS hasn't "banished" anything. Five years ago (actually, lemme repeat that: FIVE years ago), the compiler would give warning about the use of certain functions (among which, memcpy) and suggest the _s version of those functions instead. These warning could be suppressed anytime given about 3 seconds worth of typing...

[William Boyle]

Security Theater

As Bruce Schneier would say, this is nothing but Security Theater, and does nothing to make applications more secure or safe. Unless the underlying code of memcpy_s can validate the passed size with the real size of the target buffer, this is no more secure than memcpy itself. It is the programmer's responsibility to verify that buffers are of sufficient size to handle the data being copied to it. In any case, this is one of those situations where I prefer C++ to C because if the target object has been coded correctly, an assignment will "do the right thing", even if it is a bit less efficient than a raw memcpy, which is often optimized for the hardware the program is running on.

[Anonymous Coward]

@james and others,

First off, Yes, sorry, brain fart, should have been sizeof(FOO) not sizeof(dest) though sizeof(*dest) would do just as well.

Unfortunatly, obfucatsed by my fat fingers but the point about *using the compiler to associate sizes with pointers at compile time* holds true.

This implies that you would *know* if the assert(sizeof(FOO) >= sizeof(BAR)) is true at compile time meaning memcpy(dest,src,sizeof(*dest)) is allways safe provided dest/src are non-null.

@james

That said, nothing about any language protects you from typo related bugs or copying data to the wrong place, so I must assume your comment about languages is an attempt to impune my work, in response I Fart In Your General Direction!

@ @@Kevin

Yeah the src buffer too small issue is an edge case that has to be solved by context,

I think that limiting the write length with truncation as needed, and using declartive checking to avoid the short-copy issue is the way to go, YMMV.

@Others

And as for the various people pointing out sizeof(FOO) != sizeof(BAR), that may or may not be relevant but if i was assigning one FOO to another, structure assignment would be the method to use rather then memcpy.

The article refers specifically to a memcpy variant with the capacity for differing src/dest sizes so

the use of different types is implicitly a nod to the same techinque but portably done.

@Anonymous Coward Posted Friday 15th May 2009 12:10 GMT

Interestingly you both invoke efficency and scala in the same post, no contradiction there.

Tuck the little tin god efficency back in the box.

As far as flavour of the month languages go, I prefer ruby and erlang myself.

1) When your app is time critical, you don't use scala.

2) Offsets cause buffer overflows do they? Two words, Region Allocators.

here a link to maybe lift that cloud from your worldview scala boy.

http://www.dur.ac.uk/computer.science/staff/?mode=pdetail&id=2385&sid=2385&pdetail=25243

From the linked article :

Region-based memory management offers several important potential advantages over garbage collection, including real-time performance, better data locality, and more efficient use of limited memory. Researchers have advocated the use of regions for functional, imperative, and object-oriented languages.

TTFN

[Anonymous Coward]

@100 comments...

Right, that proves every programmer here's point - if you don't disable the warnings and listen to visualstudio (gaah) then you'll not learn how to use memcpy safely and therefore become a terrible C programmer.

Inability to use memcpy \implies inability to program in C. FULL STOP.

It scares me that there is a generation of programmers being developed that have such an inability to see where their code is going wrong or wasting/leaking memory. I myself am not particularly old but cut my teeth in an HPC environment where wasting memory is a big no no and optimisation is key. I'm glad I didn't do a computer science course as all they seem to teach people these days is 'oh don't worry about memory issues - the compiler will deal with GC'.

[Charles]

If tracking the size of buffers is such an issue...

...then why hasn't there been mandated the used of a structured data type where data size is self-managed alongside the data itself (by using C++ classes or functions that modify a struct properly). That way the size of the buffer is not up to the programmer (who may not even know what's supposed to be coming in). If memory problems are the result of the language being too loose, perhaps it is time to tighten it up and force sanity checking.

[vincent himpe]

Store array size in the array descriptor

and string size in string descriptor.

compiler can do size checking at compile time.

Visual Basic has been doing that for years.

[Anonymous Coward]

The gcc/glibc/linux solution

khazaddum$ cat tmp.c

#include <string.h>

int

main (void)

{

char c[20];

char d[30];

memcpy (c, d, 30);

}

khazaddum$ gcc -D_FORTIFY_SOURCE=2 -O tmp.c

In function ‘memcpy’,

inlined from ‘main’ at tmp.c:8:

/usr/include/bits/string3.h:52: warning: call to __builtin___memcpy_chk will always overflow destination buffer

khazaddum$

This was implemented two years ago. Should be available in any recent linux distro.

[James Gibbons]

@iAPX432 and all that

Yes, the good ole iAPX432. Ran slower than shit downhill. Rumor is that the CIA let the Russians have the design to set them back 10 years on trying to copy the microprocessor. Great idea!

[Anonymous Coward]

@sed gawk

Err, yes, offsetting the buffer will cause an overflow (how does the compiler infer the size of the remaining buffer?). And is copying a lot of memory suddenly more efficient simply because you're using a compiled language? Give a pithy, nonsensical response if you want, but you don't know what you're talking about!

[Frumious Bandersnatch]

when "Larry, Steve, and Linus" weigh in

What about when Moe and Curly weigh in? That's what I'm waiting for ...

[Anonymous Coward]

Virgin Nerds

Shit some of the virgin nerds on here dont havent a fucking clue about proper application (or OS) design and development...

Clearly - if you are using a proper strongly typed language and compiler then of course the code is going to be more secure and contain less bugs...no its not going to be perfect because a) the compiler isnt perfect, b) it cant do everything and c) people are still writing the code and are thus highly likely to make mistakes (despite how good a programmer some of these spotty smelly nerds think they are - every single one of them will have written (some) code that is absolute shite)

Of course standards should be adhered to whenever any programming is be done - they problem is each egomanical nerd thinks he knows best and just does it his own way - without realising that they in fact dont know everything and half of what they think to be valid is actually utter bollocks...

I have met so many programmers who think they are good - but the code they produce is utter shite...

I have met so many programmers who dont have a fucking clue about proper application (let alone database) design and development...

[Anonymous Coward]

@Dustin...

> I am no programmer

We know.

> This is identicle to having a service not installed or port listening after a clean OS install. Its

> precautionary. Where is the uproar over not having FTP running on a server a first boot? You

> can install it later if need be.

No it isn't. It's more akin to disabling the tool that tells you whether a service is installed.

This memcpy_s does *nothing* to add safety to anything but the most trivial of examples (where such protection should not be needed - a bug would be glaringly obvious).

What it does is to convince the sloppy programmer that his code is now "safer" by reason of using memcyp_s - so tempting him to do less actual design or testing.

The net result is a *reduction* in code safety.

[Eric]

Back to the dark ages....

This is nothing other than the "Shoot the messenger for providing bad news..." concept from feudal times moved into the current day.

The problem has nothing to do with the memcpy() routine. memcpy()'s only fault is not safely dealing with overlapping buffers (and IMO should always be replaced with memmove()). The problem is that developers have become complacent by using higher level languages which protect them from themselves.

That's why there is a concept of "Adult Programming" at a lot of companies. Adult Programming is for people who understand the languages and libraries, AND HOW TO USE THEM SAFELY!

Adding the extra parameter does nothing to ensure the values provided as parameters are correct. That has to be done by the programmer.

I was always taught (back in the olden days of computing, in the before time that was the 1980's) that you must verify/validate any parameters you pass into your functions and methods before you make your call. If Microsoft (and colleges, universities, et al...) would go back to this, then we could get beyond "Pointy-Haired Boss" decisions like this and develop programmers who truly understand what they are doing.

[Anonymous Coward]

"store array size in the array descriptor" (and equivalents)

Excellent idea. VMS has been doing that since 1978, not just at compile time but at run time, and not just in BASIC, but in any of the supported languages and in the language-independent runtime libraries. Do that right, and there's no such thing as a buffer overflow. The VMS languages were interoperable with each other almost 30 years before Microsoft caught on to the concept of proper mixed language programming. The concept you need to read up about is "descriptors" which are inherent in VMS BASIC, FORTRAN, Pascal and others, and which can easily be added to your C (or Ada) code if you wish to take advantage of the benefits.

[Anonymous Coward]

iAPX432 - logical predecessor to Itanium?

Technically elegant (allegedly) but noboday actually wanted it. Just like... well, you know.

[Charles]

Re: The gcc/glibc/linux solution

That warning only works if the arrays have constant parameters, enabling the compiler to know what size they would be ahead of time. If, OTOH, you're just given a source and destination pointer as the inputs to a function, with no knowledge of what's in them or even their size, you've essentially got a code bomb on your hands that not even the compiler would pick up. Same goes for data buffers for reading from files (since C doesn't know at open time how big the file is--you need to employ the file I/O functions creatively to figure it out).

[Anonymous Coward]

Quiche Eaters

what are they trying to do, turn C into Pascal?

[Iain]

use malloc and check for NULL pointers.

A good programmer would malloc the memory space first, check if a NULL pointer was returned (out of memory), and then memcpy if the memory was successfully allocated.

Also, why are all the examples here memcpy'ing char or char* variables? Use a struct ...

[Anonymous Coward]

tarmac_s

In related news:

Traffic Officials discovered that the underlaying cause of road accidents is "tarmac".

Larry Willeewanc, CTO (Chief Traffic Official) of the Department, commented: "We brought in twelve MENSA card holders to brainstorm over why road accidents occur when people can't drive, or inhibirated with alchohol, marajawana, and LSD.". Mr. Larry made the findings official on May 15.

"Tarmac is the real problem associated with increasing road accidents. Everybody drives on them, including busses and hybrid cars, and 99.9% road accidents happen on them. Therefore we will replace all tarmac roads with tarmac_s roads."

It was revealed that the "_s" in "tarmac_s" stands for "sponge". A sponge-like compound will be added to tarmac in order to prevent bad driving. All moms know that sponges are safer for babies.

Micheal Broomsweep, a 16 year old, reacted cheerfully, saying: "Yay! Now I can take my dad's car and go partying without worrying about having 'another one for the road' with me lads! lol1"

In a traffic department blog post, it was asked when Toyota, Honda and Suzuki will implement sponge into their designs. A good question indeed.

(Editor's note: I, for one, hail the new sponge powered tarmac roads)

[Anonymous Coward]

What is more concerning

but of course to be expected. Is there are people not using testing tools such as valgrind to test their applications before release.

Most, it would appear to be, are just cowboys in the IT world, didn't use to be that way but that is what off shoring does.

Being logical and rational about all of this, the dark side is much better for taking into account testing techniques, the Jedi have all been turned, and you have software written by klatooinians and tuskan raiders.

[Robert Hill]

MS actually does GET it on this one...some here do too

It is VERY easy to say that a competent programmer knows how to avoid buffer overlow in any language and in any condition...

The problem is that 25 programmers often have a more difficult challenge when working together than a single lone programmer. And with Agile and related "no/light spec" (asbestos suit on!) methodologies proliferating, getting information about what exactly each buffer should have and what length it should be updated to each team member during a development phase is a difficult task. Yeah, that's what encapusulation and concepts like data hiding are all about, but let's face it, pure C was desgined with little of that in mind. Changes during development WILL get missed, and the code relying upon it WILL run, even passing all testing. It will just have a massive security hole looming beneath the surface...

What MS is doing is defining a new library that APPEARS to (and probably DOES) make group programming in C a bit safer. Not that code won't FAIL, or BLOW UP...but at least common security exploits can be stopped. If your program fails, that might be a small or even a large loss. But if your program security hole results in the bank accounts of 100,000 people being emptied, that is a DISASTER from a legal liability viewpoint, a software brand viewpoint, etc.

Anyone who doesn't see how useful this is hasn't programmed on large projects, and hasn't faced the vagrieties of changing specs and design while trying to hit a deadline with a large team doing co-operative development...this is a safety catch for when the left hand really DOESN'T know what the right hand is doing...

The Halo Bill icon for this one...even he deserves an attaboy occasionally.

[John Smith]

A note from CAR Hoare

I paraphrase from his Turning Lecture. We asked our customers if they wanted us to remove bounds checking from arrays. They said no as it had caught so many errors.

The language he was talking about was Algol on machines whose clock speed could just about crawl into the Mhz range being run by large public companies (so performance was * very* much an issue) and at least some of the programs would have quite strict deadlines attached to them.

C/C++ are powerful and ubiquitous. But how much of that Windows code is written in them? With all that work on common language run-times it seems a lot of Office (at least) is written in something else. How often is that power actually needed? For the record both pointers and pointers to functions (that favourite C idiom) were in Pascal from day 1. Sadly Borland (as was then) did not include the pointers to function till V5. Perhaps if they did it sooner the world might be a different place. Is there now a generation of programmers who cannot think through common problems without needing dynamic memory allocation?

Mine is the one with a copy of "Code Complete" straining the side pocket with a nice example of how to do C in Pascal.

[Nermal]

My 2p

Having been an Ansi C programmer for a few years and having to write cross platform code to various platforms including the intresting Microsoft variation of Ansi C.

I understand the reasons why Microsoft feel that they need to do this. But, if they are saying that you cannot get your app certified while using memcpy() then, in my opinion, they should drop their claims to be ansi compatible. This will require yet another macro to mangle the calling of another function that Microsoft have changed or failed to accurately implement.

They are, again, fixing the symptom and not the fault. Maybe they should look at fixing faults properly and not the symptoms.

I also wonder if this will also impact the performance of the same code running under Windows based against the Unix's and Linux's of this world.

This would seem to push High End Apps back to the Unix like Platforms again.

[Anonymous Coward]

It's amazing

It's amazing how many people think that high-level languages will avoid programming errors.

Actually, perhaps it's not that amazing. Some languages have constructs that make it much harder to make certain classes of error. My favourite, in that regard, is still CLU.

On the other hand, there is no programming language on earth that will prevent programmers from making mistakes.

The mistakes vary a little from language to language, but just because one language prevents common mistakes in another doesn't mean that it won't engender its own common mistakes. It would be nice to think that there is a programming language that makes it difficult to make all those common mistakes, but I doubt you'd be able to write programs that do real work in it.

Replacing memcpy() with memcpy_s() will, with any luck, make programmers think twice. At least for a little while. After that it won't work because those same programmers will get sloppy and use the same length for both buffer sizes or find other ways to miscompute how many bytes should be copied.

The only real solution is to teach these people how to write correct code. And not to employ monkeys.

[Drak]

here is what Bjarne had to say

I fired off an email to Bjarne Stroustrup to see what he thought about this issue and here is what he had to say:

http://img196.imageshack.us/img196/2926/clipboard02z.jpg

[michaelh]

I guess the next step will be...

http://tinypic.com/view.php?pic=21cgmrl&s=5

[Anonymous Coward]

Layers ...

To miss quote Shrek "Security is like onions". It's all about layers and defense in depth.

If this helps find a few issues, and prompts 1 programmer in 50 to go "oh yeah, hadn't thought about that" then it has helped improve security (even if not making something totally secure).

Is it bullet proof? No - but it should at least result in some improvement - and shouldn't make anything worse.

That said - why you can't grep the source for memcpy then just code review the unsafe version (which you are probably going to need to do anyway) - is beyond me =)