Mark Williamson wrote:
This vulnerability could (in principle) affect isolation between Xen VMs.
It's not clear how exploitable it is, though.
It's clear that it is very exploitable.
On a real world system?
Yes.
"To ensure that the two processes run simultaneously, we start running the Spy
process before we start OpenSSL, and stop it after OpenSSL has finished, while
minimizing the number of other processes running"
The only critical issue is that the crypto code and the Spy process run
simultaneously on different threads of an HT processor. In a real situation,
there are any number of ways this could be arranged. The simplest way to get
the timing right would probably be for the attacker to initiate an SSL
connection himself.
In the case where the attack is performed between hypervisor domains, it's
easy for the attacker to ensure that the Spy is the only code running in
his domain.
That's fine as a proof of concept but it's not the real world.
The author is not attempting to do a real world attack. He's simplifying the
situation as much as possible, in order to get clean data, simple exploit
code, and a set-up that is easy to describe and reproduce. That's what you
always do (speaking from experience) when trying to demonstrate attacks
that depend on timing. Unfortunately there is the hazard that people may
think that restrictions you introduced just as a simplification, are actually
necessary preconditions for the attack.
A real attack would be a bit more complicated, but no less feasible.
Note that I'm not denying a persistent attacker may still capture a key
eventually, even in a very "noisy" environment.
I think you're overestimating how noisy a real environment would be. There
would be no interference from other processes, because an OS time slice in
the victim domain is long enough to almost always run the whole of the crypto
operation (in this case a modular exponentiation). Even if it wasn't, it
would be easy to recognize when a context switch occurred. Within a time
slice the crypto code and the Spy are the only two processes using the
shared cache.
The paper includes code for the side channel attack (Figure 1
in <http://www.daemonology.net/papers/htt.pdf>), and even if it didn't, it
would be easy to replicate.
I admit I hadn't noticed the code included could be used in the side channel
attack - it's a fair cop guv! It's worrying - we should watch what the other
OS communities do on this.
I think the FreeBSD fix implements the approach suggested in the paper of
not scheduling threads with different privileges on the same HT processor.
In Xen, this would correspond to only giving any particular domain a whole
HT processor. I'm not sure how that would affect performance; it could result
in only one thread of an HT processor being used in some cases, but OTOH cache
utilization might improve in others.
--
David Hopwood <david.nospam.hopwood@xxxxxxxxxxxxxxxx>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home