From owner-freebsd-hackers@FreeBSD.ORG Sat Feb 23 19:51:03 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 920CA16A411 for ; Sat, 23 Feb 2008 19:51:03 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: from web50306.mail.re2.yahoo.com (web50306.mail.re2.yahoo.com [206.190.38.60]) by mx1.freebsd.org (Postfix) with SMTP id 536A913C4E7 for ; Sat, 23 Feb 2008 19:51:03 +0000 (UTC) (envelope-from tim1timau@yahoo.com) Received: (qmail 88679 invoked by uid 60001); 23 Feb 2008 19:24:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=S8Y4yR/ysLZUiYJkNQFKItRoQfB9r8jzMuH/chXXe/634rMDKJjzOG45abpQhPpvFQkSne72zM0/OhsnXBHf2deTgXS/OxhZb+cIqNmkqj4yTLyeGosWKxUeuR3J5F1gVnc9npZhMuT2eiIKYxVZH+R/WoDBgT5vi0K0hlofcW8=; X-YMail-OSG: ax_K7jsVM1kPVv_pav4TOPkMivxF7QDoa7kcjd9RPQJkKwXFqUqtySWB7yVHAVEoaQ-- Received: from [210.215.149.194] by web50306.mail.re2.yahoo.com via HTTP; Sat, 23 Feb 2008 11:24:22 PST Date: Sat, 23 Feb 2008 11:24:22 -0800 (PST) From: Tim Clewlow To: hackers@freebsd.org In-Reply-To: <47C06E1F.5020308@thedarkside.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <760775.85636.qm@web50306.mail.re2.yahoo.com> Cc: Subject: Re: Security Flaw in Popular Disk Encryption Technologies X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 19:51:03 -0000 --- Pieter de Boer 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. Tim. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs