From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 26 19:49:41 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 36CBD1065672; Tue, 26 Feb 2008 19:49:41 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id D69D113C455; Tue, 26 Feb 2008 19:49:40 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:X-Spam-Status:Subject; b=pD8TR1CjRB9C3sSzWfVTbPtGnEGNyl0XjdirWpmsDCiBAPKhwTbKJNvNBPzgLjqq4sM3thv2fRWWjgH8o6YTXOfuV0uR6ok8jWQ0KttAhkBk44sWMk/m2b0/jCa56CsKVTOdKUHQb7wI62R2cxtPDjLmsE4EYDrylaj6NesXHxs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JU5o3-000GaV-8B; Tue, 26 Feb 2008 22:49:39 +0300 Date: Tue, 26 Feb 2008 22:49:37 +0300 From: Eygene Ryabinkin To: gregoryd.freebsd@free.fr Message-ID: References: <20080223010856.7244.qmail@smasher.org> <47C068B5.2090000@thedarkside.nl> <20080223185620.GA98105@eos.sc1.parodius.com> <1204051337.47c45d89ea6eb@imp.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1204051337.47c45d89ea6eb@imp.free.fr> Sender: rea-fbsd@codelabs.ru X-Spam-Status: No, score=-1.7 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_50 Cc: Jeremy Chadwick , hackers@freebsd.org, Pieter de Boer , Atom Smasher Subject: Re: Zeroing sensitive memory chunks [Was: 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: Tue, 26 Feb 2008 19:49:41 -0000 Gregory, good day. Tue, Feb 26, 2008 at 07:42:17PM +0100, gregoryd.freebsd@free.fr wrote: > Quoting Eygene Ryabinkin : > > > *) 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. > > I thought it might mean that on certain media, such as disks, data > can be read even after it has been overwriten a certain number of > times (magnetic properties of the media, this is a method used by > some police labs to recover lost data, I've been told, but maybe > the man was just a paranoid). So even "cleansing" a crypted swap > space this way would not render it safe (you would have to repeat > it enough times so that the layers are definitively overwritten) Yes, Geoff just responded to my private question: it was Peter Gutmann, who pointed him to the thing you're talking about. There is a paper by Peter, http://www.usenix.org/publications/library/proceedings/sec96/full_papers/gutmann/ I still don't understand how cleaning of a memory area will help to clean the swapped page, but may be there are some systems which will update the swapped page on the memory access. May be this even called 'read-through' -- I really don't know. Perhaps this will help for the memory-mapped files, but may be not: the system's write cache can collapse many successive overwrites to just one. The mmap'ped files are using the write cache, aren't they? Thanks for the comment! -- Eygene