memset at the end of functions

Pertaining to any discovery, principle, or aspect of science and/or technology. Open debates and discussions are welcome. Also now dealing with any happening in the news.

Moderator: Geeks United

memset at the end of functions

Postby BugInTheSYS on Tue Mar 12, 2013 9:37 am

So today I read an article about how gcc and the like will optimize away memset() calls at the end of a function, which can be annoying when (e.g. in crypto applications) you want to be sure that you don't leave a footprint of sensitive data in memory. This type of optimization isn't new to the world, but new to gcc. (Apparently 4.7.2 and newer)

It is said that you can fix this behavior by inserting the statement
asm volatile("" ::: "memory");

after the memset call, so GCC will not reorder memory instructions. It's generally nice to know that command. So, if you're worried about people analyzing memory dumps of your programs, you know what to do... Also it's probably better to check the assembly code anyway.
Someday, everything will go to /dev/null. - Bug's prophecy 13:37
User avatar
BugInTheSYS
Chaos Rift Cool Newbie
Chaos Rift Cool Newbie
 
Posts: 90
Joined: Mon Feb 07, 2011 6:16 pm
Location: Pinneberg, Germany

Re: memset at the end of functions

Postby bbguimaraes on Tue Mar 12, 2013 12:57 pm

Isn't there a switch among the ten thousand gcc switches to avoid that? I think that would be the standard solution (although I don't think people would go through that if it could be done this way).
User avatar
bbguimaraes
Chaos Rift Junior
Chaos Rift Junior
 
Posts: 324
Joined: Wed Apr 11, 2012 5:34 pm
Location: Brazil

Re: memset at the end of functions

Postby Falco Girgis on Wed Mar 13, 2013 11:09 am

I'm not sure whether there is a flag or not that you can pass to GCC (surely a lower optimization mode will get rid of that, but that probably isn't really a good way to avoid it).

It is a legitimate optimization.

Section 5.1.2.3 of the C Standard [ISO/IEC 9899:2011] states: wrote:In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object).


Other than for the reason previously stated, I can't think of any time you wouldn't want this optimization.

Just remember that even clearing out the data is not necessarily safe. If the data ever exists within RAM for any period of time, it is a potential security hazard. All you are doing with that memset() is reducing the size of this window.

I read that at least Windows (and probably all other modern OS's) zero out memory pages before giving them to an application. I can't see any way for a user-level application in a modern OS to access your application's virtual memory space. Whatever malicious piece of code would have to be executing within kernel-space to do such a thing...
"So what happens if the Elysian Shadows Kickstarter fails?"
Image
User avatar
Falco Girgis
Elysian Shadows Team
Elysian Shadows Team
 
Posts: 10693
Joined: Thu May 20, 2004 3:04 pm
Location: Studio Vorbis, AL

Re: memset at the end of functions

Postby bbguimaraes on Wed Mar 13, 2013 1:07 pm

User avatar
bbguimaraes
Chaos Rift Junior
Chaos Rift Junior
 
Posts: 324
Joined: Wed Apr 11, 2012 5:34 pm
Location: Brazil

Re: memset at the end of functions

Postby Falco Girgis on Thu Mar 14, 2013 9:49 am

Damn, that's a good article!


And for further reading on the memset optimization:
https://www.securecoding.cert.org/confluence/display/seccode/MSC06-C.+Be+aware+of+compiler+optimization+when+dealing+with+sensitive+data

I have to admit, though... The example given seems pretty damn weak in my book:
Code: Select all
void getPassword(void) {
  char pwd[64];
  if (GetPassword(pwd, sizeof(pwd))) {
    /* checking of password, secure operations, etc */
  }
  memset(pwd, 0, sizeof(pwd));
}
Even if that memset were optimized away, the function is ending. The statistical likelihood of future function calls' pushes to the stack not immediately overriding those 64 bytes with their own local storage is EXTREMELY low...

As I said, all you are doing is reducing the already extremely short window of time before that gets overwritten.
"So what happens if the Elysian Shadows Kickstarter fails?"
Image
User avatar
Falco Girgis
Elysian Shadows Team
Elysian Shadows Team
 
Posts: 10693
Joined: Thu May 20, 2004 3:04 pm
Location: Studio Vorbis, AL


Return to Current Events and Science/Technology

Who is online

Users browsing this forum: No registered users and 1 guest

cron