Woo-yay, Meltdown CPU fixes are here. Now, Spectre flaws will haunt tech industry for years Intel has borne the brunt of the damage from the revelation of two novel attack techniques, dubbed Meltdown and Spectre, that affect the majority of modern CPUs in various ways. The chipmaker's stock price is down, and it's being eyed for possible securities litigation, following reports CEO Brian Krzanich sold the bulk of his …
> It's tall, sturdy and everything! It has no holes!" / "True, but I can dig a bit and pass right through under it, isn't it?"
Look, it's not a bug. Our fences are acting exactly as designed. And in any case, we believe that these exploits do not have the potential to corrupt, modify or delete data.
Based on the analysis to date, many types of fences are susceptible to these exploits.
We are committed to product and customer security and are working closely with many other fence manufacturers to develop an industry-wide approach to resolve this issue promptly and constructively. We are making this statement today because of the current inaccurate media reports.
We believe that our fences are the most secure in the world.
... then it sounds like Intel built an adequate fence to stop you coming in my garden, but you invented a way to use a long tool and take a bit of my garden over to your side of the fence where you can do what you want with it.
Times change and things are so complicated these days that it's impossible to account for every eventuality. I'd guess that there are more hackers with evil intentions dotted around the globe than there are hands-on engineers working at all the chip designers combined, so I'd say they have done a pretty good job to date.
There are always going to be times when vulns like this are discovered. It's not so much 'OMG how could they let this happen?' but more about 'How will they stop it once it's out there and handle the cleanup?'
People are saying things like 'They won't survive this' etc. Of course they will. I agree that most large companies are run by execs and lawyers and I'd normally be on the anti-lawyer side of the fence, but this time I think it's fortunate that they have so much behind them. Plus it affects all the major chip manufacturers so they will all rise and fall together, and everything will bounce back just fine.
In a few days it will be patched, lessons learned will go into future CPU design, this will fade into the past and we all move on.
The only things that will annoy me is if any company takes too long to patch it, or uses it as a way to get people to upgrade their hardware.
Intel is in denial. It insisted the vulnerabilities identified do not reflect flaws in its chips.
Having worked with Intel two years ago on one of their new processors, I can tell you that the company is no longer run by engineers, it's run entirely by lawyers. Engineering, public relations, and marketing are all frustrated by the handcuffs Intel's legal department has placed on them.
Thinking back on my experiences, I'm going to guess - and it's a GUESS - that a select few at Intel knew about Meltdown and SPECTRE as far back as 2015, and has been bracing for this inevitable exposure.
I'm a fan - a HUGE fan - of Intel. Despite that, I'm doubtful Intel is going to survive this. My guess is it's going to weaken them so badly that someone is going to buy them out.
I don't know how address spaces inside Intel CPU's are accessed, and I don't know how they are protected from any access. With the benefit of wonderful un-informed ignorance, I am here to help!
(Cue Andy Kaufman's "Here I come to save the daaaay!!" )
So anyway, I remember when, in the 1980's and 1990's certain tricky viruses and worms would use "specific spaces" on a given hard drive, and would take advantage of the then existing technology of "hard-drive-management" which marked certain spots (clusters, specific hard drive memory areas, etc) as bad and unusable if they could not be read after a certain number of unsuccessful read attempts. So, these viruses would install themselves, and then mark the locations where they were hiding out, as "bad and unusable" to the system, while they themselves could still access their nasty programs.
Given this flashback down memory lane, I now am wondering whether the various memory units (clusters, registers, whatever you call it) inside Intel CPU's have a similar method of denying memory
access to the system? That is, an area marked unusable that actually is still good. Effectively invisible, but still accessible to those parts of the system that are informed about the "good bad spots".
That's how i imagine one could fix this problem, together with another system of pseudo-randomly storing the vulnerable data in pseudo-randomly different spots.
Anyone think this is possible, or able to tell why it's impossible?
That is, an area marked unusable that actually is still good. Effectively invisible, but still accessible to those parts of the system that are informed about the "good bad spots".
That's how i imagine one could fix this problem, together with another system of pseudo-randomly storing the vulnerable data in pseudo-randomly different spots.
No, that wouldn't help.
This is really quite complicated, but: The issue with Spectre is that while speculative execution discards incorrect results, it has side effects on system state. When spec-ex loads data from memory into cache, that changes the contents of that cache line and the address it's associated with. An unprivileged process can't read those contents - that's essential to virtual memory in a multiprocessing system with process isolation, like every modern general-purpose OS. But an unprivileged process may be able to figure out something about the address the cache line is associated with.
How? With a cache timing attack, for one. Cache timing is one of many side-channel attacks against CPU microarchitectures. Basically, you try to read a particular address and see how long it takes for the load to complete. If it's fast, then you know that address was already cached.
Cache timing leaks information - it lets the attacker find out something about what addresses have recently been cached. That may not seem relevant, but if you're a security engineer, you know that any information leak has the potential to serve as a side channel that reveals some secret information.
For one Spectre variant, you find a piece of code that does an indirect load based on an address you (the attacker) supply. That is:
1. You run the code, supplying address X.
2. The code loads value V1 from X.
3. The code uses V1 to retrieve some value V2 from another location. There's a set of possible V2 addresses, and they depend on V1.
For example, consider a bytecode interpreter which does something like:
result = Functions[*X](...);
that is, it looks at the byte at X, and uses that to index into an array of function pointers.
Now: The attacker wants to know what byte is at some address A, but doesn't have read permission for that virtual address. So he passes A to that block of code. The CPU speculatively executes up through the point of retrieving the function address from the array slot. Then the attacker users cache timing to figure out which function address was loaded. That tells the attacker the value of the byte at A. (The attacker has previously done some setup work.)
That's greatly oversimplified, but it's the basic idea for that form of Spectre.
So having unreadable memory (which we already have), or moving sensitive data around (which we already do), don't help. It's the speculative load and its effect on the cache which matter.
From the Google project zero blog that triggered all this, is that Specre is mostly mitigated on android devices due to restricted access to high precision timers.
So whilst Pixel devices are fully patched in the Jan 2018 update, and other in-support devices will get these eventually, all other ARM based android devices are still pretty well protected by other means.
Intel based Android devices however may still be subject to meltdown. Anyone know??
This post has been deleted by its author
AMD is exempt from the mandatory address space separation in the Linux tree as of now. Linus merged the patches.
Based on the way the code stands (when code speaks marketing and PR hack should shut the f*** up), AMD is not vulnerable.
Ryzen looked good prior to that anyway. It now does not just look good, it looks stunning. My guess is that AMD is about to get a serious inventory issue with not being able to print enough of them.
Not only no, but hell no. I was at AMD for several years. The bad blood between those two is really, really bad. But the reason no is not hate, it is intellectual property theft. There is no way for AMD to trust Intel not to steal from its designs. (Again, if the first-hand report I got was correct.)
"This time difference is very small, so by keeping the resolution of the timers that are exposed to JavaScript high enough, we mitigate the ability of the attacker to perform this step."
Isn't it the other way around? To mitigate the attack, the timer resolution must be LOW enough.
"No. A high resolution enables you to 'see' more. High resolution=high precision."
Isn't that the point MacroRodent was making? A high precision timer will not mitigate it as JavaScript will have access to high precision/resolution timing. The mitigation would be to only allow it access to low precision timing.
Hum, lower resolution timers will just mean that the attack code will have to make more attempts to determine the difference between the two branches; it won't plug the vulnerability.
Not necessarily; if the resolution is low enough (the grain large enough) then error can dominate to the point where it's infeasible to ever gather sufficient information. It's pretty hard to determine cache timing with 1-second resolution, for example; you'd have to take an enormous number of measurements.
More importantly, they also introduce jitter, so there's additional error.
Even more importantly, though, timing is not the only side channel in CPU microarchitectures. It's just a matter of time until someone has a PoC using some other channel. It may not be pure software (it might use RFI or something, for example), but we've seen those side channels exploited in practice - for example using an innocuous-looking device placed near the target system.
"The mitigation would be to only allow it access to low precision timing."
They should all truncate it to millisecond resolution then. Why does javascript need microsecond-level performance timers?
/me points out that I've profiled code effectively with millisecond-level resolution, MANY times. I'd explain why it works, but would probably get a dozen or so off-topic replies, half of which would contain pejoratives and whining about me using CAPITALIZATION for emphasis. I tried to explain it once on a Microshaft forum when I was profiling early insider versions of Win-10-nic that way, and I don't think they liked what I found, so I got "the flack about my methods" instead of a REAL discussion.
"/me points out that I've profiled code effectively with millisecond-level resolution, MANY times."
Apple's profiler built into Xcode just checks 1000 times per second or so where the program counter is, and that seems good enough to find bottlenecks in your code. You don't need any resolution at all as long as you can manage to sample at 1000 random points in time every second.
@gnasher, 9 times out of 10 I reckon a 1ms sampling profiler points you at the guilty target but it does depend on the problem domain. One good gotcha if you're doing this on Windows is that by default your clock has a resolution of around 10-20ms unless you use the high resolution counters. This caught me out more recently than I care to admit. Each call to my method was in the order of 0.3ms, which almost always appeared as 0ms. Once I had profiled with the high perform counters, it became easy to recognise where the time was being spent, so I could prioritise both speeding up that method and seeing if there were opportunities to call it less frequently.
Microseconds? That is 3 orders of magnitude slower than processor speed, which is clocked in nanoseconds. Millionths, billionths, you know? All of this sounds a lot like spitballing to me. Sure in theory there is a flaw, but practically exploiting it is another matter entirely. How does one know if they've just gotten a password, or random garbage? Without context and structure data is pretty worthless. Meltdown and Spectre strike me more as slow news cycle hype than anything else right now.
Intel knew all about this at the very top (ceo share sales move confirms it). Who doesn't know much, are the Intel PR asses writing the blurbs. This all ties in with the other big scandal below. I bet the NSA had a hand in keeping this hushed up for so long. But then lots of independent civilians started to notice:
===================
'Trusted Computing' Model 2.0'...
"....."The design choice of putting a secretive, unmodifiable management chip in every computer was terrible, and leaving their customers exposed to these risks without an opt-out is an act of extreme irresponsibility," (EFF)..."
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
===================
https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/
This looks really bad for him. Since he obviously knew about this issue several months before he filed to sell the shares, there are only two possibilities:
1) he deliberately sold before he knew the stock would fall, though I'm not sure how he thought he'd get away with it
2) he had some use for that money planned (building a big yacht or mansion or planning a large donation) but if that was the case he should have filed for the sale but held off selling until after the announcement just to remove all suspicion
I'd say odds are better than even he won't be Intel's CEO by this time next year.
What's great about the MotleyFool's write up is that the suspicion was raised at the time of the sale (i.e. not in hindsight based upon what we know now). So the author already suspected that his selling off of 100% of the shares he was allowed to sell off was highly suspicious and indicative that he might know something about the stock price.
It's rare to see an analysis of wrongdoing before the alleged wrongdoing is actually known.
There's a couple of things here...
1) Martha Stewart did time because of her lying to the feds and not being smart about what she did.
If you think she was the only one who does this... hardly. Its hard to get caught.
2) There may be nothing illegal in the share sale. It depends on a couple of factors.
If he is already in a programed sell of shares as a way of portfolio diversification. Meaning he gets a huge stock option grant, he then sets up a pattern of sells to cash out and diversify his portfolio.
There could be an undisclosed life changing event.
The point is that before you get a lynch mob, learn the facts.
(Then heat up the tar.... )
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
