BANNED: memcpy(), CopyMemory(), and RtlCopyMemory()

Index > Windows > BANNED: memcpy(), CopyMemory(), and RtlCopyMemory()

Goto page 1, 2 Next

Author

Thread

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 20 May 2009, 12:44

http://www.theregister.co.uk/2009/05/15/microsoft_banishes_memcpy/ wrote:

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 the C language. Effective later this year, Microsoft will add memcpy(), CopyMemory(), and RtlCopyMemory() to its list of function calls banned under its secure development lifecycle.

And here is a list of other banned function calls:

http://msdn.microsoft.com/en-us/library/bb288454.aspx

20 May 2009, 12:44

pete

Joined: 20 Apr 2009
Posts: 110

pete 20 May 2009, 12:58

Quote:

Some Microsoft security bulletins would not have been necessary if banned APIs had not been used.

Well, for me there's only one function that i'll miss, but found some weeks earlier a replacement on this board: wsprintf. Does one care about the banned functions (as ASM programmer)?

20 May 2009, 12:58

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 20 May 2009, 13:13

WTF? How are they going to copy blocks of memory now?

20 May 2009, 13:13

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 20 May 2009, 14:52

vid: Look at the second link I posted. It has the alternate APIs.

20 May 2009, 14:52

pal

Joined: 26 Aug 2008
Posts: 227

pal 20 May 2009, 15:20

Hmm, are you sure this is going to happed (soon anyway).

http://msdn.microsoft.com/en-us/library/bb288454.aspx wrote:

March 2007

Note: This paper is derived from the book The Security Development Lifecycle, by Michael Howard and Steve Lipner, Microsoft Press, 2006

Seems a bit old; two years.

20 May 2009, 15:20

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 20 May 2009, 16:01

Just a few days ago in the MSDN blog:

http://blogs.msdn.com/sdl/archive/2009/05/14/please-join-me-in-welcoming-memcpy-to-the-sdl-rogues-gallery.aspx

20 May 2009, 16:01

drhowarddrfine

Joined: 10 Jul 2007
Posts: 533

drhowarddrfine 20 May 2009, 16:07

This made me laugh:

Quote:

Simply replacing a banned function call with a better replacement does not guarantee that the code is secure. It's possible to misuse the replacement function, most commonly by getting the destination buffer size wrong.

20 May 2009, 16:07

pal

Joined: 26 Aug 2008
Posts: 227

pal 20 May 2009, 16:20

Ahh OK, I guess that they have been planning it for some time then.

20 May 2009, 16:20

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8359
Location: Kraków, Poland

Tomasz Grysztar 20 May 2009, 19:03

vid wrote:

WTF? How are they going to copy blocks of memory now?

I thought you would actually support this idea, knowing how much are into pointing out the laziness in error checking. strcpy_s may help to discipline the programmers, at least a little bit.
Well, the lazy programmer may still try to put some huge value as destination buffer size just to make thing work and forget about it... *sigh*

20 May 2009, 19:03

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 20 May 2009, 19:20

No big deal unless you are coding high security industry apps.
I am guilty myself for leaving these holes in my programs.
If someone wants to get inside they eventually will crack it.
At least it will help make buffer overflows a bit more difficult.

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.

20 May 2009, 19:20

r22

Joined: 27 Dec 2004
Posts: 805

r22 20 May 2009, 19:31

Precious CPU cycles are melting away!

Useless code to be executed ad-nauseum

Code:

MOV reg,[DST_LENGTH]
CMP reg,[SRC_LENGTH]
JB .DONT_WORRY_MICROSOFT_WUVS_YOU

20 May 2009, 19:31

vid
Verbosity in development

Joined: 05 Sep 2003
Posts: 7105
Location: Slovakia

vid 20 May 2009, 21:29

revolution: second link seems only have functions that are already banned. But now I found answer in second link.

Tomasz: I support it fully for string functions, but memcpy()? I think this is a bit overkill, but I agree it is understandable in case of MS.

20 May 2009, 21:29

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 21 May 2009, 23:50

This is the dumbest thing I've heard in a LOOOONG while Confused

First I thought it was a prank, can't believe it's actually real. It makes as much sense as copying the function arguments twice "for consistency reasons" lololol.

_________________
Previously known as The_Grey_Beast

21 May 2009, 23:50

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20451
Location: In your JS exploiting you and your system

revolution 22 May 2009, 00:29

I think they (MS) are realising that the programmers don't know how to properly use the function. So, rather trying to change the programmers habits, they thought it would be easier to change the function. And I suspect they are right, changing a programmers habits can be very hard to do. Right tom? Razz

The extra parameter kind of encourages the programmer to think about the size of the destination. However if a programmer decides to misuse it then of course this change will make no difference.

22 May 2009, 00:29

drhowarddrfine

Joined: 10 Jul 2007
Posts: 533

drhowarddrfine 22 May 2009, 03:10

I agree with revolution but I also wonder if MS is trying to protect people from themselves. They have enough issues. It's like banning loops or movs in asm cause they can runaway without a proper counter. Stupid.

However, the C library has new functions for copying strings that require definition of the string length but no one has banned the old use.

22 May 2009, 03:10

sinsi

Joined: 10 Aug 2007
Posts: 794
Location: Adelaide

sinsi 22 May 2009, 03:51

Quote:

Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s

Not totally banned, just 'deprecated'.

Anyway, what do we care? I don't use any C library functions.

22 May 2009, 03:51

Borsuc

Joined: 29 Dec 2005
Posts: 2465
Location: Bucharest, Romania

Borsuc 23 May 2009, 22:57

CopyMemory is not a C function.

23 May 2009, 22:57

bitRAKE

Joined: 21 Jul 2003
Posts: 4073
Location: vpcmpistri

bitRAKE 23 May 2009, 23:18

My processor has REP MOVSB, so I use it where needed and memory sections are known not to overlap.

Copying massive blocks of memory has never been an algorithmically sound practice. Imagine an editor which completely copied the text every time a character was inserted/deleted - bad design unless the maximum number of characters is fairly small.

MS's approach is the exact opposite of education and supports the dumbing down of the programmer - just a sick hierarchy of protocols with all the wrong reasons.

23 May 2009, 23:18

pelaillo
Missing in inaction

Joined: 19 Jun 2003
Posts: 878
Location: Colombia

pelaillo 26 May 2009, 18:03

Quote:

MS's approach is the exact opposite of education and supports the dumbing down of the programmer

They already succeed in dumbing down the computer users.

26 May 2009, 18:03

comrade

Joined: 16 Jun 2003
Posts: 1150
Location: Russian Federation

comrade 27 May 2009, 07:42

That's bad? Take a look at Apple kicking their ass.

27 May 2009, 07:42

Goto page 1, 2 Next

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum