Security Flaw in Popular Disk Encryption Technologies

Brooks Davis 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.

-- Brooks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
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 mailing list