CSCI 8970 – Colloquium Series – fall 2010 – Thirteenth Event
Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography
Monday, December 13, 2010
Presenter: Scott Yilek, University of St. Thomas
While virtualization has increased the reliability of online services as well as the ability for individuals to back up their whole system without being complete worried about losing everything in case of a complete system failure, despite the high rate of success and applicability, some problems have developed from the use of virtualization. Dr. Yilek showed us how virtualization could result on a system being compromised and secret signing keys revealed after the startup of a virtualized system. Virtual Machines started in the 1960s (IBM) and are currently used today by Amazon web services, windows azure, sun virtual box, vmware, among others. They have since contributed substantially to the current boom. Virtualization allows for the emulation of virtual hardware. As such, hundreds of machines can be in one physical machine. If the physical machine crashes, one can move the virtual machine to another virtual machine. The copy of the machine including a snapshot stored for later use. If virtual machine gets compromised, the business or household can reload snapshot state (like a word processor).Through this new technology, applications now provide for an improved flexibility, efficiency and security. Unfortunately, there are reset vulnerabilities exists when utilizing a VM snapshot
The security dangers primarily affect TLS and SSL clients. When keys are used to secure an attack on TLS/SSL Clients TLS/SSL session and then a session is reloaded, then the keys could be compromised. Adversary can learns repeated random key K and learn even one’s bank password! Testing for vulnerabilities, vulnerabilities were found in Firefox 3.5 both in Windows XP and Ubuntu, Chrome 3.0 was vulnerable in Ubuntu, while IE 6.0 and Safari 4.0 were not vulnerable to this problem. The results were the same on both VMWare Server and Virtual Box. Underlying this problem is a potential problem anywhere snapshots are used. Testing for this problem in other system, Dr. Yilek found the same problem using the Apache web server.
The bugs we found lie at the intersection of several technologies where virtualization clashes with the random number generation application cache randomness for later use. Applications rely on environment for generating unpredictability. As such cryptography routinely fail when given poor or repeated randomness.
The problem they found originates when a browser is stared in a VM and a later snapshot records the TLS/SSL key. Part of the problem lies in that randomness is generated long before it is used (usually generated when the browser is opened). This randomness is cached and the cryptography loses its security when a VM uses the same randomness but sends it to a malicious website (instead of your bank for example). Firefox modifies its randomness every time the mouse is moved. Is the mouse is moved 100 pixels then the security threat is eliminated. An obvious solution to the problem would be to move the generation of randomness closer to its application synched after requests are served (like 2 or 3 seconds later), this delay can lead to future runs from same snapshot resulting in same R’ used in DSA signing. From system/application perspective RNG is updated close to when randomness needed, but there is not enough unpredictability. DSA is fragile: signing twice with the same randomness reveals the secret key. After finalizing the study, they told Chrome and Firefox about their findings but they were not yet what to do about them. VMWare was fine with the results, since their virtualization app is working properly.
Looking at this problem from a cryptographically perspective, Yilek promotes re-designing cryptographic primitives to be less fragile and through the use of hedged cryptography. Cryptographers assume bountiful good randomness when designing protocols and assessing their security. Yet this is not necessarily the case and it affects both long term and short term keys. Random number generation is hard and history is history filled with spectacular failures. A way to reduce this is by hedging against bad randomness. With almost all traditional cypto, if randomness is good, then strong, provable security guarantees. Yet if randomness is bad, then the system can be completely insecure. With hedged cryptography, if randomness is good, then strong, provable security guarantees. If randomness is bad, then still provably as secure as possible. Hedging does not impact functionally and it would increases security. If hedging is used both of the attacks could be prevented!
Having only a limited background in cryptography but using virtualization on a regular basis this colloquium provided me with a greater insight into some of the concerns that while they may seem insignificant (3 to 4 second for Apache to sync the clock), those small time frame can compromise your computer system and your private account information. As Dr. Yilek emphasized, unfortunately, history is riddled with major cryptography problems. Hopefully little by little this problems will become more of a fluke than a regular occurrence. We can safely infer that this is the case, but more needs to be done to improve network security.
