From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 02:04:53 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 82BC613D for ; Thu, 19 Feb 2015 02:04:53 +0000 (UTC) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by mx1.freebsd.org (Postfix) with ESMTP id 3FEA9773 for ; Thu, 19 Feb 2015 02:04:52 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=pipeline.com; b=IVEOhepchd6cOM6yZ8Av/0M/NRUCxPewXw1TMyanXW/LT+v139hX+oi8HMqrMpdm; h=Received:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP; Received: from [70.109.44.99] (helo=A.pipeline.com) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1YOGNA-0004BG-UT; Wed, 18 Feb 2015 20:57:49 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 18 Feb 2015 17:57:40 -0800 To: grarpamp From: Henry Baker Subject: Re: [Cryptography] trojans in the firmware In-Reply-To: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: X-ELNK-Trace: 1ae2556e383722335a792f37df7f8ca8b65b6112f89115372cff9eeb3f9308788d00a74a5e21bdd6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 70.109.44.99 X-Mailman-Approved-At: Thu, 19 Feb 2015 04:17:29 +0000 Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, cryptography@metzdowd.com X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2015 02:04:53 -0000 At 03:12 PM 2/18/2015, grarpamp wrote: >On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell wrote: >> The critical stage is the boot ROM (BIOS) and the boot device. >> Once Linux has booted a lot is possible but too much has already taken place. >> A BIOS that allows booting from a Flash memory card must be trusted. >> >> Virtual machines may help or hinder. >> >> The VM is sitting where the man in the middle wants to be and if it wants can protect or expose >> the OSs that it hosts. A VM can protect a hard drive from being infected by blocking vendor >> codes that might try to update or corrupt modern disks of boot flash memory. > >Afaik, all vm's today simply pass through all drive commands. > >It seems a move all the BSD's and Linux could make today, >without waiting on untrustable hardware vendors to roll out signature >verification in hardware, is to simply kernel block all commands >unnecessary to actual production use of the disk. Permit only >from a list of READ, WRITE, ERASE, INQ, TUR, RST, and so on. >Thus every other command component, including firmware update, >vendor specific, and binary fuzzing, gets dropped and logged. ???? If the disk drive or flash drive firmware has already been compromised, none of this will work, because the firmware simply waits for the appropriate "legitimate" read & write commands, and does its thing. BTW, what happens with "emulated" disks -- e.g., .vdi files -- in vm's ? Presumably these emulated disks have no firmware to update, so any attempt would either be ignored or crash the system.