tags:

views:

556

answers:

2

Duplicate:

Memcpy() in secure programming?


According to "Please Join me in welcoming memcpy() to the SDL Rogues Gallery" memcpy is being banned as unsafe. It makes sense that gets(), strcpy and similar apis where the destination size is unclear. Is memmove() next?

+2  A: 

The point with all these “safe” methods is:

Of course, you can easily make a call to memcpy_s() insecure by getting the buffer sizes wrong.

[Source]

Which is why I find this SDL feature highly over-hyped. Of course, such problems are inherent in a language like C if no precautions are taken by the compiler (or an appropriate runtime, which would be costly in terms of performance and/or memory).

It also makes programs less portable which I personally find is a huge disadvantage. Of course, Microsoft wouldn't necessarily agree.

Migrating the code to C++ with proper use of (checked) iterators might make more sense, where possible. These operations, while also inherently unsafe, are more easily used right, and make wrong code stand out. Of course, caveat emptor, and all those C fans and C++ deniers will be after my skin now …

Konrad Rudolph
A: 

memmcopy might create an opening for stack overflow by a malicious user. For example: The specific flaw exists during the processing of a malicious WordDocument file. The overflow can be triggered during the parsing at offset 0xb4c in the WordDocument stream. At this offset, there is a WORD size that is used as the third parameter to a memmove call.

So essentially then you'd use the secure version to check your input for you. The root problem - assuming no one will ever try to screw with you by carefully corrupting your files - still remains.
Shog9