From owner-freebsd-security@FreeBSD.ORG Sat Feb 21 01:26:36 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 7D8D4DAC for ; Sat, 21 Feb 2015 01:26:36 +0000 (UTC) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 38F6397E for ; Sat, 21 Feb 2015 01:26:36 +0000 (UTC) Received: by mail-oi0-f42.google.com with SMTP id h136so5550989oig.1 for ; Fri, 20 Feb 2015 17:26:35 -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 :content-type; bh=4I0q/wqirstYgyKV/ujgF0C0RGvW8vsob+4jZ3jHn3A=; b=gpcwrqLZxhd/q9smYo/wFsrogHmZ81L5PbNG8yfATUcVuU0BWy21nsDqUdFixgj2/p ybHwwXr302q5DNPv0EcedwDFVhXuzvZkgD7MGaCOM8unZrvn2tTgjIKWB2zSFEPckTu5 o0BqIKn5sEfc22qfUIX93BM6pfEU+YpJ0FBjlwjuLnOA469OabYxgCj33Ep/B4FLam6T a8TmABeQcQ4TFm3f/Zllp5mKGgXxRIraSGO5bz3pSv8t6DUYT0oDhlxbVdcWGC7eUEpx lrMHq/FKv0fsxXf41EO+dMsLZCKGYSOYL0dnpoERWx0DmyOVlNsLRvfGksJq/SvD580v Bfow== MIME-Version: 1.0 X-Received: by 10.60.141.41 with SMTP id rl9mr335723oeb.31.1424481995558; Fri, 20 Feb 2015 17:26:35 -0800 (PST) Received: by 10.60.140.199 with HTTP; Fri, 20 Feb 2015 17:26:35 -0800 (PST) In-Reply-To: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> Date: Fri, 20 Feb 2015 20:26:35 -0500 Message-ID: Subject: Re: [Cryptography] trojans in the firmware From: grarpamp To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 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: Sat, 21 Feb 2015 01:26:36 -0000 These were the links I was referring to that never made it past moderation/spam... > 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. > Karl Denninger saith: > 1. The BIOS (which reads the boot sector) has not been compromised. > 2. Once the drive code has been tampered with These cases were addressed earlier... " Obviously. This is only meant to help protect clean systems, or prevent subsequent malicious commands if they happen to go through a user to firmware path that has for some reason not yet been compromised (say through the usual /dev to driver to hardware path). 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. " > how many of these attacks are going to be loaded into your machine > through a _*running*_ modern BSD-style system? These for starters, then all the public hacker malware versions of the same thing both extant and coming... https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-iratemonk.jpg https://www.schneier.com/blog/archives/2014/02/swap_nsa_exploi.html http://leaksource.files.wordpress.com/2013/12/nsa-ant-swap.jpg http://leaksource.files.wordpress.com/2013/12/nsa-ant-sierramontana.jpg http://25zbkz3k00wn2tp5092n6di7b5k.wpengine.netdna-cdn.com/files/2015/02/Equation_group_questions_and_answers.pdf > I suspect the answer is > "few" and a false sense of security is worse than none at all. Defense in depth is not a false defense, even when thrown at the few. Given a clean system, the ability to block these opcodes would seem defensive.