[Cryptography] Speculation re Intel HW cockup; reqs. OS rewrites & slow execution

[Bill Frantz]

For those who like unfiltered information about these problems:

Spectre: <https://spectreattack.com/spectre.pdf>
Meltdown: <https://assets.documentcloud.org/documents/4343429/Meltdown-paper.pdf>

On 1/6/18 at 7:34 PM, stephen.farrell at cs.tcd.ie (Stephen 
Farrell) wrote:

>On 05/01/18 19:55, Tom Mitchell wrote:
>>It is not x86 but the design decisions to make their part execute code
>>quickly.
>
>I think this is the main point - ISTM that performance has been
>seen as a way more important goal than security or privacy, and
>the same is (IMO sadly) still true. (See TLS1.3 and 0rtt, albeit
>that TLS1.3 is still an overall good thing.)

Part of the problem here is that performance is so easy to 
measure, sometimes even easier than, "Did I get the correct 
answer". Just how do you measure security or privacy? There is a 
human tendency to ignore things that can't be measured and pay 
attention to those that can.

>...

>More interesting for this list (or for me anyway:-) is whether
>or not there are any implementation countermeasures open-source
>s/w can take to better protect secret/private values if running
>on a guest-OS alongside other potentially bad guests. Other than
>obfuscating I'm not seeing many worthwhile avenues to explore,
>but would love to hear if there are.

For the Meltdown attack, which obtains information from kernel 
memory as fast as 500KB/sec, there is clearly a bug in the Intel 
chips. They do not check the permission bits before fetching 
during speculative execution. The attackers could not 
successfully perform their attack on AMD and ARM chips. Perhaps 
these chips do perform the permission check.

I think the approach taken by KeyKOS and other systems -- which 
didn't have the kernel pages mapped when user processes are 
running -- is a powerful way to avoid these problems. However 
this approach does have a significant performance hit. There may 
be ways to reduce the performance hit, but I think this approach 
will always be slower.

It should also be noted that the Spectre paper lists other 
possible covert channels in CPUs, but the authors haven't 
investigated them.

It seems to me that if two different protection domains share 
any kind of memory then there is a risk of using the speed of 
access to that memory as a covert channel to communicate 
secrets. With Meltdown, you can actually code you write to run 
as the transmitter (in the address space holding the secret).

The Spectre attack also requires some form of transmitter code 
in the sending address space. You can't, in general, write this 
code yourself, so you must discover it. Libraries are a fertile 
source of possible code "gadgets". Since you will be executing 
this code during speculation, the rules are very different, 
although the approaches are similar to those used in "Return 
Oriented Programming"[1]. In the case of the speculation attack, 
the attacker mistrains the branch predictor instead of 
overlaying the stack with a buffer overrun.

Cheers - Bill


[1] [from the Spectre paper] Return-Oriented Programming is a 
technique for exploiting buffer overflow vulnerabilities.  The 
technique works by chaining machine code snippets, called gadgets
that are found in the code of the vulnerable victim. More 
specifically, the attacker first finds usable gadgets in the 
victim binary. She then uses a buffer overflow vulnerability to 
write a sequence of addresses of gadgets into  the victim 
program stack. Each gadget performs some computation before 
executing a return instruction. The return instruction takes the 
return address from the stack, and because the attacker control 
this address, the return instruction effectively jumps into the 
next gadget in the chain.
-----------------------------------------------------------------------
Bill Frantz        | Privacy is dead, get over    | Periwinkle
(408)356-8506      | it.                          | 16345 
Englewood Ave
www.pwpconsult.com |              - Scott McNealy | Los Gatos, 
CA 95032