Attacking Branch Predictors to Bypass ASLR

[Beach Geek]

On Oct 20, 2016 07:26, "Konstantin Belousov" <kostikbel at gmail.com> 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 <labeachgeek at gmail.com>
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