Interesting (impractial) OpenSSL attack
While I usually read El Reg for teh lulz occasionally they come up with an interesting nugget, like their article on a "severe" OpenSSL vulnerability (quotes theirs). This vulnerability comes to us courtesy of the University of Michigan, and is tied to a simple oversight in the OpenSSL code: It doesn't perform a verification pass on signatures before sending them to a client.
So all you crypto-nerds, how many of you do a verify on your signatures before you send them? Hands please? Nobody? Not even me? -- Yeah, we all tend to trust that our math Just Works. I mean it's a computer, you put in fixed input through a deterministic algorithm and you get the same output ever time. Right? Nope.
- Computers, as we all hopefully know, aren't perfect. Trillions of minor errors happen every day, and they're usually compensated for: ECC RAM, cross-checks of math, etc. But because OpenSSL doesn't do a cross-check it's possible for those minor errors to creep into a transmitted signature. As the good folks from UMichigan explain in their paper if you can induce some minor errors in the OpenSSL signature math and collect a good signature and a large enough set of flawed signatures you can eventually derive the private key used for the signing.
That is all well and good, except it relies on errors in the system generating the signatures. These errors are rare (and pretty random) in the real world, so no problem, right? Wrong again Sparky! These clever folks came up with something I wouldn't ever have thought of.
-
Those of you who have worked on old Commodore computers probably know one of the first symptoms of a power supply going wonky is that the system starts acting up: Lots of random crashes, video corruption, etc. Why does that happen? Because the voltage being supplied to the system is fluctuating. Fluctuating voltages (specifically down-swings) cause all the magical voltage regulation hardware to go out of regulation, which feeds out-of-spec voltages to the chips, which in turn start making mistakes in their math.
The bottom line for this attack is an extension of that well-known Commodore problem: By putting controlled voltage fluctuations into the power supply of real computers (SPARC boxen running Linux) the UMichigan folks were able to induce errors in the math used by the real-world OpenSSL code and recover an actual key.
Some Perspective
So why am I not screaming about this the way I screamed about Debian's "OpenSSL Fix" that totally broke randomness? Why is "Severe" in quotes?
Because this attack is absolutely fascinating, but highly impractical in the wild:
- Real-World servers are in datacenters, connected to UPS power.
While a voltage fluctuation isn't impossible it's certainly not easy to induce. - Real-World servers have ECC RAM (or should)
The same fluctuations that affect the CPU's math can also affect the RAM, and your server will start crying about lots of Single-Bit memory errors
(or if the voltage swings are wild, uncorrectable errors will make the server halt) - Every power supply these days, even the really cheap ones, has basic buffering.
If all you have access to is the AC supply (and if you're not cracking the case that's all you're gonna get!) it's damn hard to induce precise voltage fluctuations on the DC output of the power supply, and precision is important here.
- At the moment it's computationally expensive to deduce the key (about 5 days on a pretty nice cluster).
This is never an excuse as computers continue to get faster and cheaper, but at the moment it's damn hard. - The fix is really simple: OpenSSL needs to check signatures before it sends them. A patch is already in the works.
The chance of a busted signature passing verification is pretty slim: It would require a damn-near-impossible confluence of faults to make the signature AND the check algorithm fail in a way where verification would succeed, so the number of leaked "bad signatures" could be reduced to within epsilon of zero.
Interference from RF sources (induced current & incident voltage transients) as a potential vector is interesting, but even less practical because of the imprecision of RF targeting and the sheer amount of RF energy required to make this happen.
In practical terms anything likely to induce errors is also likely to crash the device, and that's pretty easy to notice.
So why the hell am I writing about this?
Dude, seriously: Deducing OpenSSL keys with a (sophisticated version of) a household lamp dimmer? C'mon: You know that's fucking awesome!
Also on a more serious note: This paper highlights that the principle of Trust but Verify extends all the way down to your hardware: OpenSSL blindly trusts that the CPU will not mess up, and as a result there is a definite vulnerability. Granted it's not easily exploited, but it's also trivially mitigated: A signature verification adds a little time & RAM usage to each signature operation but guarantees that bad signatures would (theoretically) never be leaked.
Trust but Verify is a point which is always worthy of echoing.
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded