Meltdown & Spectre, Oh My

If you follow any infosec sources you’ve probably already heard a lot about Meltdown and Spectre, Kaiser and KPTI. If not, you’ve probably seen headlines like Major flaw in millions of Intel chips revealed or Intel sells off for a second day as massive security exploit shakes the stock.

What is it?
These are all about a cluster of related security issues that exploit features shared by almost all modern, high performance processors. The technical details of how they work are fascinating if you have a background in CPU architecture but the impact is pretty simple: they allow programs to read from memory that they’re not supposed to be able to read.
That might mean that a program running as a normal user can read kernel memory, allowing a malicious program to steal passwords, authentication cookies or even the entire state of the kernels random number generator, potentially allowing it to compromise encryption.
Or it might mean a program running on a virtual machine being able to escape from the sandbox the virtual machine’s hypervisor keeps it in and reading memory of other virtual machines that are running on the same hardware. A malicious user could sign up for a cloud service, such as Amazon EC2 Google Code Engine or Microsoft Azure, repeatedly create temporary virtual machines and grovel through all the other virtual machines running on the same hardware to steal, login credentials or TLS private keys.
Or it might mean a malicious piece of javascript running in a browser from a hostile website or a malicious banner ad being able to steal secrets and credentials not just from your web browser, but from any other software running on your laptop.
It’s pretty bad.
Meltdown and Spectre
One variant has been given the snappy name Meltdown. It (mostly) affects Intel CPUs, and is trivial to exploit reliably by unskilled skript kiddies. It can be mitigated at the operating system level, and all major operating system vendors are doing so, but that mitigation will have significant impact on performance – perhaps 20% slower for common workloads.
The other variant has been named Spectre. It’s more subtle, relying on measuring how long it takes to run carefully crafted code. Whether the code is fast or slow tells the malicious actor whether a particular bit of forbidden memory is zero or one, allowing them to step through reading everything they want. This is likely to be harder to exploit reliably, but is also going to be much harder to mitigate reliably in software (I’ve seen some speculation that it might be impossible to mitigate – I’m pretty sure that’s not true, but it is going to be difficult to do so reliably and will probably have significant performance impact). It affects pretty much everything, including AMD processors (despite what their PR flacks would like you to believe).
What should you do

As a typical end user you should apply your security patches as normal to mitigate Meltdown. macOS was patched on December 6th, the Windows kernel has mitigation in place. The latest release candidate of the Linux kernel has mitigation patches in place, which’ll presumably trickle out to various distributions over the next few days.
You should also update your browser. One nasty vector Spectre can use is timing attacks from malicious javascript. Chrome and Firefox have partial mitigation in their mainline development, and Microsoft have announced fixes for IE11 and Edge.
Keep updating your ‘phones. At least some of the ARM chips in iPhone and Android are vulnerable, and the more constrained ‘phone environment may make targeted attacks more likely.
If you’re using any virtual machines or cloud hosted services then your provider has probably already done rolling reboots so they can patch their hypervisors to mitigate Meltdown. You’ll still need to update your kernel yourself, to protect against attacks within your machine, even though your provider has patched their hypervisors.
Performance (and Email)
The operating system level mitigation for Meltdown works by having the CPU throw away a bunch of information every time the thread of execution goes from the kernel back to the application. Most common applications will switch between kernel code and application code a lot so this has a significant performance impact.
Initial tests with PostgreSQL show slowdowns as bad as 23%, but more realistic workloads look to be maybe 5-15% slower, depending on the workload and the hardware features available.
I wondered whether there’d be much impact on network service performance, so I set up a test network with a couple of mailservers running latest release candidates of the Linux kernel. I sent mail from one to the other, using postfix, smtp-source and smtp-sink – smtp-source and -sink are test tools distributed with postfix that make it easy to send mail or to receive and discard mail.
I wasn’t really expecting to find any performance impact for something that was likely network limited, but ran some tests anyway, slinging a few million emails from one machine to the other and turning mitigation on and off on the sender and receiver. There wasn’t any performance impact that I could measure – if it’s there it was well below the noise floor.
So you’ll probably see slight performance degradation for some things, especially disk-heavy workloads, but nothing to worry too much about.

Related Posts

Compromises and phishing and email

