Date: Sat, 23 Feb 2008 14:33:16 -0600 From: Brooks Davis <brooks@freebsd.org> To: Tim Clewlow <tim1timau@yahoo.com> Cc: hackers@freebsd.org Subject: Re: Security Flaw in Popular Disk Encryption Technologies Message-ID: <20080223203316.GC38485@lor.one-eyed-alien.net> In-Reply-To: <760775.85636.qm@web50306.mail.re2.yahoo.com> References: <47C06E1F.5020308@thedarkside.nl> <760775.85636.qm@web50306.mail.re2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 23, 2008 at 11:24:22AM -0800, Tim Clewlow wrote: >=20 > --- Pieter de Boer <pieter@thedarkside.nl> wrote: >=20 > > Jeremy Chadwick wrote: > >=20 > > > It's interesting that you classified this as a "feature" (in quotes), > > > because there's nothing "modern" about said "feature". This issue has > > > existed since the beginning of RAM chip engineering; I can even confi= rm > > > this "feature" exists on old video game consoles such as the Nintendo > > > and Super Nintendo (where there were strict guidelines put in place by > > > Nintendo, requiring developers to initialise certain areas of memory > > > and certain memory-mapped I/O registers during hard or soft resets). > > I shouldnt've used the word 'modern', then. > >=20 > > > 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. > > That is not relevant to the issue. The issue is that the keys are in=20 > > memory when the encrypted filesystem is in use. The keys can be read by= =20 > > pulling and reinserting the power plug and restarting into a tool that= =20 > > can dump memory (or by placing the memory modules in another system).= =20 > > The keys to encrypted volumes can be found in this dump, leading to a= =20 > > compromise of the data. >=20 > Many BIOS have fast and slow boot options - they are usually set to fast = by > default. The slow boot option often checks RAM and effectively wipes RAM = in the > process. If the BIOS is password protected then the only way to break in = is to > reset the BIOS by removing the BIOS battery. Given that RAM degrades over= a > short period of no power, and that arranging to physically pull the BIOS > battery most likely exceeds that time limit, then this would effectively = be one > solution. Although it will mean always booting the slow way. You should actually read the paper. :) They successfully defeat both of these type of protections by using canned air to chill the ram and transplanting it into another machine. -- Brooks --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFHwIMLXY6L6fI4GtQRApg1AJ9hyAz37r85t4gy1rGjq1LR/m8jvQCdGzjv AVwa5cDFYE5Gq0EWkYMJOgM= =Gwfr -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080223203316.GC38485>