Live data from Hacker News

How to zero a buffer

daemonology.net

121–130 of 216 posts

Re: How to zero a buffer

#121
I had no idea that such things are possible in C. The things about I've read recently (the "friendly" C suggestion) and this seem like violations of the spirit of the language. And for what, really? The language looses its signature predictability, which to me seemed like a great feature of C.

If you write crappy code and expect the compiler to fix it for you, you should maybe consider another language. I can only imagine how hard it is to write reliable system software in a language that does these things.

Re: How to zero a buffer

#122
post #22

Can someone explain this line: static void * (* const volatile memset_ptr)(void *, int, size_t) = memset; I've written some C but that is utter gibberish to me.

As usually in C, you start from the name, then try to go to the right until you hit parenthesis, then go to the left until parenthesis, rinse and repeat. So, first, the name: memset_ptr Then, try going to the right, but aha! before we can really gain speed, a parenthesis is immediately blocking us. We shrug off the bruises and turn to the left: (* const volatile memset_ptr) "Hey guys, memset_ptr is a volatile const p…

This technique is described in Peter van der Linden's book "Expert C Programming : Deep C Secrets" (and also explained really well by you).

Re: How to zero a buffer

#123
post #121

I had no idea that such things are possible in C. The things about I've read recently (the "friendly" C suggestion) and this seem like violations of the spirit of the language. And for what, really? The language looses its signature predictability, which to me seemed like a great feature of C. If you write crappy code and expect the compiler to fix it for you, you should maybe consider another language. I can only im…

Actually back in the old K&R days it was much much worse, as no real standard was in place, compilers were just kind of compatible with endless little surprises.

Specially fun when trying at home your UNIX homework and vice-versa.

Re: How to zero a buffer

#124
post #44

When I allocate the key on the heap, the memset is carried (heavily optimized and inlined). When I allocate key on the stack, it disappears. Using gcc -03: #include void doSecure(void) { /*char key[32];*/ char *key = (char*) malloc(sizeof(char)*32); memset(key,sizeof(char),32); } int main(void) { doSecure(); return 0; } -- key on stack main: .LFB13: .cfi_startproc xorl %eax, %eax ret .cfi_endproc -- key on heap main:…

That is compiler specific behaviour.

You have zero guarantees it will work in another compiler or even between releases of the same one.

Never take a compiler behaviour for the standard. That's the beauty of standards.

Re: How to zero a buffer

#125

Earlier quoted context omitted.

C may have pitfalls for "these kinds of applications," but it has some strengths that other languages don't. Since C gives the programmer significant control over memory allocation, it's possible to avoid various kinds of timing attacks related to cache misses ( possible is not the same as easy ). Many languages don't give the programmer the necessary tools to do that.

There are two different things you can mean when you say "C is not suitable to these kinds of applications". One is the more extreme, "You should not be using C, you should be using because it is more suitable." That's a bit of a hard sell; though specific alternatives should be evaluated on their merits. There is also, "there are design choices that have been made in C that make it worse for these applications than…

The funny thing to me is that the standard crypto packages for other languages nearly always end up calling C code.

Re: How to zero a buffer

#126
post #112

Earlier quoted context omitted.

What do you mean? The solution that Percival presents compiles fine on my C89 compiler.

I didn't mean to imply that the solution as presented didn't work, I was just wondering if it would also work simply running the cipher with the zeroed key in order to avoid zeroing the key being optimized away. Obviously that'd be a lot more cycles; I'm just curious if it would be a viable solution ;-)

I was referring to the first sentence ("It is a little mind boggling that support for proper handling of this didn't arrive until c11."). I don't see anything C11-specific in the code Percival posted. I don't know enough to say anything useful about the rest of your comment.

Re: How to zero a buffer

#127
post #121

I had no idea that such things are possible in C. The things about I've read recently (the "friendly" C suggestion) and this seem like violations of the spirit of the language. And for what, really? The language looses its signature predictability, which to me seemed like a great feature of C. If you write crappy code and expect the compiler to fix it for you, you should maybe consider another language. I can only im…

Other way round: the C language after optimisation is unpredictable, which makes it hard to write secure system software.

You don't expect to write sound-looking code and have it broken for you by the optimiser.

Re: How to zero a buffer

#128
> on C11 […] you can use the memset_s function

How is the case for modern C++? Are there `vector` or smart pointer alternatives that reliably zero the memory in the destructor?

Re: How to zero a buffer

#129
This all seems kind of silly. Why doesn't C have a type qualifier like called "secure" to inform the compiler that it should avoid security-compromising optimisations and maybe even automatically zero the memory when it falls out of scope?

Re: How to zero a buffer

#130

You should have test cases to verify the zeroing behavior in the object code. Even if the standard says a compiler must do something does not mean that it does.

The difficult thing is that any way to verify the zeroing behavior would change the compiler's decision about whether it could elide the call to memset. So it's possible (well, almost guaranteed) that the test would succeed even though the memory wouldn't actually be zeroed in production.

Remember that we're trying to mitigate exploits. The test code could just be an exploit. Either that or just dump and analyze the memory.
Post reply on HN