[Cryptography] 33C3: cash :-) attacks !

[Ian G]

On 10/01/2017 01:29, Kevin W. Wall wrote:

> On Sun, Jan 8, 2017 at 2:27 PM, Henry Baker <hbaker1 at pipeline.com> wrote:
>> FYI --
>>
>> https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wrong_with_insert_x86_instruction_here
>>
>> https://cdn.media.ccc.de/congress/2016/h264-hd/33c3-8044-eng-What_could_possibly_go_wrong_with_insert_x86_instruction_here.mp4
>>
>> (55 mins; 327 MBytes)
>>
>> "What could possibly go wrong with <insert x86 instruction here>?
>> Side effects include side-channel attacks and bypassing kernel ASLR"
>>
>> Clémentine Maurice and Moritz Lipp
> So I just finished watching this. My initial thought is that between
> this, rowhammer, FBI Rule 41, and NSLs, we are all pretty much screwed
> as TLAs and nation states are pretty much always going to be able to
> do this.
>
> It still seems like a pretty esoteric attack that is unlikely to be most
> attacker's _first_ choice, but as I don't see any simple mitigation for this--
> short of disabling cache, which no one is likely to do except in very
> rare cases--it seems like this is always going to be available as a last
> resort and AV is not going to be able to detect it.
>
> So what, if anything, do we do? Timing attacks are rare IRL, but
> usually that's because there's almost always some easier way in. Since
> I work in appsec, I'm always more interested in what we can do to
> manage the risk. Any ideas?
>
> -kevin

55 minutes of fun!

Two of the attacks (at least) rely on shared libraries which results in 
a shared cache area in LLC (last level cache), and the dramatic 
difference between a cache hit and a cache miss for memory access. The 
attacker can watch what happens to his view of the cash.  Or, the 
attacker can pre-load the cache and see how the victim responds.

   ==> So, if we turn off shared libraries ... does that mitigate those 
attacks?

Their target attack focussed on AES T-Tables which have pre-computed 
look-up tables, which turn keys into indexes.  Listen and profit!

   ==> Back to pure code algorithms?

The attack(s) are statistically measurable by looking at the high cache 
activity.  But they were able to slow down the attack and tune for 
stealth, and avoid the detection.

The attack on the android keyboard/password is again a table-lookup.  By 
identifying the table in the code, they were able to attack the 
addressing and reverse the locations of the key presses, leading to the 
letters being pressed.

   ==> passwords without table look-ups?

The covert channel description of delivering 0s and 1s via cache 
stuffing "prime & probe" is really fun.  I'm not convinced it is 
realistic but it's a great example of sexing up a presentation. 
40-75KBps between AWS vms allowed them to mount an SSH connection over 
the covert channel.

They also exploited direct kernel direct memory mapping to reverse out 
the physical addresses from virtual addresses.  Allows attacker to find 
kernel drivers.  Point of this was not clear to me, it related to other 
attacks.

And a bunch of other attacks related to other instructions.  Their 
conclusion was that there is so much leakage going on with many 
instructions that simple instruction level mitigations won't help.

   == Don't use VMs?

Not sure how well this will work with mobile phones...



iang