[Xen-devel] Impact of HW vulnerabilities & Implications on Security Vulnerability Process

[Lars Kurth <lars.kurth.xen@xxxxxxxxx>]

Dear community members,

A few years ago it was discovered that much of the RAM shipped in our
computers contains flaws which allow "leakage" across rows; effectively
allowing programs to use access to one bit of memory to flip bits in
other parts of memory to which they have been specifically denied
access.  This has attack on faulty hardware has been dubbed "rowhammer" 
[1].

As time has gone on, researchers have continued to refine rowhammer
techniques and attacks, increasing the probability and speed of finding
rowhammer vulnerabilities, their effectiveness at making unauthorized
changes to memory, and the methods of using these changes in order to
escalate privilege.  Last year Google published demonstrated an attack
on Linux [2]; and a recent Usenix conference had three papers containing
rowhammer attacks, one of which demonstrated an attack on KVM [3], and
one of which demonstrated an attack on Xen PV guests [4].  It is only to
be expected that the techniques will continue to advance over time.

[1] http://users.ece.cmu.edu/%7Eyoonguk/papers/kim-isca14.pdf
[2] 
http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
[3] 
https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_razavi.pdf
[4] http://web.cse.ohio-state.edu/~yinqian/papers/sec16.pdf

The underlying bug is clearly not a software bug, which raises a number of 
technical as well as process questions:
* Process: whether we should handle such vulnerabilities as XSAs
* Technical: to which degree is rowhammer (or similar HW   
  vulnerabilities) affecting Xen, is the threat theoretical or real 
  and are there any technical mitigations we could implement other than 
  not using PV (using the rowhammer example)

I am starting this discussion, as the information is already in the public 
domain. 

Process
=======
From a process perspective, these new class of hardware vulnerabilities 
raise the question whether the project should treat them as XSAs (even 
if just informational purposes), or not. My understanding of the issue 
is that this is a hardware bug, which cannot be fixed by a Xen software 
patch (please correct me if wrong).

Looking at the process 
[5] https://www.xenproject.org/security-policy.html
the scope of the process currently is "vulnerability in Xen Project software" - 
see bullet 1 

A general observation in [5] is that the "Introduction" and "Scope of 
this process" sections are a little unclear and could probably be 
improved. In particular with a view of how we deal with vulnerabilities 
in upstreams such as QEMU, Linux, ...), vulnerabilities in experimental/preview 
code, and HW vulnerabilities, ...

From my perspective, there are a number of differing goals we are trying 
to achieve with the process

a) Ensuring that pre-disclosure members can deploy patches before 
   information becomes public

b) If already public (or at disclosure time), ensure that our users have 
   all the information to make the right choices

In this case, a) does not apply as there are no patches that can be 
applied, but b) would.

However, we are also other considerations/trade-offs

c) Widening the scope of the process, obviously creates more work-load   
   for the security team
   We had some issues with upstream vulnerabilities in QEMU in the past:    
   for a while we did not have a clear policy, which led to a growing
   influx of upstream vulnerabilities being reported
   to security@xenproject instead of the upstream projects. This 
   eventually forced us to tighten our criteria to only cover 
   vulnerabilities of upstream that affect supported configurations.

d) Also, XSAs are monitored by the tech press, and frequently result in 
   media coverage.
   The coverage is not always fair, and often technically incorrect. 
   Treating HW vulnerabilities like XSAs carries the risk that 
   vulnerabilities like rowhammer will be closely linked with
   Xen, due to mistakes by reporters, and ultimately damage the 
   reputation of the project. This would in particular be true if 
   competing projects/commercial products, do not treat Hardware 
   issues in the same way. 

As an aside, there has already been ample coverage on rowhammer/Flip 
Feng Shui attacks, but none of the stories published were Xen specific. 
If we were to publish an XSA, that would VERY LIKELY change. 

Technical
=========
On the technical front, it would be good to understand whether
a) This is a real threat and whether thus, we as a community need to 
   take action 
b) Whether the technique described in [3] is serious on big iron with 
   different core/cache properties compared to some of the machines this 
   was tested on
c) Whether there is any mitigation that we can develop, if necessary

In any case, it is probably a new type of attack vector, that we need to 
consider and keep in mind, when developing new features.

Best Regards
Lars
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel