From owner-freebsd-hackers@freebsd.org Thu Oct 20 12:26:08 2016 Return-Path: Delivered-To: freebsd-hackers@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 B321BC186B7 for ; Thu, 20 Oct 2016 12:26:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3763B95D; Thu, 20 Oct 2016 12:26:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9KCQ1gT037793 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 20 Oct 2016 15:26:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9KCQ1gT037793 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9KCPx9B037776; Thu, 20 Oct 2016 15:25:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 20 Oct 2016 15:25:59 +0300 From: Konstantin Belousov To: Conrad Meyer Cc: Beach Geek , FreeBSD Hackers Subject: Re: Attacking Branch Predictors to Bypass ASLR Message-ID: <20161020122559.GO54029@kib.kiev.ua> References: 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-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2016 12:26:08 -0000 On Wed, Oct 19, 2016 at 01:01:18PM -0700, Conrad Meyer wrote: > On Wed, Oct 19, 2016 at 12:00 PM, Beach Geek wrote: > > This came across my tech news feed. It's a bit early and more testing is > > being done, but I wanted to start a discussion about it. > > > > Does this affect FreeBSD? > > If so, severity? > > Can this be countered/fixed in the OS? > > > > Link to 13 page paper: > > http://www.cs.ucr.edu/~nael/pubs/micro16.pdf > > Hi, > > FreeBSD doesn't have an ASLR implementation to bypass. So the > straightforward answer is no. It does not affect FreeBSD's existing > code. > > There is an open question of whether it affects or obviates > Konstantin's userspace ASLR patch which is waiting to be merged. > > The paper suggests a really lame and difficult software mitigation on > page 10. On page 11 it suggests a possible HW mitigation, but that > does not yet exist in any CPU of course. > > The userspace ASLR attack is somewhat limited. Key quotes: > > > Our prototype code tests 100 addresses in a second. > > 2^18 / 100 ~= 2^7 or ~2^11 seconds is about 35 minutes. > > > Please note that current BTB addressing scheme (as used in Haswell processor used for our experiments) allows us to recover only a limited number of ASLR bits. The number of bits that are randomizes is implementation specific. However, according to [47], the full ASLR in Linux randomizes 12th to 40th bits of the virtual address. Since 30th and higher bits are not used in BTB addressing, only 18 bits can be recovered using the BTB attack on Haswell. > > So it seems ASLR may still be somewhat useful on amd64, especially if > bits above 30 are randomized (Haswell anyway). But it may be > completely useless on i386. ASLR is almost useless obfuscation scheme, which does not give much, except possibly a buzzword compliance. In fact, it does have the value, by allowing you to note persons who promote it, and to make required conclusions. It seems that finding a clever tiny trick that circumvents whatever obfuscation provided by any ASLR implementation, is the required initiation step for the low-level security researchers. Reading the interesting pdf that was linked in the initial mail, I admit that I was more impressed by the recent presentation about using PREFETCH instructions to recover kernel address map in presence of KASLR, see https://www.blackhat.com/docs/us-16/materials/us-16-Fogh-Using-Undocumented-CPU-Behaviour-To-See-Into-Kernel-Mode-And-Break-KASLR-In-The-Process.pdf This is mostly equivalent thing, using cache timing instead of BTB timing. You will quickly find a dozen or two of the similar 'exploits' by Googling for several minutes.