AMD Epyc processors support Secure Encrypted Virtualization (SEV), a technique that prevents even a hypervisor reading memory belonging to a virtual machine. To pull this off, the encryption and decryption is handled on the fly by the Platform Security Processor (PSP), which is an ARM core that handles processor start-up and many security features of modern AMD processors. The vulnerability announced this week is related to the encryption scheme used. The full vulnerability is math heavy, and really grokking it requires a deeper understanding of elliptical curve cryptography (ECC) than your humble author currently possesses.
During the process of starting a virtual machine, the VM process goes through a key-sharing process with the PSP, using an ECC Diffie-Hellman key exchange. Rather than raising prime numbers to prime exponents, an ECC-DH process bounces around inside an elliptical curve in order to find a shared secret. One of the harder problems to solve when designing an ECC based cryptographic system, is the design of the curve itself. One solution to this problem is to use a published curve that is known to be good. AMD has taken this route in their SEV feature.
The attack is to prime the key exchange with invalid data, and observing the shared key that is generated. A suitably simple initial value will leak information about the PSP’s secret key, allowing an attacker to eventually deduce that key and decrypt the protected memory. If you’d like to bone up on invalid curve attacks, here’s the seminal paper. (PDF)
OpenSSH Shielding
[Damien Miller] of OpenSSH was apparently tired of seeing that project tied to vulnerabilities like Rambleed and Rowhammer, so added a technique he’s calling key-shielding. OpenSSH now encrypts private keys in memory using a 16 kB pre-key. While an attacker with full knowledge of the process’s memory wouldn’t be deterred, the error rate of Rambleed and similar attacks is high enough that the 16 kB of randomness is likely to thwart the attempt to recover the secret key.
Firefox and Coinbase
We mentioned Firefox vulnerabilities and updates last week, and as anticipated, more information is available. [Philip Martin] from Coinbase shared more information on Twitter. Coinbase employees, as well as other cryptocurrency companies, were targeted with fishing emails. These lured employees to a malicious page that attempted to exploit a pair of Firefox vulnerabilities. Coinbase has a security system in place that was able to prevent the exploit, and their security team was able to reverse engineer the attack.
The first vulnerability has been dissected in some detail by a Google security researcher. It’s a weakness in Firefox’s Javascript engine related to type handling. An object is created with one data type, and when that data is changed to another type, not all the data handlers are appropriately updated. Under the hood, a value is assumed to be a pointer, but is actually a double-length value, controlled by the attacker.
The second vulnerability is in the functions used to prompt for user interaction. Specifically the call to “Prompt:Open” isn’t properly validated, and can result in the un-sandboxed Firefox process loading an arbitrary web location. I suspect the sandbox escape is used to run the initial exploit a second time, but this time it’s running outside the sandbox.
Odds and Ends
[Tom] wrote a great intro into how to Impersonate The President With Consumer-Grade SDR, go check it out!
Another city, more ransomware. Riviera Beach, Florida was hit with a ransomware attack, and paid $600,000 in an attempt to get their data back. For a city of 35,000 inhabitants, that’s $17.14 in ransom per man, woman, and child. According to the linked article, though, the city was insured.
“Another city, more ransomware. Riviera Beach, Florida was hit with a ransomware attack, and paid $600,000 in an attempt to get their data back. ” ..
Maybe they could try, ya know, having backups ?
“Maybe they could try, ya know, having backups ?”
Unfortunately, many institutions that don’t have their own knowledgeable IT staff (as inferred from the fact that the city spokesperson said they were acting on the advice of “consultants”) opt to have “live” backups which in a case like this get encrypted too. Of course, there are also many that, as you say, simply don’t have backups at all…
It’s a difficult problem to solve, how to give a machine the ability to backup, without the ability to erase those backups. It’s certainly possible, but takes an intentional effort.
One could just make a backup of everything all the time. Keep any changes as yet another backup.
Erasing simply is out of the question.
Downside with this is that it consumes a lot of storage.
Another simple solution is to have a rolling backup of the last week or so. Constantly overwriting the old stuff. (Ie, only overwrite stuff that is older then x weeks, and that one has backed up newer versions of already.) This would be more storage efficient, but if one doesn’t detect the ransomware attack for an extended period of time, then one can still lose data. Though, not detecting ransomware for a whole week or two is a bit weird in and of itself…
If the machine can overwrite old backups, then a ransomware attack on that machine can also overwrite the backups. That’s why it’s a challenge.
Exactly. One of those automated tape libraries would cost much less than the $ 600k they had to pay.
And if not that much data, for some single institution, a tape drive, a designed operator and lets say 30 taps would not break the bank also.
Jonathan Bennett
Yes, if the infected machine can overwrite backups, then yes it can whip one’s backups as well.
This is why we should preferably run the backup system on its own machines, and have that machine’s software have a bit more security in mind. (ie, don’t run crap on it that isn’t specifically needed for the backing up of data.)
Though, making proper secure environments is not really a trivial task… But one can at least use some forethought into trying to limit the amount of potential security flaws. (ie, if one doesn’t need something, then don’t run it…)
“Downside with this is that it consumes a lot of storage.”
ZFS snapshots. If relatively little data changes each day then the savings are staggering.
How does one prevent an attacker simply erasing the snapshots?
I don’t really agree it’s difficult. Just get some physical switch somewhere. For my home use it’s an USB cable i plug in only for backups.
It’s not difficult, and is a long solved problem. It’s actually very simple of a concept.
You don’t have the backup target push data to the backup repository, but instead go the other way around. The backup system should connect to and pull data from the targets.
This way you can focus protection of the backup system (no incoming connections, only outbound and only to the targets) while you centralize the keys/credentials there. No storing credentials for the backup system on the at-risk targets.
This also has the accidental bonus with ransomware that, between getting infected and the ransomware deleting its own encryption keys, the ‘encrypt all the data’ phase can take some time to finish, and the ransomware decrypts files on-the-fly to the system to avoid detection.
So right up to the moment it finishes and deletes its keys, your backup system is pulling good valid data.
If you’re pulling backups daily, but got infected three months ago, once the ransomware triggers you still have a perfectly clean backup of data from yesterday.
Probably the conslutants were very well paid. Nice that the city can find consultants in short notice for such an important matter, but would say they don´t have IT staff ?
Also, the part about they agreeing to spend $1 million “to buy new computers and hardware” also looks like the kind of dumb decision government people do when spending *our* money.
From the list of services affected, they have no infra-structure nor planing. Seems most of the important things ( 911, financial ) are just running in common machines, which the employees uses to keep tabs in their facebook accounts while working. Not a recipe for a trustable and stable system.
Isn’t having offline backups required by law in the US?
No.
Some entities are required by law to satisfy a data retention policy of a certain time, but even then, how to go about it isn’t codified into law.
Amazing! Here every municipality has to have a backup system in place, online and offline, test its readability on a regular basis and be prepared to have a fully working system within 48 hours of a calamity. I think it is insane that a country as the US has to pay criminals to get their data back!
The Risk Management Framework (RMF) [1] address all matter of things like this. (COOP, backups, disaster recovery). But while the DoD uses this, state governments might not have the same detail to accredit systems and applications.
[1] https://csrc.nist.gov/publications/detail/sp/800-53/rev-4/final
I wonder how much added latency the elliptical curve cryptography imposes on the Epyc processors.
After all, memory is already really far away, and cache misses is annoying enough as is….
Surely there could have been simpler ways of securing the data from software level attacks.
Like keeping a local table (in the security system) of what content belongs to what VM, and simply always return an empty answer when asked to access something that one technically doesn’t have access to. The answer would always be of a fixed time duration, and always contain nothing. So even a timing level attack would be pointless. Since we never even look at cache. And VM’s that shouldn’t have access to the data can’t cache it to begin with. (Though, over-complicated solutions to simple problems is kinda the name of the game these days…)
The elliptical curve is only to negotiate the actual encryption key. I’m not sure what encryption standard is used, but I’m sure it’s one of the speedy routines.
Hopefully it is really speedy. Since technically speaking, every cycle counts. (Though, the difference in performance if it takes 3 cycles or 5 cycles might not be all that “noticeable”.)
Though from a pure software security standpoint, there is no major need for the memory to be encrypted, since the memory management system simple shouldn’t allow any unauthorized process to access that memory regardless. (This could honestly be done with a simple lookup table…. If one makes an assumptions that a VM only uses a specific set of cores, and is the sole user of those cores. Running multiple VMs on the same core makes the problem a lot more complicated. Though, then there is PCI with its DMA, so…..)
Though, from a hardware security standpoint, one could read out the data by tapping into the memory buss. But if someone unauthorized has physical access to one’s hardware, then there is likely other more important security problems to be fixed. (unless one doesn’t trust one’s own sysadmin…)