I applaud the researchers however there's one thing I cannot understand at all: Intel was let know about some of these vulnerabilities (Meltdown and Spectre v1/v2) at the very least a year ago and to this date they don't have a single CPU where these vulnerabilities are mitigated at the hardware level. And according to rumors and leaked documentation they'll soon release yet another Skylake reiteration.
Spectre rises from the dead to bite Intel in the return stack buffer
Spectre, a class of vulnerabilities in the speculative execution mechanism employed in modern processor chips, is living up to its name by proving to be unkillable. Amid a series of mitigations proposed by Intel, Google and others, recent claims by Dartmouth computer scientists to have solved Spectre variant 1, and a proposed …
COMMENTS
-
-
Monday 23rd July 2018 22:26 GMT asdf
rome wasn't built in a day
Product design cycles are a lot longer than a year especially when you have to balance the fix against the tremendous performance increases the vulnerability gave your product. Not excusing Intel or chip makers in general especially since they spent billions acquiring McAfee which was supposed to increase their security (so showed they at least gave it lip service) but not surprised new products don't have the fixes yet.
-
Tuesday 24th July 2018 13:51 GMT Zippy's Sausage Factory
Aside the fuss about production cycles, my other question is why are people accepting delivery of broken parts in the first place? Maybe there should be legislation about putting warning stickers on things: "warning, this device has X known vulnerabilities". I suspect Intel would start taking it a bit more seriously then...
-
Tuesday 24th July 2018 15:37 GMT Jon 37
Re: Warning stickers
Sadly, it would go the way of the California cancer warnings.
Pretty much everything is "known to cause cancer" as far as the state of California is concerned, so pretty much everything and every building has to have a stupid warning sign. So the signs don't actually provide any useful information, and most people ignore them. The only people who like the signs are the lawyers, who make money suing anyone who doesn't have the signs up.
-
-
-
-
Tuesday 24th July 2018 20:24 GMT Roo
I agree with your assessment a_yank_lurker, but the thing that bothers me about Spectre class exploits is how do you detect them reliably in the wild ? Quite frankly I fully believe that at least a few Kskiddies to be trying it out in AWS right now.
From a risk management point of view nothing has changed, if you care about keeping stuff secret you don't share your box with anyone else. :)
-
-
-
Tuesday 24th July 2018 01:10 GMT amanfromMars 1
What you are not being told is that which rules and reigns and reins you. And 'twas ever the case.
Spectre, a class of vulnerabilities in the speculative execution mechanism revive doubts about whether current and past chip designs can ever be truly fixed and is revised to render the possibility and therefore assured probability that even all future chip designs will be unfixable.
Good questions to ask here are .... What is the fix for/what is the concern trying to prevent? Virtual Machines and SMARTR Autonomous Systems acting and doing the Internetworking Things their way?
You might like to consider that is both a battle and a war you can never win and all is already lost.
Does that register with you, a_yank_lurker and Mark 85, and answer your questions/concerns?
-
Tuesday 24th July 2018 05:20 GMT Schultz
Striatification
The hardware fix might require a rethinking of the processor architectures. Take the performance hit of non-speculative execution in one/several cores for safety-relevant processes. Separate those from the performance-optimized number-crunching cores. It's a kind of striatification, offering the hardware to perform the different jobs encountered in the wild.
That should solve the problem for intel, they can blame the programmers if the software doesn't use the hardware properly ;). Allow the programmers to set the flag for 'optimized' (i.e., speculative) execution at their own risk if they want the performance boost. Give it a catchy name to clarify that your hardware offers xy% performance boost for optificated software and watch the programmers scramble to release their new versions.
-
Tuesday 24th July 2018 10:30 GMT Peter Gathercole
RSB
I've only had a short think about this, but it strikes me that the main problem here is that the contents of the Return Stack Buffer persists across context switches.
If whatever OS kernel is being used invalidated the RSB when context switching between different process/threads, then this may affect performance, but should prevent this type of leak between processes. Any performance impact would only be when a process is re-scheduled.
Switching to kernel mode (a system call) would be a bit more problematic, as system calls happen frequently. You would not really want to invalidate the RSB on every syscall, but I would have thought that there should be something that the syscall interface could do to sanitize the RSB it inherits from the process. But the separation of the kernel and process address spaces in the Meltdown fixes should really limit the damage.
As I say, I've not read the full papers yet, so there may be something I haven't considered.
-
Tuesday 24th July 2018 13:42 GMT MacroRodent
Re: RSB
> Switching to kernel mode (a system call) would be a bit more problematic, as system calls happen frequently.
I don't think invalidating at every syscall would be such a big deal. System calls are already very slow compared to normal calls, and subsequently the kernel will internally do a lot of other function calls before returning, so I would estimate the performance hit to be very small, or non-existent.
-
-
Tuesday 24th July 2018 10:50 GMT defiler
STOP THE WORLD!!
Okay - so which muppet is going to suggest that Intel, AMD et al stop manufacturing CPUs until *this* hole is patched too? As I keep saying, this is going to take a long time to fix, and the world can't just stop. We'll just have to muddle along as best we can, uncertain as to who can break our security.
Still, we all use mechanical locks, and they've been proven to be vulnerable time and time again...
-
-
Tuesday 24th July 2018 14:58 GMT defiler
Re: STOP THE WORLD!!
In comparison to what?
In comparison to flailing around wailing "Oh noes! The lock is imperfect - I can't buy a lock until all of the security flaws are fixed! The lock manufacturers are robbing everyone by continuing to make locks with these known vulnerabilities! They need to stop making any locks until they perfect them!" whilst somebody nicks the lawnmower from your unlocked shed...
That's my bugbear with the gnashing of teeth going around here - the idealism in the face of the real world, and the notion that I (as someone who just needs to get a job done) am somehow a lackey to the corrupt semiconductor industry.
Phew - glad to get that off my chest! Also, I didn't downvote you - it was actually a fair question.
-
-
-
Tuesday 24th July 2018 12:10 GMT Giovani Tapini
Asking (possibly) dumb question
Why is normal software even able to access the buffers in question, let alone write to them. I would have thought this would effectively be internal to the CPU or possibly OS kernel level software only.
As a "not an expert in this area" IT person, are there any legitimate use cases for this sort of capability?
-
Tuesday 24th July 2018 14:28 GMT MJB7
Re: Asking (possibly) dumb question
There's no such thing as a stupid question (but failing to ask can be very stupid).
In general, you can't gain access to these buffers directly - but you can do things (like call a function), which will modify the buffers in a predictable way. Furthermore, by carefully timing things(*) you can estimate the contents of the buffer (if it has one value an operation, like return, will be fast; if it has another, it will be slow).
*: You might think that just adding a bit of timing jitter would be enough to fool this. Sadly, it turns out to be easy enough to repeat the exercise and average out the jitter. It turns out that you can do accurate-enough timing from within javascript - you don't need access to the hardware cycle counter
-
Tuesday 24th July 2018 15:57 GMT Peter Gathercole
Re: Asking (possibly) dumb question
In this case, I don't think that it is a timing issue (the timing issue leaks were to decide whether a data cache contained a value, or whether the system had to go an fetch it from main memory).
In this case, what is being done is that a buffer that caches the return address from functions is being controlled, so that when returning from a function or sub-routine, it is possible to change the return address from the next instruction after the call (the normal result) to an arbitrary address controlled by the malicious code.
Normally, the processor would go to the stack frame stored in main memory to fetch the return address (and changing this is the primary technique in a 'stack smashing' attack, as the stack is in the address space of the user process), but it looks like Intel and ARM have found a way of keeping this return address in a faster cache, so that the return can save some clock cycles. If you can arrange to change entries in this buffer cache to point to some malicious code, and get the processor to return to this code while still in kernel mode, in theory you can get access to memory that would normally be protected.
The write up and description of the Return Stack Buffer and this vulnerability is quite involved, and I'm not sure I fully understand it, because in ARM at least, there appears to be two buffers, one of which is a conditional buffer that tracks predictive returns, which can be manipulated using 'branch not taken' types of speculative attack.
As I said earlier, invalidating the RSB (assuming the processor has a suitable instruction) on a syscall or context switch should limit this type of attach to the current process, which is still not that good, but should prevent the leaking of information from other processes or the kernel.
-
-
Tuesday 24th July 2018 15:19 GMT Anonymous Coward
Re: Asking (possibly) dumb question
No. Intel have designed themselves into a corner and now they need to ermm cut corners to remain competitive against AMD, that’s why they are affected so much more than AMD are. The corners they chose to cut this time were around checks before accessing data. There may be others.
-
-
-
Tuesday 24th July 2018 14:40 GMT Anonymous Coward
Re: Inevitable
There have been ways of fuzzy data collection over the air for decades. Radio wave timing and communication timing "hacks" have been known for ages.
The ones that get a lot of flack here are the "read a HDD via temps/power draw" or "guess your password from the heat of the CPU" stories.
While those may use different methods, and power use or heat and not timings as much, they are all statistical analyses when you don't have direct access.
However, IIRC one of the Intel holes was direct access to one of the prediction branches? Hence the even larger flack sent their way.
-
-
Tuesday 24th July 2018 17:27 GMT Cynic_999
How serious is it ... really?
Yes, I've read the descriptions and the theoretical attack vectors of these CPU vulnerabilities. And am left wondering whether anyone would in practise be able to write an exploit that actually achieved anything useful for the exploiter except in a miniscule percentage of occasions.
-
Tuesday 24th July 2018 17:55 GMT Claptrap314
Estimated time to fix: 3 years
Yes, my knowledge here is a bit out of date. However, standard processor release times in during the decade surrounding 2000 were a bit more than 2 years. Less if the design did not represent any great architectural changes, more if it did. (STI Cell did, for instance. IBM G5 did not.) This represents a complete change in focus of the architecture. I would not be surprised if the design work proper has not even started as the big boys are probably petrified about the idea of missing something that their competition does not, and so are red-teaming design concepts like mad. (The hardware-only solution would be to systematically make execution times data independent, but in my experience, they lack the imagination & patience to proceed in that fashion.)
I think it is also going interesting to see what responsibilities are going to fall to the OS. One could, for example, add a "flush everything" command, and require that the OS invoke it on any context switch to untrusted code. This extreme would of course kill performance, but it would allow a single chip design for multi- and single-tenet systems. I mention it to demonstrate that security does not have to be entirely in hardware. For performance reasons, it cannot be. We already have things like separated data and instruction caches & we require the OS to keep them valid.
-
Tuesday 24th July 2018 20:30 GMT Roo
Re: Estimated time to fix: 3 years
I worry that the big boys are overthinking it a bit. All they have to do is put in a "run like a dog" mode that flushes the entire state every context switch and job's a good 'un. The lawyers can sleep at night on their overstuffed mattresses and the punters can carry on sacrificing security & reliability for speed - remember "Parity is for farmers"...
-