From owner-freebsd-hackers@freebsd.org Fri Oct 21 15:34:20 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 C8659C1B77F for ; Fri, 21 Oct 2016 15:34:20 +0000 (UTC) (envelope-from labeachgeek@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 80960ED; Fri, 21 Oct 2016 15:34:20 +0000 (UTC) (envelope-from labeachgeek@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id t193so100061181ywc.2; Fri, 21 Oct 2016 08:34:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8l68HrywYe4MwkFnS8dUiAQnBpD/rUQglK/AzLXVQlI=; b=wwxogk6viyLcpWEXr/nuaQnsV4PLXp9UPMCne8AnKAjX5F7um94sE1t/drpJ4I9/Kh rniTpzPdBs9y3Uq8EpfuXyT7cI3QPE1sOJzp+YPqNY5LlbHo4xNDkQQukDSwWldKx5RF dL38TscRjmbYxQCMpTaPJaFgogWgNlWSslgOrTPZebmxtPTfrMujFu+3qyLfJ20/Ys2M 93vw4BO34oY/xzRsACKiBi+YiY2xTyaCUHN9k7Nr6p2+rlWzQ4wmAKqjVnBGqX5hP9gm i/1uHDEA+bT64Zgv9//M4PGqfGIr0nala0SJnbaeiAsmZT8yctxmq66aWKnXnKKlWkOn fVRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8l68HrywYe4MwkFnS8dUiAQnBpD/rUQglK/AzLXVQlI=; b=PRs1c326yHCEERTIU+08fSCoRbsJrIw2ptN6kYr0hzMkP6zik5LYRtNcqw3s/jStEy HOxTF/J7KpqiGDiYjsDaJLzZhwUXEqIUbLtUMzRwU1NXhNTYaL55ccpo+ufQ7tD7LD++ 2s1EEb00OcCbN+hkXOLyRUBPSFSf0W6MoxZ90IVpW4uipHAnVcqrNe1CsgvwtcwAggwg +gPb0uCmukFGiTFWBOyDbZSBbcQjkJla7ZkGvSIWQSyEF3vJZmCQ0YMmktvSXqmkjJEh nUyCh8U1gFEoCxvhUEHwNyqWqtutICl3Rd6lq8SJ6ZTNmEYLLZqH93EvhTaAfmxK6cuA Hzmg== X-Gm-Message-State: AA6/9RnBLPDu5p+MYAURDik868I/Qi4UAtQTw0KXpxoaiLAMkW+yyj7THWbbiP+/QY976oTdpE9NuwxY5Dqbbg== X-Received: by 10.202.196.204 with SMTP id u195mr11846286oif.150.1477064059626; Fri, 21 Oct 2016 08:34:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.220.85 with HTTP; Fri, 21 Oct 2016 08:34:18 -0700 (PDT) Received: by 10.202.220.85 with HTTP; Fri, 21 Oct 2016 08:34:18 -0700 (PDT) In-Reply-To: <20161020122559.GO54029@kib.kiev.ua> References: <20161020122559.GO54029@kib.kiev.ua> From: Beach Geek Date: Fri, 21 Oct 2016 10:34:18 -0500 Message-ID: Subject: Re: Attacking Branch Predictors to Bypass ASLR To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, Conrad Meyer X-Mailman-Approved-At: Fri, 21 Oct 2016 16:30:03 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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: Fri, 21 Oct 2016 15:34:20 -0000 On Oct 20, 2016 07:26, "Konstantin Belousov" wrote: > > 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. Thank you for the responses. I was sure I'd get questions about this, and they just started coming in today. We're in the process of hardware upgrades and handling that has all my attention and time currently. Thanks again, BG