From owner-freebsd-security@freebsd.org Sun Mar 19 14:44:00 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DAF0D121DB; Sun, 19 Mar 2017 14:44:00 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D9CB410DE; Sun, 19 Mar 2017 14:43:59 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id D37F4B846; Sun, 19 Mar 2017 14:43:51 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id 9D544468C; Sun, 19 Mar 2017 15:43:46 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Andrey Chernov Cc: Xin LI , Steven Chamberlain , kostikbel@gmail.com, "freebsd-security\@freebsd.org" , freebsd Subject: Re: arc4random weakness References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> <8677f9d8-b326-2526-47ce-f2e18421c074@freebsd.org> Date: Sun, 19 Mar 2017 15:43:46 +0100 In-Reply-To: <8677f9d8-b326-2526-47ce-f2e18421c074@freebsd.org> (Andrey Chernov's message of "Thu, 16 Mar 2017 22:26:09 +0300") Message-ID: <861sttpbrx.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 14:44:00 -0000 Andrey Chernov writes: > Theo kindly explained that zeroing whole page instead of single variable > suits to his newest arc4random better, since clears two structs at once > (including ChaCha state), making some form of backward secrecy. Yes, avoiding leaking key material to child processes would be useful for more than just arc4random. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Sun Mar 19 15:12:41 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A1AAD12CBF; Sun, 19 Mar 2017 15:12:41 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id CECE8196; Sun, 19 Mar 2017 15:12:40 +0000 (UTC) (envelope-from des@des.no) Received: from desk.des.no (smtp.des.no [194.63.250.102]) by smtp.des.no (Postfix) with ESMTP id 96C71B953; Sun, 19 Mar 2017 15:12:39 +0000 (UTC) Received: by desk.des.no (Postfix, from userid 1001) id A357A46A4; Sun, 19 Mar 2017 16:12:29 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Konstantin Belousov Cc: freebsd-security@freebsd.org, Steven Chamberlain , freebsd-hackers@freebsd.org Subject: Re: arc4random weakness References: <20170313220639.GB65190@pyro.eu.org> <20170315130615.GC25448@pyro.eu.org> <5160183b-9778-59aa-6cf9-118014a588eb@freebsd.org> <86k27pz8sy.fsf@desk.des.no> <20170316131946.GN16105@kib.kiev.ua> Date: Sun, 19 Mar 2017 16:12:29 +0100 In-Reply-To: <20170316131946.GN16105@kib.kiev.ua> (Konstantin Belousov's message of "Thu, 16 Mar 2017 15:19:46 +0200") Message-ID: <86wpblnvvm.fsf@desk.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Mar 2017 15:12:41 -0000 Konstantin Belousov writes: > Dag-Erling Sm=C3=B8rgrav writes: > > Wouldn't it be possible to just set up the page entry but leave it > > unmapped, so that it is paged in (and zeroed if necessary) on first > > access? Thus, a process that uses arc4random() and fork()s would not > > incur a penalty until (and unless) the child uses arc4random() too. > This is how the forking code works, without any additional coding, > for the INHERIT_ZERO regions as well. Well then I don't see the problem... I just assumed from ache@'s objection that it wasn't the case. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-security@freebsd.org Wed Mar 22 09:19:48 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58B96D1573F; Wed, 22 Mar 2017 09:19:48 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: from mail-ot0-x244.google.com (mail-ot0-x244.google.com [IPv6:2607:f8b0:4003:c0f::244]) (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 160521F66; Wed, 22 Mar 2017 09:19:48 +0000 (UTC) (envelope-from tomek.cedro@gmail.com) Received: by mail-ot0-x244.google.com with SMTP id y88so1946913ota.1; Wed, 22 Mar 2017 02:19:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=udwVm6logtLyIqKroUrcXN3HZDV5bSjQ3Z+kWLnJZ5g=; b=Yzgl0wvm25TB84cmtZ7hkSfViFRfN4hO1TiyEED7Z3zy2xmno37DSe73w9lRg0pK+o qGKA6XWUv3OSdv6lvRRUhCmerpgVE94MFyVjhqLeG3d8xNIyzW2avoJuKdm7z9xW0Ebx 1+FMRRa3FQo5lHY3Bz6gEv+R6h7fALITkl5eEEBXGBYiX+XwstX9YG2qZj2zxLSU3NdU pNtk8NTyJ66f2aGHnMf2tQQN6yDqPZ/RqdhLtHoa55q1iRu8JyHd5+VYzFDJJdd4n9A7 DM5oDiz9pjnRFMjUoNL4tZ74r1iKC0s/HGu8mbHpRzs8dpxXOJR0L30Gcm/C0GoJY3Hn VvEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=udwVm6logtLyIqKroUrcXN3HZDV5bSjQ3Z+kWLnJZ5g=; b=HF7+Q8WALKiPP96nZ/Upd6s9PmE+Rh2Nj6nqGggm9WZFRkIVFjcBvHJqygoWHn1f6A JtF1xUmbriCcptEd03/0ANr4FtN4oiKU5Q2dLmLNBUVhJVtEtowdiVa1Y88YFGZ7YqPk vCxUrzxkMefWSIWNjq/G9BHgKfRtPZPS8ENOdcIehRrN7vBSCtBSkOjPgO4IoVCu2tgZ URGH10zrDtewNkrbH5E2B3ovQWG9gfMeHkjxPQi0TdeOaE3c2cNM1VDHm/MQF9ixzmKL uU00Quv70Gx8zxvLJySncd6lw1pZn5/Ls3z6XbbbdH3dJA9a/J4ZanjkCdR0DrRd3og6 vA7w== X-Gm-Message-State: AFeK/H3Ho7RDvMLGD82hI+n/ure+ipLbkJ2Ibqk1Wpj/QQgxckYlxi7JEhMaHk2JiSDF6qQz7u0R3kOAIqQ3Cw== X-Received: by 10.157.43.232 with SMTP id u95mr547006ota.70.1490174387448; Wed, 22 Mar 2017 02:19:47 -0700 (PDT) MIME-Version: 1.0 Sender: tomek.cedro@gmail.com Received: by 10.157.18.211 with HTTP; Wed, 22 Mar 2017 02:19:47 -0700 (PDT) Received: by 10.157.18.211 with HTTP; Wed, 22 Mar 2017 02:19:47 -0700 (PDT) In-Reply-To: References: From: Tomasz CEDRO Date: Wed, 22 Mar 2017 10:19:47 +0100 X-Google-Sender-Auth: xbwbah1jmaH9JSRs_AvVBoFj2Hk Message-ID: Subject: Re: Filtering Against Persistent Firmware Rootkits - BadUSB, HDDHack, UEFI To: grarpamp Cc: FreeBSD Questions Mailing List , freebsd-hardware@freebsd.org, freebsd-security@freebsd.org, freebsd-hackers@freebsd.org X-Mailman-Approved-At: Wed, 22 Mar 2017 11:56:09 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 09:19:48 -0000 I have created www.libswd.com and www.iCeDeROM.com for low-level access to embedded system resources, all developed on FreeBSD :-) Still no interest from investors/sponsors to support iCeDeROM so I could focus 108% on its development :-/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info From owner-freebsd-security@freebsd.org Wed Mar 22 23:12:38 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 746AFD18C01; Wed, 22 Mar 2017 23:12:38 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk0-x244.google.com (mail-vk0-x244.google.com [IPv6:2607:f8b0:400c:c05::244]) (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 2FC0317C0; Wed, 22 Mar 2017 23:12:38 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk0-x244.google.com with SMTP id j64so17376253vkg.0; Wed, 22 Mar 2017 16:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J4yAAyNGmVYThYlbDvizeJDSZR5kVFHNArcr3ArW2dE=; b=cCNZTAZr+miW4WCw12CgeCa6gr/86/LehyriCtiSWi5fDPvzoY7rsY7xSwuJTLbuMV lQau7ooK8pEkXzyspVu19WYbrVUVvljj5uT2O4zEtZOSo0iSfCdvR68m7mTC+bEul/3z iU1TJ8S87RRhRXzQoWxYmX+vUlrS1UFAOlHtKOSyIrwXq2nTA1LJc/VH1+UA15TIbXRB k31EAr9F/ehvcyEOc0jqzPI+Vb1m/dA0jv1ClGVisXSzh72J0Axyn9218HjlQAkDcXVl M1I3lSRLPx74duJqhXGa9G/gT4NvF4wmhdMrElW7i3f3COpb/pFHl5FF0YrjoLZRVisD uWtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J4yAAyNGmVYThYlbDvizeJDSZR5kVFHNArcr3ArW2dE=; b=steE8h4bRgqjRsrN1QxDmZIiNNMEuh7tLiu5Bd9vePKRpSJponQ2qAKYvcPmxSSipF LHx3jk39B7XZSI1cY05wDTge1DG3SQwKz/meuVIdbuX8JXLdBYtjA0ooEMga/d7LhKOK sjwdC6r5EmtWn3xKsAiJC6BLMnSe84DXX/VOvLafurPeOJonD690+3g0VbuN5ZPi5crM V0lqS5fHDouaNAMDXKTln7n1Jvuca3a0Y7mhB+ExcrPbdbqzWKvUzLcoTxxPezEaCUsN vY/l6GAUeJSt2gFq6WT7Vv+IjCnKXEh5mdOsyJo6PvxH6KSZKenTL2ApaxAttz1ehBaZ R2ZA== X-Gm-Message-State: AFeK/H1Nok8Gx8kU5gWUkkY7gwcrbXtCSvWXGOqgr5bZ/BziCIbW7dE5Iz/RNDCHi8ML20uUZjspjmsr2RxlzQ== X-Received: by 10.176.91.87 with SMTP id v23mr15252195uae.90.1490224356990; Wed, 22 Mar 2017 16:12:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.37 with HTTP; Wed, 22 Mar 2017 16:11:56 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Wed, 22 Mar 2017 19:11:56 -0400 Message-ID: Subject: Re: Filtering Against Persistent Firmware Rootkits - BadUSB, HDDHack, UEFI To: freebsd-security@freebsd.org Cc: freebsd-hardware@freebsd.org, freebsd-hackers@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 23 Mar 2017 12:30:15 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 23:12:38 -0000 > It is virtually impossible to guard against firmware rootkits because > cpu cannot prevent the card's or device's cpu from from executing that code. > This was made known by the malware embedded in disk drives' FW, and > other peripherals' FW, such as wifi and graphics, to name a couple. > It is possible for such device FW to insert malware into, > or modify, the RAM resident OS. > Apparently making OS's executable segments "non-writeable" can be gotten > around. There are two very different write directions involved... HW -> OS / SW ... Yes, as above, you're screwed. SW -> OS -> HW ... However, as before, you can add kernel filters to further help prevent software from writing the screwed firmware to your hardware in the first place. From owner-freebsd-security@freebsd.org Fri Mar 24 12:30:18 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AF99BD1BC04 for ; Fri, 24 Mar 2017 12:30:18 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "goliath.siemens.de", Issuer "Siemens Issuing CA Class Internet Server 2013" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D8EF1532; Fri, 24 Mar 2017 12:30:17 +0000 (UTC) (envelope-from Andre.Albsmeier@siemens.com) Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id v2OCLTNk008405 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Mar 2017 13:21:29 +0100 Received: from curry.mchp.siemens.de (curry.mchp.siemens.de [139.25.40.130]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id v2OCLTZQ032132; Fri, 24 Mar 2017 13:21:29 +0100 Received: (from user@localhost) by curry.mchp.siemens.de (8.15.2/8.15.2) id v2OCLTBb042611; Date: Fri, 24 Mar 2017 13:21:29 +0100 From: Andre Albsmeier To: Dimitry Andric Cc: Roger Marquis , freebsd-security@freebsd.org, Ed Maste Subject: Re: /tmp/ecp.* created during kernel build? Message-ID: <20170324122129.GA24947@bali> References: <1612271904400.79526@mx5.roble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 12:30:18 -0000 On Wed, 28-Dec-2016 at 12:31:49 +0100, Dimitry Andric wrote: > On 28 Dec 2016, at 04:10, Roger Marquis wrote: > > > >> Found a couple of ecp binaries in /tmp, apparently created concurrent > >> with an 11.0 x86_64 kernel build. Anyone else seen this? Could they > >> be related to a "make buildkernel"? > > > > Confirmed 'make buildkernel' does create these files, apparently via > > /usr/src/contrib/elftoolchain/elfcopy/main.c (thanks Adam). > > > > Still odd that these are LSB binaries which don't run on this server and > > nothing including cleanworld removed them. Anyone audited elftoolchain > > recently? > > This looks like a minor bug in elfcopy, when used as objcopy, > specifically when in combination with the --input-target binary flag: > > $ mkdir /tmp/foo > $ export TMPDIR=/tmp/foo > $ ls -l /tmp/foo/ > $ /usr/bin/objcopy --input-target binary --output-target elf64-x86-64-freebsd --binary-architecture i386 cloudabi32_vdso.o bar.o > $ ls -l /tmp/foo > total 12 > -rw-r--r-- 1 dim wheel 10198 2016-12-28 12:29:32 ecp.0xbNAi5i > > E.g. for some reason this does not clean up the temporary file. strip (objcopy) does more curious things: $ cd /tmp $ cp /usr/lib/libc.a . $ strip --strip-debug libc.a $ strip --strip-debug libc.a [1] 960 segmentation fault strip --strip-debug libc.a Interesting is also that libc.a grows(!): Before the strip: -r--r----- 1 andre wheel 2622684 24 Mar 13:18 libc.a After: -r--r----- 1 andre wheel 2713792 24 Mar 13:19 libc.a -Andre > > -Dimitry > -- Never argue with an idiot. They drag you down to their level, then beat you with their experience. From owner-freebsd-security@freebsd.org Sat Mar 25 03:29:27 2017 Return-Path: Delivered-To: freebsd-security@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD336D0FF82; Sat, 25 Mar 2017 03:29:27 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 78024159; Sat, 25 Mar 2017 03:29:27 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk0-x233.google.com with SMTP id r69so7559498vke.2; Fri, 24 Mar 2017 20:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Te0jIJKZTFGAutgQir6X+lltBWu6HsL9UcePTWXrUnk=; b=qpN7XMXtzsl763r2EuUI8fEMSCstHhJ246CgApowPgYfvYO2fSyIUmi7UyBSZ7BStQ lv6hYMEHpWq5/j/SZe9RYd7HagPuSZl3LvH+Y8ylkA1yk2BI89rsvyhvbVDO/8qsrvp4 SO3TQYh/NB7Zkf1jjZsUJ7HZNTHZc7K5/ddAhV5PhuN84LkRbRYVVPMpmLaakiMBN1Gg ByrpGMFNsatQIbbvKohLNZgqXaGx08IJIV4lokZayOgWOfY+pUcOSd9EUJuoOqbplHeZ 4FgfDY9U8XU229j1pHd8eT4hsdoFPNqouID8Lh5TuhjgqWxHLCTddoiwTM0lB9hRxkkh +r0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Te0jIJKZTFGAutgQir6X+lltBWu6HsL9UcePTWXrUnk=; b=eOaW3ktyjs2A1mBhx6nTGkNFi2gBFhCutEY6Rmu2gO3wOwPz5lLN5I8aR71kqcWPDd pI4a8TLBWs1u6QjuC+GyMog7u037jwuz0e9nsFxr92cOrchqN3TI7Tf4MmG/Nw8A7UvU JLgr9Gn7NJrkiuUXCYt+/0gR4gCipAHwqAzBZbb3ATWYeM3Y45sDDnDuKVeptlhg/hyF WJ0txqgvx7Nkhrjneu+APQwPHnZTUDSBG97CcS0hen63Jv+qQ5H9p083dQjOvBwV/vTk gg1308JZ2ytffnqFcWjUX4m80fiOoqZScPE3F4zJrmIuBvM0E97wqS4wvmEjwRUFcbK7 HFng== X-Gm-Message-State: AFeK/H3C8gUQMDgE6XOr8Qnt3JlwRNwZuSeu6ufQII2hrerVh5wGnGJ9MWvV+r7ue6fCzELyUn/g0b+a8ys0SQ== X-Received: by 10.176.83.141 with SMTP id k13mr4549508uaa.64.1490412566354; Fri, 24 Mar 2017 20:29:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.33.37 with HTTP; Fri, 24 Mar 2017 20:28:46 -0700 (PDT) In-Reply-To: References: From: grarpamp Date: Fri, 24 Mar 2017 23:28:46 -0400 Message-ID: Subject: Re: Filtering Against Persistent Firmware Rootkits - BadUSB, HDDHack, UEFI To: freebsd-security@freebsd.org Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Mar 2017 03:29:27 -0000 Over two years ago this "trojans in the firmware" was mentioned here. These attacks are real and are in the wild. They are created and used by various hats from adversary to researcher to miscreant... and ultimately can end up passing unwittingly through degrees of separation to and among you and your peers over daily sharing and other physical transactions, use of unaudited application and systems code, dual booting, parking lot attacks, computer labs, libraries, component swapping, etc. Some mitigation may be possible through kernel filtering modes... - Filter and log all known firmware / bios writing opcodes. - Filter and log all opcodes except those required for daily use, such as: read, write, erase unit, inquiry, reset, etc. - Filter and log all opcodes execpt those in some user defined rulesets. Default permit / deny, the usual schemes. In a securelevel, this may provide some resistance and extra steps of defense in depth to attacks that presume they have direct access to firmware without needing to smash the kernel further beyond root (also, root access is foolishly yet often available to users). FreeBSD should consider addressing any oppurtunities to further inhibit these attack vectors. Details via links below. (CC'd to a few lists to promote general awareness. Replies are perhaps best made only to freebsd-security@ . This post is what people were replying to but never made it.) # CAM - hdd, tape, optical, etc https://www.schneier.com/blog/archives/2014/01/iratemonk_nsa_e.html http://spritesmods.com/?art=hddhack http://s3.eurecom.fr/~zaddach/ https://www.ibr.cs.tu-bs.de/users/kurmus/ https://www.malwaretech.com/2015/04/hard-disk-firmware-hacking-part-1.html https://www.malwaretech.com/2015/06/hard-disk-firmware-rootkit-surviving.html http://web.archive.org/web/20150615181236/http://malwaretech.net/MTSBK.pdf https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf http://arstechnica.com/security/2015/02/how-omnipotent-hackers-tied-to-the-nsa-hid-for-14-years-and-were-found-at-last/ http://web.archive.org/web/20130228090611/http://www.recover.co.il/SA-cover/SA-cover.pdf http://www.spiegel.de/media/media-35661.pdf # USB https://opensource.srlabs.de/projects/badusb https://github.com/robertfisk/USG/wiki # BIOS, UEFI http://blog.trendmicro.com/trendlabs-security-intelligence/hacking-team-uses-uefi-bios-rootkit-to-keep-rcs-9-agent-in-target-systems/ http://arstechnica.com/security/2013/10/meet-badbios-the-mysterious-mac-and-pc-malware-that-jumps-airgaps/ # CPU http://inertiawar.com/microcode/ https://wiki.archlinux.org/index.php/microcode http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-vol-3a-part-1-manual.pdf https://en.wikipedia.org/wiki/Intel_Active_Management_Technology # FreeBSD, UFS - supported 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 # various https://en.wikipedia.org/wiki/NSA_ANT_catalog https://firmwaresecurity.com/