Security Flaw in Popular Disk Encryption Technologies
brooks at freebsd.org
Sat Feb 23 20:33:18 UTC 2008
On Sat, Feb 23, 2008 at 11:24:22AM -0800, Tim Clewlow wrote:
> --- Pieter de Boer <pieter at thedarkside.nl> wrote:
> > Jeremy Chadwick wrote:
> > > 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 confirm
> > > 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.
> > > 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
> > memory when the encrypted filesystem is in use. The keys can be read by
> > pulling and reinserting the power plug and restarting into a tool that
> > can dump memory (or by placing the memory modules in another system).
> > The keys to encrypted volumes can be found in this dump, leading to a
> > compromise of the data.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20080223/69d33a17/attachment.pgp
More information about the freebsd-hackers