Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zeroing buffers is insufficient

daemonology.net

Post reply on HN
Print view View original

51–60 of 134 posts

Re: Zeroing buffers is insufficient

#51

Post by lazyjones »

AlyssaRowan wrote: post #45
userbinator wrote: post #34

Earlier quoted context omitted.

This is also why dedicated cryptoprocessors exist, with special features for attack resistance; I'm not completely certain about this, but I'd think the software running on those does not have to zero memory containing keys, because the whole environment that said software runs in has been secured from the outside already, and if it's possible to read any memory or run untrusted code from outside on those without bei…

Having seen a few existing designs of those, up-close and personal - actually they do have to worry about zeroisation, quite an awful lot. And sometimes they don't worry enough either. They ought to fail a FIPS-style audit for that. But, well... they ought not to contain proprietary LFSR "crypto" algorithms, either. They are not as well audited, or as publicly designed, as they ought to be: many are as black-box clos…

Are current GPUs suitable subsystems for running properly isolated cryptographic algorithms? If not, why not? If yes, perhaps a well-audited open source library would be possible.

Re: Zeroing buffers is insufficient

#52

Post by nly »

cousin_it wrote: post #6

I don't completely understand the C spec. Would the following approach work for zeroing a buffer? 1) Zero the buffer. 2) Check that the buffer is completely zeroed. 3) If you found any non-zeros in the buffer, return an error. Is the compiler still allowed to optimize away the zeroing in this case?

Is the compiler still allowed to optimize away the zeroing in this case?

With 'volatile', generally not, modulo bugs. Without volatile, it would never return an error.

Re: Zeroing buffers is insufficient

#53

Post by gizmo686 »

xxs wrote: post #23
Rapzid wrote: post #10

Earlier quoted context omitted.

I was wondering that too.. I would think that simply accessing the any byte in the buffer afterwards would prevent the compiler optimizing it out.

That depends how much the compiler can optimize (away). If the next call is free(), it's quite trivial to skip the zeroing and just take the correct branch. I am still uncertain while people want to just 'zero' it. Filling random data (just one random() call) and then using inline PRNG, then summing the result, storing it globally in volatile would reliable 'zero' the data but it's quite CPU intense.

You still are not guaranteed to clear the buffer like that.

  for (int i=0; i
Using loop fusion, the compiler can optimize this to: int sum=0; for (int i=0; iWhich it can then optimize to: int sum=0; for (int i=0; iIn fact, as the article points out, the compiler can legally transform:

  reallyZeroBuffer(sensitiveBuffer);
into

  pointlesslyCopy(sensitiveBuffer);
  reallyZeroBuffer(sensitiveBuffer);

Re: Zeroing buffers is insufficient

#54

Post by zAy0LfpBZLC8mAC »

xxs wrote: post #40
zAy0LfpBZLC8mAC wrote: post #29

Earlier quoted context omitted.

Why shouldn't the compiler be able to figure out that you sum a series of numbers that aren't used anywhere else, thus don't need to be spilled to RAM?

You write them to a global state volatile

How does that require writing the random data to RAM, apart from the volatile variable itself?

Re: Zeroing buffers is insufficient

#55

Post by lazyjones »

pascal_cuoq wrote: post #42
cousin_it wrote: post #6

I don't completely understand the C spec. Would the following approach work for zeroing a buffer? 1) Zero the buffer. 2) Check that the buffer is completely zeroed. 3) If you found any non-zeros in the buffer, return an error. Is the compiler still allowed to optimize away the zeroing in this case?

> Is the compiler still allowed to optimize away the zeroing in this case? Yes, completely. In the snippet below, the compiler is allowed to eliminate all code after “leave secrets in array c”. { char c[2]; ... /* leave secrets in array c */ memset(c, 0, 2); c[0] = 0; c[1] = 0; memset(c, 0, 2); if (c[0] || c[1]) exit 1; } The compiler is also allowed to compile the last three instructions below as if they were “retur…

> In the snippet below, the compiler is allowed to eliminate all code after “leave secrets in array c”

gcc 4.4.5 doesn't though (-O3), it still clears the stack once and performs the comparison.

I believe these optimizations can be defeated by declaring a global

  volatile char fill = 0;
and using that instead of 0 in memset().

Re: Zeroing buffers is insufficient

#57

Post by anon1385 »

Demiurge wrote: post #41

Every time I read one of these posts about a clever "attack vector", how something can be gleaned from this special register, or a timing attack, somesuch, I remember about a theory that the sound of a dinosaurs scream can be extracted from the waves impact made on a rocks crystal structure. I googled pretty hard for real life example uses of a timing attack, and now using of stale data on the register, but couldn't…

For examples of real implementations of timing attacks, try this: http://www.contextis.com/documents/2/Browser_Timing_Attacks....

Some of those are fixed now, but the history stealing link redrawing one is still an issue as far as I know (or at least, this bug is still open https://bugzilla.mozilla.org/show_bug.cgi?id=884270 ).

Re: Zeroing buffers is insufficient

#58

Post by Demiurge »

anon1385 wrote: post #57
Demiurge wrote: post #41

Every time I read one of these posts about a clever "attack vector", how something can be gleaned from this special register, or a timing attack, somesuch, I remember about a theory that the sound of a dinosaurs scream can be extracted from the waves impact made on a rocks crystal structure. I googled pretty hard for real life example uses of a timing attack, and now using of stale data on the register, but couldn't…

For examples of real implementations of timing attacks, try this: http://www.contextis.com/documents/2/Browser_Timing_Attacks.... Some of those are fixed now, but the history stealing link redrawing one is still an issue as far as I know (or at least, this bug is still open https://bugzilla.mozilla.org/show_bug.cgi?id=884270 ).

Thanks, that's pretty awesome. However, I was talking about attacks relying on non-constant time memory copy or math function that is used to somehow defeat a server or cryptography.

Re: Zeroing buffers is insufficient

#59

Post by ge0rg »

Even if the proposed feature is added to C and implemented, there is still the (practical) problem of OS-level task switching: when your process is interrupted by the scheduler, its registers are dumped into memory, from where they might even go into swap space.

It would be consequential (but utterly impractical) to add another C-level primitive to prevent OS-level task suspension during critical code paths. Good luck getting that into a kernel without opening a huge DoS surface :)

Re: Zeroing buffers is insufficient

#60

Post by xorcist »

Symmetry wrote: post #24
polarix wrote: post #13

Earlier quoted context omitted.

What's the current status of the Mill project? Is there a proof of concept compiler / emulator? What's the bootstrap strategy to get things rolling?

Last I heard they're still limited to sims and are concentrating on patent filings. The bootstrap strategy is LLVM (once they get around LLVM assuming addresses are integers as opposed to the Mill's compound things) and to get Linux running on top of L4 which seems doable[1]. They say they're looking for a niche to start in before going after PCs. [1] http://l4linux.org/

Why on L4? Is Mill somehow tied to it, architecture-wise? Or is it just that L4 has a smaller footprint and is easier to port?
Post reply on HN