Earlier this month, Sendgrid reported that a customer account was compromised and used for phishing. At the time Sendgrid thought that it was only a single compromise. However, they did undertake a full investigation to make sure that their systems were secure.
Today they released more information about the compromise. It wasn’t simply a customer account, a Sendgrid employee’s credentials were hacked. These credentials allowed the criminals to access customer data, and mailing lists. Sendgrid has a blog post listing things customers should do and describing the changes they’re making to their systems.
Last month it was Mandrill. Today it’s Sendgrid. It could be anyone tomorrow.
Security is hard, there’s no question about it. Users have to have access. Data has to be transferred. Every user, every API, every open port is a way for a bad actor to attempt access.
While it wasn’t said directly in the Sendgrid post, it’s highly likely that the employee compromise was through email. Most compromises go back to a phish or virus email that lets the attacker access the recipient’s computer. Users must be ever vigilant.
We, the email industry, haven’t made it easy for users to be vigilant. Just this weekend my best friend contacted me asking if the email she received from her bank was a phishing email. She’s smart and she’s vigilant, and she still called the number in the email and started the process without verifying that it was really from the bank. She hung up in the transaction and then contacted me to verify the email.
She sent me headers, and there was a valid DMARC record. But, before I could tell her it wasn’t a phishing email, I had to go check the whois record for the domain in question to make sure it was the bank. It could have been a DMARC authenticated email, but not from the bank. The whois records did check out, and the mail got the all clear.
There’s no way normal people can do all this checking on every email. I can’t do it, I rely on my tagged addresses to verify the mail is legitimate. If the mail comes into an address I didn’t give the sender, then it’s not legitimate – no matter what DMARC or any other type of authentication tells me. But most people don’t have access to tagged or disposable addresses.
I don’t know what the answers are. We really can’t expect people to always be vigilant and not fall for phishing. We’re just not all present and vigilant every minute of every day.
For all of you who are going to tell me that every domain should just publish a p=reject statement I’ll point out DMARC doesn’t solve the phishing problem. As many of us predicted, phishers just move to cousin and look alike domains. DMARC may protect citi.com, but citimarketingemail.com or citi.phisher.com isn’t.
We’ve got to do better, though. We’ve got to protect our own data and our customer’s data better. Email is the gateway and that means that ESPs, with their good reputations and authentication, are prime targets for criminals.

Read More

Target breach started from email

According to Brian Krebs the compromise of Target’s POS system probably originated with a phishing attack against one of Target’s vendors. This attack compromised credentials of the HVAC vendor and possibly allowed the hackers entrance into Target’s systems.
Interestingly, Brian mentions Ariba, a company I’ve been forced to deal by a large customer of ours. I’m not sure if there really is an attack vector where a vendor can get access through Ariba to the internal systems of the customers. However, my experience with Ariba has been frustrating and problematic, so I’ll be happy to believe their security is as broken as their email.
Email is a great way to interact with people and companies. It’s great for growing communities and businesses. But it is also a way for attackers to get access to your computer and the websites you interact with. Protect yourself, and your company, by running security software. And, please, don’t open attachments or click on links in emails and provide usernames and passwords.

Read More

Ashley Madison Compromise

Last month Brian Krebs reported that the Ashley Madison database was compromised. Ashley Madison is a dating site that targets married folks who are looking to have affairs. Needless to say, there is a lot of risk for users if their data is found on the released data. Today what is supposedly the Ashley Madison data was released.
The release of this data can have some significant impacts on the site members. Of course there’s the problem of credit card numbers being stolen, but that’s something most of us have to deal with on a regular basis. But there can also be significant relationship repercussions if/when a spouse discovers that their partner has registered on a site to have affairs.
When I first heard of the compromise I wondered if they had my data. You see, they have one of my spamtraps on their unsubscribe list. It just so happened that I visited an unsubscribe link, hosted by Ashley Madison (http://unsub.ashleymadison.com/?ref=2). This was during the time when I decided to unsubscribe from all the spam coming into one of my spamtraps. Is my email address going to be a part of this data dump? If my email address is there, what name do they have associated with it? This is the trap that gets mail addressed to multiple other people. Maybe it’s my email address but their name. Are they at risk for relationship problems or legal problems due to my attempt to unsubscribe?
Of course, Ashley Madison had no incentive to make sure their data was correct. In fact, they were sued for faking data to entice paying members. How much of the released data is false and will there be real harm due to that?
I expect in the next few days someone (or multiple someones) will put up a website where those of us who are curious can search the data. I just hope that people realize how much of the data is likely to be false. Even Arstechnica cautions readers from jumping to conclusions.

Read More