From owner-freebsd-security@FreeBSD.ORG Sun Feb 22 10:44:27 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 B5F69792; Sun, 22 Feb 2015 10:44:27 +0000 (UTC) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 67A3AC8B; Sun, 22 Feb 2015 10:44:27 +0000 (UTC) Received: by mail-oi0-f53.google.com with SMTP id u20so9359625oif.12; Sun, 22 Feb 2015 02:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=5bTmRMMzWxCy9BNX0El8108LCPylMOfAaV9Pj4AWGB4=; b=PSJCQSyi0uelGFudkoSnpcE/1BrZtHznD1mQSlFAgu4M1QpR4lRGdjATbsLCQ6YXe2 E/pr03vkJLnvg6YxSENZ//rFZfJlI3VNCOtfC56MbihjiD/KP/no6IoeaIE24Ql5Qa2F 83MxB7xltqgxaE+FtMsU2D6BSkvkEjm0ZSSTzPwO1I0K3A+r1oYgb0HqkqUadvYbl049 tEYGZ2sBynftIrUCZNN6rOox88ty8hSWj3D8LX0nHki8B+vgAQdGIw5jDG5K1GTPNMdd DV4McaehCGFVzW6Y3pr0SS7eUuh58+rmjbqGswZassz5Bb7GKxTz/jVsJOIhi1qt8z5M 18Dw== MIME-Version: 1.0 X-Received: by 10.60.133.174 with SMTP id pd14mr3993951oeb.79.1424601866636; Sun, 22 Feb 2015 02:44:26 -0800 (PST) Received: by 10.60.140.199 with HTTP; Sun, 22 Feb 2015 02:44:26 -0800 (PST) Date: Sun, 22 Feb 2015 05:44:26 -0500 Message-ID: Subject: trojans in the firmware From: grarpamp To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-questions@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: Sun, 22 Feb 2015 10:44:28 -0000 On Sat, Feb 21, 2015 at 8:41 AM, Kay Rydyger : Please do not quote 200 lines of text just to insert your ten. And if using the digest, use the original subject line. Else it's lazy bad form at the expense of other readers of the list. >> > Alfred Hegemeier saith: >> > just encrypt the whole hard drive with Geli. >> >> GELI works under your control for what you store on the >> drive, and you can even enable the AES encryption feature >> of the drive itself as a no cost to performance extra freebie >> underneath that. However since the raw device interface is still >> accessible, neither of them do anything to block firmware >> updates. > what has blocking firmware updates to do with > firmware being able to read the data passing > through the controller ? Reread the entire thread and all the linked materials. If your drive is clean and you kernel block the malicious firmware update command, the exploit fails and your drive remains clean. If you don't block it, then your drive gets rooted and then yes, there's nothing you can do after that. And since users don't have JTAG gear/skills and device vendors usually never publish a firmware update anyway, you can't verify or securely reflash even if you did discover it got rooted. Thus you now own a worthless brick with a warranty that won't be honored. > That encryption is a good line of defense, you can > read here: > https://www.ibr.cs.tu-bs.de/users/kurmus/papers/acsac13.pdf > in section 4.1. No hardware and software disk encryption themselves don't prevent installation of the firmware, nor help much afterwards given the current as yet non-ideal state of the entire system protection/crypto ecosystem. The MBR, boot, loader and whatever other early stages, are not encrypted or signed... malicious firmware can exploit that. It could also use DMA to read/write RAM to get your FDE keys and so on. Even SecureBoot with FDE doesn't help there. It's all caveated in the doc. To be more secure you need to disallow the malicious firmware update from taking place to begin with. The standard interface for that is through the /dev device provided by the disk driver over the bus subsystem. Block/filter out all non-production opcodes from those interfaces and and it becomes more work for kids to exploit. Add that to other defenses in depth and you're better off. Long term, you should demand the vendors include a $0.10 hardware read-only update jumper and a signed authority root anchored in the mask ROM. You should demand the t10/t11/t13/serialata standards bodies include a readout command for firmware verification and backup. For that matter, you should demand vendors include another jumper for pointing to your own installable ROM space in flash (or via pin header) and to also open up their specs so you don't have to use their literally stupid and broken firmware blobs [1]. How many tens of thousands of users strong are you BSD? How many tens of thousands of users strong is Linux? Yet all of you combined can't seem to place even two calls/mails per month to each vendor asking for these things... shame. You can and should be overloading their switchboards... they'd drop to their knees before your armies in a week. [1] Vendor code is generally buggy crap quality, quite often highly guarded just to save embarassement there, to dodge responsibility for making fixes by saying "what bugs, where", and to speed up obsolesense.