From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 04:13:19 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 740215D1 for ; Thu, 19 Feb 2015 04:13:19 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 3A9BC644 for ; Thu, 19 Feb 2015 04:13:19 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id vb8so10229229obc.12 for ; Wed, 18 Feb 2015 20:13:18 -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=OzqTVkNGDX8RHopPuwqP2TvUgc/0sFwkBppQHZJW18o=; b=OUgNF38OJYimIsw/PPH8w1JVLG/9ymXi3BMchFRQ7C6IU1fFEV53JsI909rDg4rEpz C2sB5qJKuiy+LkLf8SIXaBoZBCsz5OKVl1QLm+XugAPLYaTgZDTeE0G34XNgjHzGghiu hUvo8BK84ILOJBdkXc2ok1Qp+lIC9ekcToUK9Kysb8S+rZUn/1zX3jOxVMtI2kNOGn1n ZAInT068M6R0x0yPG1XTyMH7++3txdox58WTkLxunHSLxQf0HIpaUaCEfidzwPFf2Xwh fPuOcB7VdZ7Rch5a/lNrVfP+WKKW/mFUyKuEQ4G2r14tkKxDVbQGU06N2X+5V3DJ0HuU WvaA== MIME-Version: 1.0 X-Received: by 10.202.219.215 with SMTP id s206mr1553882oig.114.1424319198426; Wed, 18 Feb 2015 20:13:18 -0800 (PST) Received: by 10.60.140.199 with HTTP; Wed, 18 Feb 2015 20:13:18 -0800 (PST) In-Reply-To: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> Date: Wed, 18 Feb 2015 23:13:18 -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 12:10:58 +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: Thu, 19 Feb 2015 04:13:19 -0000 On Wed, Feb 18, 2015 at 8:57 PM, Henry Baker wrote: > At 03:12 PM 2/18/2015, grarpamp wrote: >>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. Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to kernel path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). > 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. Depends on how the vm is coded. My guess is vm's that emulate say disk devices, munge those opcodes too. Yes, looking at how virtualbox and even lightweight instances like jails code/handle it could be useful. Try it and see :) In all cases, having the logging capability for non production opcodes without having to postfilter them out of some debugging stream would be nice. Obviously again caveat parts of the system that have not been compromised, and defense in depth.