Topic: Memcpy() banished in Redmond  (Read 1326 times)

0 Members and 1 Guest are viewing this topic.

Offline toasty0

  • Application.Quit();
  • Captain
  • *
  • Posts: 8045
  • Gender: Male
Memcpy() banished in Redmond
« on: May 15, 2009, 03:36:30 pm »
NOTE: This is pro'ly of little interest to anyone but marstone and a few others, but as I don't know how many are going to script against the new SFC code base I thought it still might have community weight.

Larry? Steve? Linus?

By Dan Goodin in San Francisco • Get more from this author

Posted in Security, 15th May 2009 00:39 GMT

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

Memcpy has long served as a basic staple of C-based languages, providing a simple way to copy the contents from one chunk of memory to another. Its drawback comes when the source to be copied contains more bytes than its destination, creating overflows that present attackers with opportunities to remotely execute code in the underlying application.

"That's definitely one of those notoriously dangerous C commands," said Johannes Ullrich, CTO of the SANS Institute, who teaches secure coding classes to developers. He likened memcpy() to other risky functions such as strcpy() and strcat(), which Microsoft has already banned after exacting untold misery over the years.

Developers who want to be SDL compliant will instead have to replace memcpy() functions with memcpy_s, a newer command that takes an additional parameter delineating the size of the destination buffer. 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. (This evidently can easily be worked around, according to this discussion. Readers who know other approaches are encouraged to leave a comment.)

A Microsoft blog entry that heralded the planned change suggests modifying common header files so compilers issue a warning each time the banned function is used.

It also wondered aloud when "Larry, Steve, and Linus" plan to issue similar security edicts in their products. It's a question worth asking. ®
http://www.theregister.co.uk/2009/05/15/microsoft_banishes_memcpy/
MCTS: SQL Server 2005 | MCP: Windows Server 2003 | MCTS: Microsoft Certified Technology Specialist | MCT: Microsoft Certified Trainer | MOS: Microsoft Office Specialist 2003 | VSP: VMware Sales Professional | MCTS: Vista

Offline FPF-Paladin

  • 'Thou shalt not CAD.' - DH
  • Lt.
  • *
  • Posts: 588
  • Gender: Male
Re: Memcpy() banished in Redmond
« Reply #1 on: May 15, 2009, 07:24:40 pm »
Bah, it's about time.. they've known about this and the accompanying issues for... geez, a long time.

*feels his age*
~Life cannot find reasons to sustain it, cannot be a source of decent mutual regard, unless each of us resolves to breathe such qualities into it. ~

Offline toasty0

  • Application.Quit();
  • Captain
  • *
  • Posts: 8045
  • Gender: Male
Re: Memcpy() banished in Redmond
« Reply #2 on: May 15, 2009, 08:47:09 pm »
Stop it. No one wants to see you feeling your age...
MCTS: SQL Server 2005 | MCP: Windows Server 2003 | MCTS: Microsoft Certified Technology Specialist | MCT: Microsoft Certified Trainer | MOS: Microsoft Office Specialist 2003 | VSP: VMware Sales Professional | MCTS: Vista

Offline marstone

  • Because I can
  • Commander
  • *
  • Posts: 3014
  • Gender: Male
  • G.E.C.K. - The best kit to have
    • Ramblings on the Q3, blog
Re: Memcpy() banished in Redmond
« Reply #3 on: May 15, 2009, 08:54:12 pm »
yeah, I have been using the _s forms of some of the functions.  Wasn't sure why I was to use them, but I have been.  Now I see why, will use them more in the future instead of slipping back into old habits.
The smell of printer ink in the morning,
Tis the smell of programming.