Zeroing buffers is insufficient
daemonology.net
Zeroing buffers is insufficient
1–10 of 134 posts
Re: Zeroing buffers is insufficient
#2It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing.
Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand.
The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?
Re: Zeroing buffers is insufficient
#3It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing. Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand. The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?
David Beazley after analyzing 1.5 Tbytes of C++ code shows in "Some Lessons Learned": C++ -- SUCKS, Assembly code -- ROCKS
http://www.youtube.com/watch?v=RZ4Sn-Y7AP8#t=2049
Re: Zeroing buffers is insufficient
#4It's becoming gradually more tempting to write a crypto library in assembly language, because at least then, it says exactly what it's doing. Alas, microcode, and unreadability, and the difficulty of going from a provably correct kind of implementation all the way down to bare metal by hand. The proposed compiler extension, however, makes sense to me. Let's get it added to LLVM & GCC?
That works for well-defined ISAs (like ARM), but not for those with undocumented pipelines, or instructions defined by practise (like x86 and amd64).
In other words, if you write a crypto library in x86 assembler, Intel don't guarantee that they won't introduce a side channel in their next chip model or stepping.
Re: Zeroing buffers is insufficient
#5Excellent point! I really hope such a sensible suggestion is added to mainstream compilers asap and blessed in future standards.
Apologies to everyone suffering Mill fatigue, but we've tried to address this not at a language level but a machine level.
As mitigation, we have a stack whose rubble you cannot browse, and no ... No registers!
But the real strong security comes from the Mill's strong memory protection.
It is cheap and easy to create isolated protection silos - we call them "turfs" - so you can tightly control the access between components. E.g. you can cheaply handle encryption in a turf that has the secrets it needs, whilst handling each client in a dedicated sandbox turf of its own that can only ask the encryption turf to encrypt/decrypt buffers, not access any of that turf's secrets.
More in this talk http://millcomputing.com/docs/security/ and others on same site.
Re: Zeroing buffers is insufficient
#6I 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?
Re: Zeroing buffers is insufficient
#7"As with "anonymous" temporary space allocated on the stack, there is no way to sanitize the complete CPU register set from within portable C code"
I don't know enough of modern hardware, but on CPUs with register renaming, is that even possible from assembly?
I am thinking of the case where the CPU, instead of clearing register X in process P, renames another register to X and clears it.
After that, program Q might get back the old value of register X in program P by XOR-ing another register with some value (or just by reading it, but that might be a different case (I know little of hardware specifics)), if the CPU decide to reuse the bits used to store the value of register X in P.
Even if that isn't the case, clearing registers still is fairly difficult in multi-core systems. A thread might move between CPUs between the time it writes X and the time it clears it. That is less risky, as the context switch will overwrite most state, but, for example, floating point register state may not be restored if a process hasn't used floating point instructions yet.
Re: Zeroing buffers is insufficient
#8It very much looks like a situation in which the system has already been compromised and is running malicious programs that it shouldn't. These malicious programs could still face the hurdle of being held at bay by the permission system that prevents them from reading your key file.
However, they could indeed be able to circumvent the permission system by figuring out what sensitive data your program left behind in uninitialized memory and in CPU registers.
Not leaving traces behind then becomes a serious issue. Could the kernel be tasked with clearing registers and clearing re-assigned memory before giving these resources to another program? The kernel knows exactly when he is doing that, no?
It would be a better solution than trying to fix all possible compilers and scripting engines in use. Fixing these tools smells like picking the wrong level to solve this problem ...
Re: Zeroing buffers is insufficient
#9WRT the AESNI leaking information in the XMM registers, wouldn't starting a fake AES decryption solve the problem?
Also, wouldn't a wrapper function that performs the AES decryption and then manually zeroes the registers be a good enough work around?
Re: Zeroing buffers is insufficient
#10I 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?
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.