Date: Sat, 23 Feb 2008 22:32:02 +0300 From: Eygene Ryabinkin <rea-fbsd@codelabs.ru> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: hackers@freebsd.org, Pieter de Boer <pieter@thedarkside.nl>, Atom Smasher <atom@smasher.org> Subject: Zeroing sensitive memory chunks [Was: Security Flaw in Popular Disk Encryption Technologies] Message-ID: <CHndeNGUDnyFiyFuhzNdulGXPe8@nE9n69L2PrcQKa%2Be6OgU6kZtlVg> In-Reply-To: <20080223185620.GA98105@eos.sc1.parodius.com> References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeremy, list, good day. Sat, Feb 23, 2008 at 10:56:20AM -0800, Jeremy Chadwick wrote: > > A possible counter-measure would be to add wiping features to the RAM > > modules themselves. When power is lost, the memory could wipe itself. Still > > not perfect, but would certainly help. > > Proper software should be memset() or bzero()'ing memory space it > mallocs. I've gotten in the habit of doing this for years, purely as a > safety net. If said software doesn't do this, it's very likely > succeptable. > > So the OP's question about ELI/GELI stands -- does it properly zero out > memory it allocates before using it? Excuse me, but I think that you're confusing two things: zeroing or, generally, initializing memory before the first use (it what is you're talking about) and sanitizing sensitive data like passwords and keys after they were used (it is what OP was talking about). The answer to the original question: yes, geli module cleans all keys and passphrases after use with bzero(). As it was mentioned, this will not help you, if you have your geli-encrypted partition mounted and someone performs the attack by replugging the power and dumping the memory image. But there is another concern with bzero(): it is well-known function. Especially for compilers. And it is bad: some arrays inside g_eli, that hold decryption keys are the local variables. And they are not used after the final bzero() call, so optimizing compiler can eliminate the bzero() completely, as the "not relevant". I don't know if GCC does it -- I should check and will do this tomorrow, because it is already too late in Russia for this day ;)) For example, OpenSSL has the OPENSSL_cleanse() function whose purpose is two-fold (from http://cvs.openssl.org/chngview?cn=9301): ----- *) New function OPENSSL_cleanse(), which is used to cleanse a section of memory from it's contents. This is done with a counter that will place alternating values in each byte. This can be used to solve two issues: 1) the removal of calls to memset() by highly optimizing compilers, and 2) cleansing with other values than 0, since those can be read through on certain media, for example a swap space on disk. [Geoff Thorpe] ----- The '1)' is what I was talking about. '2)' is not very clear to me now, I should research what Geoff meant. If anyone has an idea, please comment. May be the crypto(4,9) framework should receive the function, that will be simular to the OPENSSL_cleanse. And that function should be used for wiping of the sensitive data. Will try to post an update once it will be more clear to me. -- Eygene
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CHndeNGUDnyFiyFuhzNdulGXPe8>