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. 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. 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. From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 12:53:11 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 0D0DD24A for ; Thu, 19 Feb 2015 12:53:11 +0000 (UTC) Received: from nm14-vm6.bullet.mail.ne1.yahoo.com (nm14-vm6.bullet.mail.ne1.yahoo.com [98.138.91.107]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C27D8C6 for ; Thu, 19 Feb 2015 12:53:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1424350242; bh=fLSbP8NCdV7MCkwEXYxNUkyCGSFfooal6orIHKQ5Gug=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=PMAcPij9RfCTe5Bjhx5rSfxRr0Ss3RVqqFxw0NNZz6l3i/wdLRfPFYR26i+U7W+cuHGuy619ElyPI5b+PvA3On4h9DMEFiy/AYadrwpOlBGt7yRiStYV0KZ1tA6ZZ8hEDSSCUbOt8DyihU21W15212ATZpD4JylAt8Oh19uhwOWTCF78tkG/hgdm0wd5YFbw6xeH7CdVa3mLlXEXTqcaeEEnmPqM/326C32OvZyeaSYDgb09h78xVk+EFHvu6Q8X572L7kAm59QM13CcUkmxp6/NzpiBFOamqPfuCEwoEuqbJmdSaAxNN2LBqF5ljyaGkejuiyYp29R4/zKeeVUk+Q== Received: from [98.138.100.102] by nm14.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2015 12:50:42 -0000 Received: from [212.82.98.87] by tm101.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2015 12:50:41 -0000 Received: from [127.0.0.1] by omp1024.mail.ir2.yahoo.com with NNFMP; 19 Feb 2015 12:50:41 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 450376.63462.bm@omp1024.mail.ir2.yahoo.com X-YMail-OSG: hcvKhFkVM1lzT.9JfYTbqn4kdv8M1.LjvT8uVugVQJfJIwK9uelb0vWyajNytVL arepnSOy13VE1xv_eNISTHy_tYDH1V635TJzvCWpcoiE7MKT6CWdlu4WOM8hznIrk1a33eGClPQG yk5qPIOsDmlW8yt3wvPLeoRx3V45W9wUymRkZQ7TIvLQ8aOEM9IBRTCShT7eJ4l7ayDGjfhr2Y.6 agrdwA6i7fchjshRI43Dd8aomCClhXOIpfY7yai1NWjUf_5nO8IuHvq_YyEC5pM2UK6HwAX108V7 YHLc1vARuOopGh5wTp6pde0Nm1JdBy2vZn24B1rI867B75SJWA2iyGS56N77Mz1AB.vzMcBonvUL 6staxyga1zj9QKgtGVF6wdbLw4rv2EGuVjamIyt7Ktw70TWgJI42bHk_UGdZUEC8jx17xzLXvd9K KzXIX.YoVK.aPCD78.ekANVgZ4op.3Xc5dnhcSw3rI.Ej4_ux52VdHhRxObi6yfRsSr_inEd5rdy _mfQ.UzrFtUtZdXU- Received: by 217.12.9.8; Thu, 19 Feb 2015 12:50:40 +0000 Date: Thu, 19 Feb 2015 12:50:40 +0000 (UTC) From: Alfred Hegemeier Reply-To: Alfred Hegemeier To: "freebsd-security@freebsd.org" Message-ID: <2128122602.2736874.1424350240576.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: Subject: Re: freebsd-security Digest, Vol 522, Issue 1 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 19 Feb 2015 13:51:49 +0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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 12:53:11 -0000 just encrypt the whole hard drive with Geli. That's the only protection I see: everything passing through the controller= s is encrypted - unless keyloggers are installed, which you best protect ag= ainst completely firewalling the "core" system, andhaving jails to access t= he outer world. PCbsd already dumped complete auto hard drive encryption in their latest pr= oducts - the automatic full HD encr was dumped when the Snowden stuff was r= evealed, I think with 10 release.So, I guess, they know why they removed it= - makes it to secure. Which brings up an important question: how 'safe' is the encryption Geli, i= .e. how can we know that developers are not on any agencies pay list ?Does = that make sense=C2=A0 what I am writing in your opinion ? greetings. From: "freebsd-security-request@freebsd.org" To: freebsd-security@freebsd.org=20 Sent: Thursday, 19 February 2015, 13:00 Subject: freebsd-security Digest, Vol 522, Issue 1 =20 Send freebsd-security mailing list submissions to =C2=A0=C2=A0=C2=A0 freebsd-security@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit =C2=A0=C2=A0=C2=A0 http://lists.freebsd.org/mailman/listinfo/freebsd-securi= ty or, via email, send a message with subject or body 'help' to =C2=A0=C2=A0=C2=A0 freebsd-security-request@freebsd.org You can reach the person managing the list at =C2=A0=C2=A0=C2=A0 freebsd-security-owner@freebsd.org When replying, please edit your Subject line so it is more specific than "Re: Contents of freebsd-security digest..." Today's Topics: =C2=A0 1. Re: [Cryptography] trojans in the firmware (grarpamp) =C2=A0 2. Re: [Cryptography] trojans in the firmware (Henry Baker) ---------------------------------------------------------------------- Message: 1 Date: Wed, 18 Feb 2015 18:12:07 -0500 From: grarpamp To: "cryptography@metzdowd.com" Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org Subject: Re: [Cryptography] trojans in the firmware Message-ID: =C2=A0=C2=A0=C2=A0 Content-Type: text/plain; charset=3DUTF-8 On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell wrote: > The critical stage is the boot=C2=A0 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.=C2=A0 A VM can protect a hard drive from being inf= ected > by blocking vendor > codes that might try to update or corrupt modern disks of boot flash memo= ry. 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. ------------------------------ Message: 2 Date: Wed, 18 Feb 2015 17:57:40 -0800 From: Henry Baker To: grarpamp Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, =C2=A0=C2=A0=C2=A0 cryptography@metzdowd.com Subject: Re: [Cryptography] trojans in the firmware Message-ID: Content-Type: text/plain; charset=3D"us-ascii" 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=C2=A0 ROM (BIOS) and the boot device. >> Once Linux has booted a lot is possible but too much has already taken p= lace. >> 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 want= s can protect or expose >> the OSs that it hosts.=C2=A0 A VM can protect a hard drive from being in= fected by blocking vendor >> codes that might try to update or corrupt modern disks of boot flash mem= ory. > >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. ????=C2=A0 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 ?=C2=A0 Presumably these emulated disks have no firmware to update, so any attempt would either be ignored or crash the system. ------------------------------ Subject: Digest Footer _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" ------------------------------ End of freebsd-security Digest, Vol 522, Issue 1 ************************************************ From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 16:16:02 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 89BEF95B for ; Thu, 19 Feb 2015 16:16:02 +0000 (UTC) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by mx1.freebsd.org (Postfix) with ESMTP id 57A99AA5 for ; Thu, 19 Feb 2015 16:16:01 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=pipeline.com; b=GYKwoOi5vc2tepvkSurjvZix9n0AJt4BjidKTqWmGKObm15apbl9ZKxHxa2D88cT; h=Received:X-Mailer:Date:To:From:Subject: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-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1YOTjj-0004uI-59; Thu, 19 Feb 2015 11:13:59 -0500 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Feb 2015 08:12:41 -0800 To: grarpamp ,cypherpunks@cpunks.org, freebsd-security@freebsd.org,cryptography@metzdowd.com 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: 1ae2556e383722335a792f37df7f8ca8b65b6112f891153790fc6552fcaf67896e6db278222a318a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 70.109.44.99 X-Mailman-Approved-At: Thu, 19 Feb 2015 16:23:00 +0000 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 16:16:02 -0000 I would love to be able to program this device myself, instead of relying on Samsung's firmware. BTW, what's the point of AES encryption on this pre-p0wned device? More security theatre? http://hothardware.com/reviews/samsung-portable-ssd-t1-review Samsung Portable SSD T1 Review: Blazing Fast External Storage Utilizing Samsung's proprietary 3D Vertical NAND (V-NAND) technology and a SuperSpeed USB 3.0 interface, the Portable SSD T1 redlines at up to 450MB/s when reading or writing data sequentially, according to Samsung. For random read and write activities, Samsung rates the drive at up to 8,000 IOPS and 21,000 IOPS, respectively. Capacity 1TB (250GB and 500GB also available) Interface Compatible with USB 3.0, 2.0 Dimensions (W x H x D) 71.0 x 9.2 x 53.2 mm Weight Max. 30 grams Transfer Speed Up to 450MB/sec UASP Mode UASP Mode Encryption AES 256-bit Security Password setting (optional) Certification CE, BSMI,KC, VCC, C-tick, FCC, IC, UL, TUV, CB RoHS Compliance RoHS2 Warranty Limited 3 year Price$569 (street) - Find It At Amazon From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 16:54:07 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 CEC84A1F for ; Thu, 19 Feb 2015 16:54:07 +0000 (UTC) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "NewFS.denninger.net", Issuer "NewFS.denninger.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7846CF20 for ; Thu, 19 Feb 2015 16:54:06 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.9/8.14.8) with ESMTP id t1JGmmlR080992 for ; Thu, 19 Feb 2015 10:48:51 -0600 (CST) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Thu Feb 19 10:48:51 2015 Message-ID: <54E613DE.5090204@denninger.net> Date: Thu, 19 Feb 2015 10:48:30 -0600 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: [Cryptography] trojans in the firmware References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050805090107030104010400" X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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 16:54:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050805090107030104010400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2/18/2015 5:12 PM, grarpamp wrote: > On Wed, Feb 18, 2015 at 5:16 PM, Tom Mitchell wrot= e: >> 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 wa= nts >> can protect or expose >> the OSs that it hosts. A VM can protect a hard drive from being infe= cted >> by blocking vendor >> codes that might try to update or corrupt modern disks of boot flash m= emory. > 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. The basic problem with this is that it makes two assumptions, both of=20 which are dangerous. 1. The BIOS (which reads the boot sector) has not been compromised. If=20 it has been you're hosed. Most if not all BIOS chips are=20 field-programmable today which is both good and bad. It's good when you = want to swap in a newer stepping CPU that wasn't formerly supported,=20 it's bad when someone comes along and tampers with it. Hardware=20 protection (e.g. a physical write-enable jumper on the board) would=20 largely address this in terms of FIELD tampering (although not at the=20 OEM level) but I know of nobody doing that right now. All my SuperMicro = systems, for example, require nothing physical (e.g. a jumper to be=20 installed) to enable a BIOS update. 2. Once the drive code has been tampered with you're in trouble because=20 it is trivial for the drive to detect that the boot sector is being read = and, if it is, to return something other than the real (unmolested) boot = sector. That can then retrieve more corrupted things and now you're cook= ed. I like barrier-protecting the I/O subsystem when running, but then again = how many of these attacks are going to be loaded into your machine=20 through a _*running*_ modern BSD-style system? I suspect the answer is=20 "few" and a false sense of security is worse than none at all. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ --------------ms050805090107030104010400 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFTzCC BUswggQzoAMCAQICAQgwDQYJKoZIhvcNAQEFBQAwgZ0xCzAJBgNVBAYTAlVTMRAwDgYDVQQI EwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM TEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkqhkiG9w0BCQEWIGN1c3Rv bWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0MB4XDTEzMDgyNDE5MDM0NFoXDTE4MDgyMzE5 MDM0NFowWzELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExFzAVBgNVBAMTDkthcmwg RGVubmluZ2VyMSEwHwYJKoZIhvcNAQkBFhJrYXJsQGRlbm5pbmdlci5uZXQwggIiMA0GCSqG SIb3DQEBAQUAA4ICDwAwggIKAoICAQC5n2KBrBmG22nVntVdvgKCB9UcnapNThrW1L+dq6th d9l4mj+qYMUpJ+8I0rTbY1dn21IXQBoBQmy8t1doKwmTdQ59F0FwZEPt/fGbRgBKVt3Quf6W 6n7kRk9MG6gdD7V9vPpFV41e+5MWYtqGWY3ScDP8SyYLjL/Xgr+5KFKkDfuubK8DeNqdLniV jHo/vqmIgO+6NgzPGPgmbutzFQXlxUqjiNAAKzF2+Tkddi+WKABrcc/EqnBb0X8GdqcIamO5 SyVmuM+7Zdns7D9pcV16zMMQ8LfNFQCDvbCuuQKMDg2F22x5ekYXpwjqTyfjcHBkWC8vFNoY 5aFMdyiN/Kkz0/kduP2ekYOgkRqcShfLEcG9SQ4LQZgqjMpTjSOGzBr3tOvVn5LkSJSHW2Z8 Q0dxSkvFG2/lsOWFbwQeeZSaBi5vRZCYCOf5tRd1+E93FyQfpt4vsrXshIAk7IK7f0qXvxP4 GDli5PKIEubD2Bn+gp3vB/DkfKySh5NBHVB+OPCoXRUWBkQxme65wBO02OZZt0k8Iq0i4Rci WV6z+lQHqDKtaVGgMsHn6PoeYhjf5Al5SP+U3imTjF2aCca1iDB5JOccX04MNljvifXgcbJN nkMgrzmm1ZgJ1PLur/ADWPlnz45quOhHg1TfUCLfI/DzgG7Z6u+oy4siQuFr9QT0MQIDAQAB o4HWMIHTMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAsBglg hkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFHw4 +LnuALyLA5Cgy7T5ZAX1WzKPMB8GA1UdIwQYMBaAFF3U3hpBZq40HB5VM7B44/gmXiI0MDgG CWCGSAGG+EIBAwQrFilodHRwczovL2N1ZGFzeXN0ZW1zLm5ldDoxMTQ0My9yZXZva2VkLmNy bDANBgkqhkiG9w0BAQUFAAOCAQEAZ0L4tQbBd0hd4wuw/YVqEBDDXJ54q2AoqQAmsOlnoxLO 31ehM/LvrTIP4yK2u1VmXtUumQ4Ao15JFM+xmwqtEGsh70RRrfVBAGd7KOZ3GB39FP2TgN/c L5fJKVxOqvEnW6cL9QtvUlcM3hXg8kDv60OB+LIcSE/P3/s+0tEpWPjxm3LHVE7JmPbZIcJ1 YMoZvHh0NSjY5D0HZlwtbDO7pDz9sZf1QEOgjH828fhtborkaHaUI46pmrMjiBnY6ujXMcWD pxtikki0zY22nrxfTs5xDWGxyrc/cmucjxClJF6+OYVUSaZhiiHfa9Pr+41okLgsRB0AmNwE f6ItY3TI8DGCBQowggUGAgEBMIGjMIGdMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlk YTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExDMRwwGgYD VQQDExNDdWRhIFN5c3RlbXMgTExDIENBMS8wLQYJKoZIhvcNAQkBFiBjdXN0b21lci1zZXJ2 aWNlQGN1ZGFzeXN0ZW1zLm5ldAIBCDAJBgUrDgMCGgUAoIICOzAYBgkqhkiG9w0BCQMxCwYJ KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTAyMTkxNjQ4MzBaMCMGCSqGSIb3DQEJBDEW BBSYAE2PgZQFi1HfCM5jvnBEfF+qczBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG0BgkrBgEEAYI3EAQxgaYwgaMwgZ0xCzAJBgNV BAYTAlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoT EEN1ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExLzAtBgkq hkiG9w0BCQEWIGN1c3RvbWVyLXNlcnZpY2VAY3VkYXN5c3RlbXMubmV0AgEIMIG2BgsqhkiG 9w0BCRACCzGBpqCBozCBnTELMAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExEjAQBgNV BAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1zIExMQzEcMBoGA1UEAxMTQ3Vk YSBTeXN0ZW1zIExMQyBDQTEvMC0GCSqGSIb3DQEJARYgY3VzdG9tZXItc2VydmljZUBjdWRh c3lzdGVtcy5uZXQCAQgwDQYJKoZIhvcNAQEBBQAEggIAZX2HLXtcOET7ouL+o+6Eq7PTbtpw hoOVy8lueaRTOnKIs80mvB5XrOLwcuGsysf2qZpRRy9sdBoMA9x93ApNZnd4dlrj6bAez8OD 1Rjg9U4gBobF82o3OXjaE7OiYIgaw2JNuckrHN7rfgPnRWtwJTXPMt816aa/UIcB8oTf3zeI rpvZ913qAB0imop/KUrf3Gg+jykrcN0zTMHcaBDMLTian8rKgAuixY3dq0IQdgj5mjs/4f2l WDvp6nuC2kK7z7EQ551vkcChPR96icaDQXCgDdjBXxSJIgG3ubk+DWwjWepc4a54by0zNXpu GOXyO+MKW19IOxHJz6DhPJSV0oUE7dpre/jZmgdAz1GtPXjIENlpkTH4E+nvB/4YMQyr89Tr BAQ6VSTvvJNC2RnyImokArjfwQ4TzNFQ+TDHvpDyWA1+mQSjoyaNjEXtKhBiCnHofbQOQa2/ R9U1aFJOZuM1rmMnoexOCoOYZWGsPbxEIyfeNDtitq2Ks7OO2EFccL79HIlXntWx39ysxZkX XCGa1ckSAt+Vu5Kx3bBjMGYepOqLQs6bDGFKFFdQsvtCtFDIBzG1ndnRXa/k7RLOStb6OUHV aCgjaT4akPK0rTxcL5qXEXL4JvSOFQ6iF3IXb4Ky3n3BHsU3K6VqcbPfzFamXt4D1bEaIJQX 3OesLS8AAAAAAAA= --------------ms050805090107030104010400-- From owner-freebsd-security@FreeBSD.ORG Thu Feb 19 22:09:18 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 0742F33F for ; Thu, 19 Feb 2015 22:09:18 +0000 (UTC) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "gold.funkthat.com", Issuer "gold.funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFFE1AC5 for ; Thu, 19 Feb 2015 22:09:17 +0000 (UTC) Received: from gold.funkthat.com (localhost [127.0.0.1]) by gold.funkthat.com (8.14.5/8.14.5) with ESMTP id t1JM9GqV048558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2015 14:09:16 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.14.5/8.14.5/Submit) id t1JM9GY9048557; Thu, 19 Feb 2015 14:09:16 -0800 (PST) (envelope-from jmg) Date: Thu, 19 Feb 2015 14:09:16 -0800 From: John-Mark Gurney To: Alfred Hegemeier Subject: Re: freebsd-security Digest, Vol 522, Issue 1 Message-ID: <20150219220916.GF46794@funkthat.com> References: <2128122602.2736874.1424350240576.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <2128122602.2736874.1424350240576.JavaMail.yahoo@mail.yahoo.com> X-Operating-System: FreeBSD 9.1-PRERELEASE amd64 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (gold.funkthat.com [127.0.0.1]); Thu, 19 Feb 2015 14:09:16 -0800 (PST) Cc: "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 22:09:18 -0000 Alfred Hegemeier wrote this message on Thu, Feb 19, 2015 at 12:50 +0000: > just encrypt the whole hard drive with Geli. > That's the only protection I see: everything passing through the controllers is encrypted - unless keyloggers are installed, which you best protect against completely firewalling the "core" system, andhaving jails to access the outer world. > PCbsd already dumped complete auto hard drive encryption in their latest products - the automatic full HD encr was dumped when the Snowden stuff was revealed, I think with 10 release.So, I guess, they know why they removed it - makes it to secure. > > Which brings up an important question: how 'safe' is the encryption Geli, i.e. how can we know that developers are not on any agencies pay list ?Does that make sense  what I am writing in your opinion ? Having working on the AES-XTS code, and looked at the geli code to make it go faster, it's good code.. I don't see any major issues w/ it besides what is well know w/ using the various modes... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-security@FreeBSD.ORG Fri Feb 20 06:45:38 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 8F120EE4 for ; Fri, 20 Feb 2015 06:45:38 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 48E9AA7C for ; Fri, 20 Feb 2015 06:45:37 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 662023B8A2; Fri, 20 Feb 2015 06:45:31 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t1K6jRak061529; Fri, 20 Feb 2015 06:45:27 GMT (envelope-from phk@phk.freebsd.dk) To: Henry Baker Subject: Re: [Cryptography] trojans in the firmware In-reply-to: From: "Poul-Henning Kamp" References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <61527.1424414727.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Feb 2015 06:45:27 +0000 Message-ID: <61528.1424414727@critter.freebsd.dk> Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, cryptography@metzdowd.com, grarpamp 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: Fri, 20 Feb 2015 06:45:38 -0000 -------- In message , Henry B= aker = writes: >BTW, what's the point of AES encryption on this pre-p0wned device? >More security theatre? > >http://hothardware.com/reviews/samsung-portable-ssd-t1-review It's so that you can decommision the drive without destroying it. Pulverizing electronics gets you hazardous waste under EU's ROHS/WEEE rules. Throwing away the AES key gives you run-of-the-mill electronic garbage. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-security@FreeBSD.ORG Fri Feb 20 11:35:59 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 0EE4E832 for ; Fri, 20 Feb 2015 11:35:59 +0000 (UTC) Received: from smtp-2.bestweb.net (smtp-2.bestweb.net [209.94.103.42]) by mx1.freebsd.org (Postfix) with ESMTP id D7DABC19 for ; Fri, 20 Feb 2015 11:35:57 +0000 (UTC) Received: from [10.0.1.150] (unknown [32.213.41.236]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-2.bestweb.net (Postfix) with ESMTPSA id A9C7D119F5F; Fri, 20 Feb 2015 06:19:56 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Cryptography] trojans in the firmware From: Jerry Leichter In-Reply-To: Date: Fri, 20 Feb 2015 06:19:55 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> To: Henry Baker X-Mailer: Apple Mail (2.1878.6) X-Mailman-Approved-At: Fri, 20 Feb 2015 13:14:52 +0000 Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, cryptography@metzdowd.com, grarpamp 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: Fri, 20 Feb 2015 11:35:59 -0000 On Feb 19, 2015, at 11:12 AM, Henry Baker wrote: > I would love to be able to program this device myself, instead of = relying on Samsung's firmware. Good luck with that. SSD performance and even proper operation is still = somewhat of a black art; much of the value of the device comes from the = proprietary algorithms that control it, which are build knowing details = of the design. Samsung, like other SSD makers, has every reason to keep = that stuff secret. The market advantage of increments in speed and = other features is significant; the market to people who want to program = it themselves is essentially non-existent. > BTW, what's the point of AES encryption on this pre-p0wned device? = More security theatre? It depends on the implementation and what kind of attacker you're = considering. There have been implementations in the past which use = simply match a password stored in the device - encrypted with AES so = that the advertising claims aren't outright lies - against a password = entered at boot; the data itself was left unencrypted. But there's = plenty of power in a device like this to essentially build FDE right = into the SSD. That's probably proof against any attack against a = stolen/seized SSD. (Of course, Samsung may have deliberately, or = through incompetence, provided a back door - we'd never know. But most = attackers wouldn't know either. I'm sure North Korea would *assume* = that the South Korean intelligence services have access, whether it's = true or not.) Low-enough level attacks against the boot sequence could intercept and = leak the password. The OS typically would come in way too late to see = the password - but of course if you take it over, you have full access = to the device. In summary: Assuming a decent implementation and no back doors = available to the attackers of interest to you, this has exactly the = strengths and weaknesses of FDE, with no overhead in the host. Not = really security theatre, but given modern hardware, perhaps not much of = an advantage either. You could go for defense in depth by using FDE on = top of what the device provides. -- Jerry From owner-freebsd-security@FreeBSD.ORG Fri Feb 20 22:12:58 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 6477687C for ; Fri, 20 Feb 2015 22:12:58 +0000 (UTC) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 20EF01DA for ; Fri, 20 Feb 2015 22:12:58 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id wo20so26691223obc.5 for ; Fri, 20 Feb 2015 14:12:57 -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=MDf1AEiFGHCPYKWr/uh4kl2/+AC7tciSnK4f2sBemEk=; b=xUtPjjQLH6cr+g+TnYss48nmXPngrxIEu8PAFyKLRdI52Eo6/uBf6GaxoVUQvFU1s4 Q/6wCpSJTomstQRC8qA5UQxWzcGLivfN/4ygfPuV4wrpgSJPEaWfs0nbSk2RBqLpBo/f ASKVbbfXzHqKYzviTNGAIzXeO91Npsvvy8qoQ3zVmPCUbVcvMy1bpzE9HkPea7YGi15Y asgpi62l0Ja1LWkLvVjPYVE0GoJaDyEdGeD/5iNvQXPpqzosLIW+4eAXfyInqeCN0+Yu Ho+udT8ZqWCupLVidO6pZ5sVsH6I3QbPMwTecYesFGu/iy86ogWwFl0JRf9d+yRvE01o yAhw== MIME-Version: 1.0 X-Received: by 10.182.128.199 with SMTP id nq7mr1045586obb.47.1424470377561; Fri, 20 Feb 2015 14:12:57 -0800 (PST) Received: by 10.60.140.199 with HTTP; Fri, 20 Feb 2015 14:12:57 -0800 (PST) In-Reply-To: References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> Date: Fri, 20 Feb 2015 17:12:57 -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-Mailman-Approved-At: Fri, 20 Feb 2015 22:25:38 +0000 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: Fri, 20 Feb 2015 22:12:58 -0000 On Fri, Feb 20, 2015 at 4:50 PM, grarpamp wrote: > These for starters, then all the public hacker malware versions of > the same thing both extant and coming... Note the explicit references to FreeBSD and UFS in those links. Linux and EXT FS as well. These OS are not immune to 0-day and other exploits. Multiple defenses are always useful.. From owner-freebsd-security@FreeBSD.ORG Fri Feb 20 22:47:14 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 6BAE1C7 for ; Fri, 20 Feb 2015 22:47:14 +0000 (UTC) Received: from mail.merrymeet.com (merrymeet.com [173.164.244.100]) by mx1.freebsd.org (Postfix) with ESMTP id 459277B7 for ; Fri, 20 Feb 2015 22:47:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.merrymeet.com (Postfix) with ESMTP id 98FD269FA01C; Fri, 20 Feb 2015 14:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at merrymeet.com Received: from mail.merrymeet.com ([127.0.0.1]) by localhost (merrymeet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUfQh-+oR7Tb; Fri, 20 Feb 2015 14:36:59 -0800 (PST) Received: from keys.merrymeet.com (keys.merrymeet.com [173.164.244.97]) by mail.merrymeet.com (Postfix) with ESMTPSA id EFE2469F9FEC; Fri, 20 Feb 2015 14:36:58 -0800 (PST) Received: from [10.0.23.30] ([173.164.244.98]) by keys.merrymeet.com (PGP Universal service); Fri, 20 Feb 2015 14:36:59 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 20 Feb 2015 14:36:59 -0800 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Cryptography] trojans in the firmware From: Jon Callas In-Reply-To: Date: Fri, 20 Feb 2015 14:36:55 -0800 Message-Id: <711B69EB-1CBF-4F03-9336-AFEBE0B857A0@callas.org> References: <54E2B04C.9080707@av8n.com> <54E436FB.9000709@deadhat.com> To: Henry Baker X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 20 Feb 2015 23:56:34 +0000 Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, cryptography@metzdowd.com, Jon Callas , grarpamp 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: Fri, 20 Feb 2015 22:47:14 -0000 On Feb 19, 2015, at 8:12 AM, Henry Baker wrote: > I would love to be able to program this device myself, instead of = relying on Samsung's firmware. >=20 > BTW, what's the point of AES encryption on this pre-p0wned device? = More security theatre? NAND memory runs faster when the hamming weight of the data is = approximately even between zeroes and ones. You can speed up NAND flash = by running the data through a suitable whitening function. AES is a great whitening function. If you then go to the extra effort to = do key management, you have security. It's a simple matter of = architecture and programming. :) Jon 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. From owner-freebsd-security@FreeBSD.ORG Sat Feb 21 13:43:24 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 8E67213D for ; Sat, 21 Feb 2015 13:43:24 +0000 (UTC) Received: from nm6.bullet.mail.ne1.yahoo.com (nm6.bullet.mail.ne1.yahoo.com [98.138.90.69]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4EA3D838 for ; Sat, 21 Feb 2015 13:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1424526097; bh=CqNm0zYGJmP2L4WTkgguM6MGK4yjJqtnzvmZpEedGgU=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=WXgbAMLfX8wAxc6rAHNNW22Js0p/GpF4uox8r+k497571QupUoWumeXQaQp43yhMqsmVd1Cu4S5OtLfhcjB4PAu8vlWLDhzWK+a+XNREPJvU4vh6OHxPbJ5pSDcKwnORzH927GII92GyPCxQ/14Qc8ZqbPBxOcpGF4kjpb6GJu3TrULKl9OuwTgDmh3wgrDiIFUGw+6csYWt99m20ekLVitRWG4uFYDGb7fEHbFQT5quCgigvl8SDE/fKv/2xlkh29mXPOQkBWhxAQDj9/9nbZrycHxEknJt4vkmzzbGXyzpuH/QEO5kDNDe09xGNQOo72kJk/6K6Q3u9XFSEUAq0g== Received: from [98.138.100.113] by nm6.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2015 13:41:37 -0000 Received: from [46.228.39.105] by tm104.bullet.mail.ne1.yahoo.com with NNFMP; 21 Feb 2015 13:41:37 -0000 Received: from [127.0.0.1] by smtp142.mail.ir2.yahoo.com with NNFMP; 21 Feb 2015 13:41:37 -0000 X-Yahoo-Newman-Id: 262512.41019.bm@smtp142.mail.ir2.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WBd9ZF0VM1nLzEW.NG8TuyCCsngbxmFWE_.IRrcqr3gk5eb EMqhtucGcFMQcy_bdCcLsPNzGJ_VEbgGleD9K.x9GCutmHx972dLZH_FoFfg PT83tz2vh0qwnI1N01GbgnMPoO4n3qo00Z1nmWeSXof2Wls2OfstQGcseXIF b7PWFJLSCg93yQtG7BLWw2dsLZE9RxkBXr2FKO8HJdtdHg07_xmfNe7aimRm lNp_QTnevN5nNJX64vMLyNYFl0gHjZkw2GaKHz9XTGec1eIIUl3nkk8kl5qC bS_5wbAl5lSxYj1AuCoXCvvYIT0n1XJ_5RExOUZpcJWuftso1IOBfuLjVd7X 6IYH_jVvQAZYLFhNpecRzO6C3gQO_agD_Cf_jLI4zbrXqXvSuyh63R.ADa6j GgjGeZzfJUfsIecbWqRsukJa3f9iriiVK15kCBAfthrMU58UtMtDsCFoblS4 5t_hhlZ.nd.JLWK0WJ.0Soh_tTDx1ttdmgKvEqSuXTbiYP643rjKtbzxdpHp FRRSbTNxI_LdVwyrsaHEKvh7VLvNHi7NLl5hvHldKCnN2GLNi1WSbXpHlnGc W623YQoaTOQueN_EeADJ0Gr_Y3CxL7f3gWufo4XmK8HkSrQeQ5Fo63MG6ujA RSNsOzFW0qgbnRUNAR7Zhr81Ya52GyTIKn01WtvYIW.iqm4YdP1c8MxLLOhS YMgMxp8InZTU4BcrlbWFzpqf2dprhhgjn3sSEIYx87D8wcAupy5DGRyE3oFY Y3uiKZwtWRm6SrPsk6nKjxHburCMZmzpR7B6KD9zoOMCzaTY3UIOUI6yeUL5 1nmRp7DbIdFrxlT8nK3gPPfEYzD3A1SaKXlbgfBw.Ipnb0_9xhz3qkJprwOH S1nFleVoJZ10QYvCuSqQy7nPyx3xljFJbWMGJMbztYD7iag6rwpwmca4ZMMW DgqY1jwpTFoKv7Tih.tc3bls1SBfbtGjdizIkURUtHpy3uFlfi5nhxjvJIed z4edNFq1LrdI_hOsNAdPk7u._74u6VPsBD2.XAffdsJz18w-- X-Yahoo-SMTP: dPauJreswBAUXFIVPuojsKYGX1jkJdG. Date: Sat, 21 Feb 2015 14:41:57 +0100 From: Kay Rydyger To: freebsd-security@freebsd.org Subject: Re: freebsd-security Digest, Vol 522, Issue 3 Message-ID: <20150221134157.GA23391@snowflake.fritz.box> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 13:43:24 -0000 On 21.02.15 12:00, freebsd-security-request@freebsd.org wrote: > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. Re: [Cryptography] trojans in the firmware (Jerry Leichter) > 2. Re: [Cryptography] trojans in the firmware (grarpamp) > 3. Re: [Cryptography] trojans in the firmware (Jon Callas) > 4. Re: [Cryptography] trojans in the firmware (grarpamp) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 20 Feb 2015 06:19:55 -0500 > From: Jerry Leichter > To: Henry Baker > Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, > cryptography@metzdowd.com, grarpamp > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > Content-Type: text/plain; charset=us-ascii > > On Feb 19, 2015, at 11:12 AM, Henry Baker wrote: > > I would love to be able to program this device myself, instead of relying on Samsung's firmware. > Good luck with that. SSD performance and even proper operation is still somewhat of a black art; much of the value of the device comes from the proprietary algorithms that control it, which are build knowing details of the design. Samsung, like other SSD makers, has every reason to keep that stuff secret. The market advantage of increments in speed and other features is significant; the market to people who want to program it themselves is essentially non-existent. > > > BTW, what's the point of AES encryption on this pre-p0wned device? More security theatre? > It depends on the implementation and what kind of attacker you're considering. There have been implementations in the past which use simply match a password stored in the device - encrypted with AES so that the advertising claims aren't outright lies - against a password entered at boot; the data itself was left unencrypted. But there's plenty of power in a device like this to essentially build FDE right into the SSD. That's probably proof against any attack against a stolen/seized SSD. (Of course, Samsung may have deliberately, or through incompetence, provided a back door - we'd never know. But most attackers wouldn't know either. I'm sure North Korea would *assume* that the South Korean intelligence services have access, whether it's true or not.) > > Low-enough level attacks against the boot sequence could intercept and leak the password. The OS typically would come in way too late to see the password - but of course if you take it over, you have full access to the device. > > In summary: Assuming a decent implementation and no back doors available to the attackers of interest to you, this has exactly the strengths and weaknesses of FDE, with no overhead in the host. Not really security theatre, but given modern hardware, perhaps not much of an advantage either. You could go for defense in depth by using FDE on top of what the device provides. > > -- Jerry > > > > ------------------------------ > > Message: 2 > Date: Fri, 20 Feb 2015 17:12:57 -0500 > From: grarpamp > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On Fri, Feb 20, 2015 at 4:50 PM, grarpamp wrote: > > These for starters, then all the public hacker malware versions of > > the same thing both extant and coming... > > Note the explicit references to FreeBSD and UFS in those links. > Linux and EXT FS as well. These OS are not immune to 0-day > and other exploits. Multiple defenses are always useful.. > > > ------------------------------ > > Message: 3 > Date: Fri, 20 Feb 2015 14:36:55 -0800 > From: Jon Callas > To: Henry Baker > Cc: cypherpunks@cpunks.org, freebsd-security@freebsd.org, > cryptography@metzdowd.com, Jon Callas , grarpamp > > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: <711B69EB-1CBF-4F03-9336-AFEBE0B857A0@callas.org> > Content-Type: text/plain; charset=us-ascii > > > On Feb 19, 2015, at 8:12 AM, Henry Baker wrote: > > > I would love to be able to program this device myself, instead of relying on Samsung's firmware. > > > > BTW, what's the point of AES encryption on this pre-p0wned device? More security theatre? > > NAND memory runs faster when the hamming weight of the data is approximately even between zeroes and ones. You can speed up NAND flash by running the data through a suitable whitening function. > > AES is a great whitening function. If you then go to the extra effort to do key management, you have security. It's a simple matter of architecture and programming. :) > > Jon > > > > ------------------------------ > > Message: 4 > Date: Fri, 20 Feb 2015 20:26:35 -0500 > From: grarpamp > To: freebsd-security@freebsd.org > Subject: Re: [Cryptography] trojans in the firmware > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > 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. what has blocking firmware updates to do with firmware being able to read the data passing through the controller ? 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. > > > > > 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. > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > ------------------------------ > > End of freebsd-security Digest, Vol 522, Issue 3 > ************************************************ > From owner-freebsd-security@FreeBSD.ORG Sat Feb 21 15:59:26 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 49738C21 for ; Sat, 21 Feb 2015 15:59:26 +0000 (UTC) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (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 00B485E5 for ; Sat, 21 Feb 2015 15:59:25 +0000 (UTC) Received: by mail-qa0-f52.google.com with SMTP id v10so16591306qac.11 for ; Sat, 21 Feb 2015 07:59:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:organization :user-agent:mime-version:content-type; bh=YHgAR0tbw6UY3ku/1RrtB9UZTDapehMfhI9pSGVBifw=; b=Qqad22AKyWrSyYMp7gakoineY6Vebr4wyHsaJqcTbPMjEskKBGsloA2qBp9hZCUjpC XS8EDo/rPY72VPIHkV+QSEESaK+UqAeKHBqUrdWQrOxDsmhvEM0hc4XPzZh7jFUh90Jp A/LA12E1M0KLcHTFV4RJaGwE51GRynm69ap/joDJQogZXFM4IAbQdC4GHv8WvcwN2r79 tIYVfa9UJ9ksdQXHgQS/per9ae4Qu8vik14mmgiSZOollmr8FhWjftmOJ/RUZ61PjlnA MLDN5oZs8mlZvytcCuk0viiodWk0Ht8w9BI4YZGTT6msnfaIB/EE6Lqc0TZ7eNkwnHkG eQ6w== X-Gm-Message-State: ALoCoQkWm939+wCS77rdjzhZwekgLXGBZX3RWxuyUjt5ujbkwRF644tXe17oSc8vswO/TgVQeFv+xPzxAlWNWFax4a6w/GWYG56NV5+06ZTeTsta8oiex3EQMVsU84wq5Ab2fhf7J+AFdhxuPAJnkWIyeV3hYqZhry4oXAILvQDh1rFDQBU31zQmjCKJOGfNMeD/BzEqIUCV X-Received: by 10.140.88.17 with SMTP id s17mr6346346qgd.79.1424534359209; Sat, 21 Feb 2015 07:59:19 -0800 (PST) Received: from shawnwebb-laptop.localnet ([73.173.99.185]) by mx.google.com with ESMTPSA id z67sm24024754qgz.10.2015.02.21.07.59.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Feb 2015 07:59:18 -0800 (PST) From: Shawn Webb To: "freebsd-security@freebsd.org" Subject: CFT: New ASLR Patch Date: Sat, 21 Feb 2015 10:59:16 -0500 Message-ID: <2473923.nPpcAzaekg@shawnwebb-laptop> Organization: HardenedBSD User-Agent: KMail/4.14.2 (FreeBSD/11.0-CURRENT; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1439586.rm7WrNrMXC"; micalg="pgp-sha256"; protocol="application/pgp-signature" 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 15:59:26 -0000 --nextPart1439586.rm7WrNrMXC Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hey All, It has been a long time since we sent out a call for testing request for our ASLR patch. We've been hard at work making our ASLR implementation as robust as possible. We'd like to invite all adventurous souls to test our ASLR implementation. Put it through the ringer. Since the patch is much too large to attach to an email, you can find our latest patch on FreeBSD's Phabricator: https://reviews.freebsd.org/D473 Or download the raw version of the patch: https://reviews.freebsd.org/D473?download=true Please let me know if you find any issues. Thanks, Shawn Webb HardenedBSD --nextPart1439586.rm7WrNrMXC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCAAGBQJU6KtUAAoJEGqEZY9SRW7uUr8QAK89Qk9xeH2gDE6pHTYK6DBs iBbVtTvAeK9uIVAGkQfVpU2eBBtmhnKElgrHQVKjM9DiGz15M7gNm6B/qhxlA02j NQtimnxTm6hko482dLPmbG0vUxHw8jePmXnLmHTcna0n2ccXgtzJF/3lHLEEWuSw rmqi1tGNcwvi7ZpaDR8Bk/kphDWM6WU4GBJAwmTfsmnMwVl1zFvzDgV6ilok6AaM mP8yRcdjm5/c6vi0NDHUkiEOk9oV6DTVFCFZqIwrbguCOwG9cLVRwpCSSquTAHbQ vbDorcLqYh1bgHzaIrA2unWggZZ0Bo0s9z56vbhMZZdm61+hvocjRFMAJ6vnJFh2 XZCZeeqPmSEQ/osmb6ctR2l6W83nZ6CsoIg9IyMRqsdSPt38R98920w8YVvfPI+I f4ABWR7hqGcrdLanB5WTZJGUZpq9YgOnSTlX+/xXnjeBLky6y0yUlu/A3dojGShs L88w9yqyTu8Vw9JhUKa+S9RunG8o0pn2rztHylvZWL6GxNiFrnJD3DdFi/NFx2Ph 8uuoraqBZsMKK5ycUT51GXqGQCGnvMwsMOQsOCP/7M8J+/M9IjO6BxqMGqYsxuzQ E6ryNlYH+pes5qIEfCKqJ72A5CqiROUcouIdLtn+Q5mgCoelIy9ZqI5S5ynu7rK5 wpV3lKoT6VIVkGuCHakT =pc7R -----END PGP SIGNATURE----- --nextPart1439586.rm7WrNrMXC--