From owner-freebsd-security@FreeBSD.ORG Wed Feb 18 23:12:08 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB0895C9 for ; Wed, 18 Feb 2015 23:12:08 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 69AB7EAC for ; Wed, 18 Feb 2015 23:12:08 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wo20so8311628obc.7 for ; Wed, 18 Feb 2015 15:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xzWfeosoLq+RSMwKZK+198mu/CLk9cQCs02jUbUq/Bg=; b=H0eqgUb6wQKZLuvZdjr/eg3fsw11EmPHvCT6+bdtt3VkQTo8IhBAirmxr2eXxOb5MF AKP7z/61kavGsiVueuGIIZ+y1hq1q60RZCjeRgZSG6WDjsg6WBy0+JxTe/Pobapx+8AN 9bO//a6oWkgMD9n0m3vvOlYTaMOkbc/Z/irGot+U69F1q2oChxjEPuVWUy8k+edLu4Rx Z75F/yjFjddA+OAtnlNUo/8XAhcSA6H+q/zK0mmFO4cVnWOcS3Pe1tEiNZOSdrfHso60 Tyl3S4L0KcVspHTFL8PI2is4MMGfGt6gJqF10/kJiAN3xzoZVuPk0fKx5NFBgvjmK8AS fMWg== MIME-Version: 1.0 X-Received: by 10.202.46.138 with SMTP id u132mr1020696oiu.19.1424301127814; Wed, 18 Feb 2015 15:12:07 -0800 (PST) Received: by 10.60.140.199 with HTTP; Wed, 18 Feb 2015 15:12:07 -0800 (PST) In-Reply-To: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> Date: Wed, 18 Feb 2015 18:12:07 -0500 Message-ID: Subject: Re: [Cryptography] trojans in the firmware From: grarpamp To: "cryptography@metzdowd.com" Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 19 Feb 2015 00:00:10 +0000 Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org 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: Wed, 18 Feb 2015 23:12:08 -0000 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. It could be done as a securelevel, or compiled in. It's definitely not bulletproof, but it does force adversaries to add that much more exploit code and effort to get root and go around the driver interface to access the hardware directly. Defense in depth. Similar tactics could be applied to other areas where firmware and vendor/fuzzable opcodes are involved... usb, bios and cpu.