From owner-freebsd-security@FreeBSD.ORG Sun May 18 01:27:17 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02812106566C for ; Sun, 18 May 2008 01:27:17 +0000 (UTC) (envelope-from abi@e-arroyo.net) Received: from ocean.hostingzoom.com (ocean.hostingzoom.com [209.51.135.2]) by mx1.freebsd.org (Postfix) with ESMTP id D20628FC14 for ; Sun, 18 May 2008 01:27:16 +0000 (UTC) (envelope-from abi@e-arroyo.net) Received: from [127.0.0.1] (port=33219 helo=209.51.135.2) by ocean.hostingzoom.com with esmtpa (Exim 4.68) (envelope-from ) id 1JxWxd-0006iA-8s for freebsd-security@freebsd.org; Sat, 17 May 2008 19:41:13 -0500 Received: from 75.36.168.192 ([75.36.168.192]) (SquirrelMail authenticated user abi@e-arroyo.net) by 209.51.135.2 with HTTP; Sat, 17 May 2008 17:41:13 -0700 (PDT) Message-ID: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> Date: Sat, 17 May 2008 17:41:13 -0700 (PDT) From: "Abiron Arroyo" To: freebsd-security@freebsd.org User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ocean.hostingzoom.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - e-arroyo.net Subject: Vulnerability with compromised geli credentials? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: abi@e-arroyo.net List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 01:27:17 -0000 I'm not really a developer, but was considering if there is a key vulnerability in geli given that when you change a key there isn't a disk update. Consider the scenario where a new file system is created and populated with some files. At a later time the original key is changed because someone has gained access to the key and passphrase. A new key is generated and attached, but none of the files are modified. Furthermore, let's say the thief has access to the system and is able to update the disk to use the previous key and then reattach/mount. Is it then possible for the person that has the stolen credentials to mount the drive and view the files? The man page does not detail how the metadata is written. With that said, if this is possible, what's the best way to update the system? I suspect that moving the file is not enough, using vi in a script is not very practical, and using cat may cause problems with some special characters. From owner-freebsd-security@FreeBSD.ORG Sun May 18 12:30:18 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B4CF106567A for ; Sun, 18 May 2008 12:30:18 +0000 (UTC) (envelope-from robert.woolley@rwoolley.com) Received: from turtle-out.mxes.net (turtle-out.mxes.net [216.86.168.191]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7498FC25 for ; Sun, 18 May 2008 12:30:18 +0000 (UTC) (envelope-from robert.woolley@rwoolley.com) Received: from mxout-03.mxes.net (mxout-03.mxes.net [216.86.168.178]) by turtle-in.mxes.net (Postfix) with ESMTP id 036AD163F59 for ; Sun, 18 May 2008 08:18:51 -0400 (EDT) Received: from gumby.homeunix.com. (unknown [87.81.140.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 456F423E3F6; Sun, 18 May 2008 08:18:49 -0400 (EDT) Date: Sun, 18 May 2008 13:18:46 +0100 From: Robert Woolley To: freebsd-security@freebsd.org Message-ID: <20080518131846.375f85aa@gumby.homeunix.com.> In-Reply-To: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> References: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> X-Mailer: Claws Mail 3.4.0 (GTK+ 2.12.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 18 May 2008 12:31:52 +0000 Cc: abi@e-arroyo.net Subject: Re: Vulnerability with compromised geli credentials? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 12:30:18 -0000 On Sat, 17 May 2008 17:41:13 -0700 (PDT) "Abiron Arroyo" wrote: > > I'm not really a developer, but was considering if there is a key > vulnerability in geli given that when you change a key there isn't a > disk update. > > Consider the scenario where a new file system is created and populated > with some files. At a later time the original key is changed because > someone has gained access to the key and passphrase. A new key is > generated and attached, but none of the files are modified. > The data is encrypted with a random master-key that's generated during the init stage. That key is itself encrypted with a user-key generated from the passphrase and keyfile, and the encrypted masterkey is stored on the disk. The master-key itself is never changed; if the new files were encrypted with a different key you wouldn't be able to read the old ones. From owner-freebsd-security@FreeBSD.ORG Tue May 20 10:05:13 2008 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A2421065679 for ; Tue, 20 May 2008 10:05:13 +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 1DE0C8FC12 for ; Tue, 20 May 2008 10:05:13 +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:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=OEwHYcxwyHe7bbRwfFkjxLyoHk+2A936wxmgnfw/hXFO+1ZpTovyzfEM7iAwu2G8if0DJ5crJRRj1QTdJUC/yVloyWPgAmo0AuOrtdDd66pOJj1X19p0LK2cgXRfL3PzCP1XOcdw9PB0XLIZ8xOZ+rVdKlDO9PXRLRVczk0hMYs=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JyOVk-000ME5-5a; Tue, 20 May 2008 13:52:00 +0400 Date: Tue, 20 May 2008 13:51:59 +0400 From: Eygene Ryabinkin To: Abiron Arroyo Message-ID: References: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <39408.75.36.168.192.1211071273.squirrel@209.51.135.2> Sender: rea-fbsd@codelabs.ru Cc: freebsd-security@freebsd.org, pjd@freebsd.org Subject: Re: Vulnerability with compromised geli credentials? X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 May 2008 10:05:13 -0000 Abiron, good day. Sat, May 17, 2008 at 05:41:13PM -0700, Abiron Arroyo wrote: > I'm not really a developer, but was considering if there is a key > vulnerability in geli given that when you change a key there isn't a disk > update. > > Consider the scenario where a new file system is created and populated > with some files. At a later time the original key is changed because > someone has gained access to the key and passphrase. A new key is > generated and attached, but none of the files are modified. There were a simular thread at SecurityFocus, related to the PGP disk encryption products: http://www.securityfocus.com/archive/1/435007/30/0/threaded > Furthermore, let's say the thief has access to the system and is able to > update the disk to use the previous key and then reattach/mount. Is it > then possible for the person that has the stolen credentials to mount the > drive and view the files? If you possess the Master Key that actually used for the encryption, then yes. The passphrase you're entering to attach geli volume is just used to encrypt that master key on the disk. > The man page does not detail how the metadata is written. Probably the manual should be updated to say something about the process of encryption and some neats about it. > With that said, if this is possible, what's the best way to update the > system? I suspect that moving the file is not enough, using vi in a script > is not very practical, and using cat may cause problems with some special > characters. The best way is to get the second, virgin geli volume with uncompromised master key and copy data to that volume. In theory, one can reencrypt the data on the geli volume with the new master key, but this can be error-prone: if process is interrupted, some part of the disk will be encrypted with the old key and one -- with the new one. This can be overriden if geli will be extended to be able to handle two keys at once: try the first one and then the second one. So the scenario for the reencryption with new master key is the following: a. new master key is created, encrypted and saved in some location within the metadata; b. geli starts to reencrypt the disk contents; c. if the process is interrupted, then geli will see two keys on the next attachment and will be able to operate and continue the reencryption. d. when reencryption completes, new master key is dropped to the regular place and it is wiped from the secondary location. I thought about adding such functionality to geli some time ago, but I had no time to implement it, so I was stuck to the second, virgin geli volume. I vaguely recall that pjd@ was mentioning some script or program that was able to really reencrypt the disk, changing the master key. But I may be wrong. Pawel, what do you think, will there be a place for a secondary master key? As I understand, the encryption is done with a non-chained mode (counter?), so the disk that is partially encrypted with the new and partially with the old key should not pose any problems with the case of authenticated geli volume (we can check if decryption was working, so we can run two passes on the block with different passwords). With unauthenticated geli one can put the counter of already reencrypted block somewhere to the metadata. Potentially, this is not worse than the authenticated case: if power fails during reencryption and the counter will not be updated for the recent block(s), then it will be the same badness as for authenticated case: blocks can be reencrypted, but the authentication data can not be written to the disk. Though, the complete reencryption will be very error-prone process and can lead to data loss, so I would stick to two different disks and/or volumes to prevent any old data overwrites before the new data will be written and validated. -- Eygene