7 ms·
CPU hardware vulnerable to side-channel attacks
- gaius 9y agoIn the old days this would be no biggie as every non-trivial site would have at least half a dozen different kinds of Unix workstations anyway. SPARC, MIPS, PA-RISC, AXP, m68k, POWER...
- mtanski 9y agoIn the good old days everybody just used HTTP, FTP and telnet and NIS. Old archs also has other bugs we forgot about / never discovered.
- gaius 9y agoThe point being: monocultures are fragile.
- acdha 9y agoYou think it'd be less work having to coordinate with even more vendors than listed in the advisory?
- kardos 9y agoOn one hand, great news for Intel: everyone needs a new chip. On the other, terrible news for Intel: AMD's offerings are pretty competitive these days. It'll be interesting to see how this plays out.
- sebazzz 9y agoCan't it be fixed with a microcode update?
- jvreeland 9y agonope.
- noja 9y agoWhy not? What can?
- deleted 9y ago[deleted]
- xemdetia 9y agoIt's very likely that because this is a performance driven optimization that exposes the security hole it is at a layer beneath the microcode from how the instruction pipeline/branch prediction was working to begin with. The wiki page for Instruction Pipelining is pretty good https://en.wikipedia.org/wiki/Instruction_pipelining https://en.wikipedia.org/wiki/Instruction_pipelining. There was already problems in multicore systems for false sharing/other cache issues. As far as my understanding goes microcode is only useful for the logical wiring of the various subsystems of the CPU together to perform the requested operation, but it is not generally 'inside' the actual operations (ex: at a certain point shift left one bit turns into currents through gates, and there's no microcode at that level). If you bring it to a higher level of abstraction on a particular motherboard you might be able to flash the firmware of the BIOS, and the memory controller has a known issue you may be able to use the BIOS to access it differently but for a certain class of issues if you can't change how you signal the memory controller to work around it and the memory controller is not a replaceable part you might be screwed and need a new motherboard that just doesn't have the issue which seems to be closer to what we have here.
- y0ghur7_xxx 9y agoso i bought my cpu a few months ago. will intel replace it for free?
- nikanj 9y agoAfter 15 years of class action appeals, you’ll get a voucher for $15 off of a retail-packaged processor.
- petee 9y agoDoubtful - Intel's press release is carefully worded to suggest that the chip is working as designed, and that others are to blame if exploited. I'm sure they see the lawsuits on the horizon
- manyoso 9y agoIt's those nasty hackers and awful security researchers who are to blame...
- ballenf 9y agoThe wording "working as designed" makes about as much sense here as a lock maker claiming a lock was designed to be easily pickable. Intel's outside lawyers are going to have a great 2018. And '19 and '20. And AMDs. The plaintiff's lawyers too. Don't forget expert witnesses. Damn, for anyone with technical expertise in the area now's the time to polish up the resume and start shopping it to the large firms on both sides.
- ashark 9y agoI can't figure out whether this means that OS-level mitigation of the problem doesn't prevent all avenues for exploitation. The headline implies it (and probably made it to the front page based on that implication) but TFA doesn't make it clear whether that's true.
- contrarian_ 9y agoAny branch on attacker-controlled data can be speculatively bypassed. You would have to at the very least recompile all applications to attempt to mitigate the two Spectre variants discussed so far. Unless there is some way to turn off speculation entirely, but that would hurt performance badly.
- orblivion 9y agoSo why are the OSes bothering to patch anything?
- contrarian_ 9y agoThere are (at least) two separate things going on. Meltdown, the flaw exclusive to Intel and some ARM CPUs, is very easy to exploit and is the one being patched by OS vendors. Spectre is a whole other can of worms, on the one hand it's more tricky to exploit, on the other hand there might not be an easy fix and people are speculating (no pun intended) that it will have to be dealt with in hardware.
- pfooti 9y agothe pun is apparently at least part of where the name come from, as it exploits speculative computation
- justrobert 9y agoSpectre works in javascript due to how aggressive the JIT is. Chrome and Firefox are already working on solutions as you cannot exploit the JIT if it generates code that ruins your timing as far as I'm aware. So that solves the problem for most people, but all other environments that allow execution of untrusted code also need to be updated.
- userbinator 9y agoSide-channel attacks are notoriously difficult to prevent: https://en.wikipedia.org/wiki/Tempest_(codename) https://en.wikipedia.org/wiki/Tempest_(codename) I suspect these sorts of attacks will exist as long as people try to share running untrusted code on the same hardware.
- bno1 9y agoI think that it's been proven that any computational system with shared resources is susceptible to side channel attacks. The only generic way to solve them is to share each resource equally across all its consumers (e.g. each thread gets 1/num_of_threads cpu time).
- Klathmon 9y agoIt's not just untrusted code, it's all code. "Trusted code" is one exploit away from being untrusted code. And solving that requires not accepting untrusted input, which makes most general purpose computing useless. Has there been any research into solving this problem at the hardware level? I'm imagining something like having hundreds or thousands of distinct processors on a PC all isolated each running only one process. It sounds extreme, but over time I've basically learned to treat "optimization" as a synonym for "introduces side channel attacks", and without something that can protect against a large majority of these kinds of exploits, computers are only going to get less secure.
- TrevorJ 9y agoEven with distinct processors, there would still be something in charge of who gets to use what hardware resource. I suspect that would be where the attack vector would shift.
- Klathmon 9y agoAt least some of those resources can only deal with encrypted data to reduce the amount of leakage to acceptable levels. Or maybe we can contain the problem by having a kernel that manages access to all resources, but keeps individual processes on nearly separate hardware. As you can probably tell, I have no idea what I'm talking about here, but the more of these big side channel attacks that come out, the more I'm feeling that there is no way to securely share a machine among multiple processes without just giving up and letting them all have access to one another.
- noja 9y agothis is our golden opportunity to switch to something less privacy evading and bug-ridden. (and it will incidentally also prove that the market really doesn't work very well, because most people will still buy intel)
- krylon 9y agoThe problem is that there are not many alternatives. AMD claims their current CPUs are not affected, but they still have the PSP, AMD's equivalent to Intel's ME. I suppose it has not been probed as thoroughly as ME because of Intel's bigger market share. ARM CPUs are - according to Intel - also vulnerable, which disqualifies almost all other competitors. I had hoped that the Longsoon chips would amount to something; I vaguely remember Richard Stallman used a notebook with Longsoon processor, but none of the vendors I checked at the time had even heard of it. And if you are paranoid enough, a Longsoon-based system might just replace the NSA with their chinese equivalent. The only viable alternative from a technology point of view that I am aware of is the Talos Raptor workstation. Unfortunately, it is rather expensive. Okay, for a high-end workstation, the price is not unusual. But compared to the price of a regular office PC, it is very expensive.
- reirob 9y agoI'm also looking at Raptor Hardware and I would love to hear the experience from somebody that uses it. As well, I am not sure that POWER9 is immune to these attacks. And then, well, you still cannot buy their products, as far as I understand it from their page [1]. Does anybody know more about the Raptor systems? [1]: https://raptorcs.com/ https://raptorcs.com/
- reacweb 9y agoMaybe the CPU is the wrong place to perform sophisticated optimizations. IMHO, the CPU should be far more simple and the intelligence should be in the compiler.
- chrisseaton 9y agoThis has been tried several times and it just doesn't look like it works in practice. Delay slots, Itanium, etc. The CPU is a bit like a JIT in that it can see how the program is really running and optimise for those conditions, which the AOT compiler cannot. Your AOT compiler may not know you're going to take a branch more times than not, but your CPU may be able to work that out at runtime. And then tomorrow you may never take the same branch and it'll work that out as well for the same code.
- std_throwaway 9y agoThe compiler only knows about the program and maybe statistical information about the data. The CPU knows about the actual data currently being processed. Therefore, the CPU can do more by using branch prediction and speculative execution. It is more expensive in terms of energy per computation but so far it was worth it. The CPU can also optimize old code on-the-fly.
- hinkley 9y agoItanium tried this and Intel got burnt by the experience. Not saying you’re wrong, just saying Intel won’t believe you for a while yet.
- contrarian_ 9y agoDid Itanium really fail because of the technology or because of x86's momentum and lock-in effects? AFAIK Itanium has explicit software control of speculative loads.
- chrisseaton 9y agoOther 'the compiler will sort it out' approaches have also failed though, so it seems likely.
- m3kw9 9y agoAnyone know the implications to the security of the crypto currencies? Are they highly prone to theft now?
- aviv 9y agoMy guess is at least one exchanger will run away with coins and blame it on the CPU vulnerability being exploited.
- teraflop 9y agoI can't think of any cryptocurrency-specific attack vectors off the top of my head. But if malicious Javascript code can use Spectre to escape the browser sandbox, then wallet private keys are potentially vulnerable, just like everything else on the machine.
- sova 9y agoIf your crypto coin lives on a box connected to the internet you're living dangerously. That said, I live dangerously too.
- brndnmtthws 9y agoNot if you use a hardware wallet (Ledger or TREZOR). If you're using a web (Coinbase) or desktop wallet, you might be at risk. In reality, it's pretty unlikely to be exploited. Someone could steal your login credentials for any web service, but the risk is mitigated if you use 2FA, or some sort of IP whitelisting.
- anonemouse145 9y agoWhat happens when you use that wallet by plugging it into the computer, or by entering its information on a computer to perform a transaction? People say "Hardware wallet" like it's a magic incantation.
- brndnmtthws 9y agoIf you use a hardware wallet, the private keys only exist on the device, and therefore cannot be stolen using this attack vector. The Ledger uses a secure element, which is an entirely separate MCU, and (as far as we know) can't be 'hacked' by any script kiddies. However, if you for some reason decided to store the wallet seed on your computer, it's no longer secure.
- jstewartmobile 9y agoI wish desktop chips would trade a little performance for more simplicity and robustness. Even at half-speed, they are still pretty damn fast, and a lot of the bleeding-edge stuff was pushed over to the GPU a long time ago. The economics are also a little off. If this were something like ARM64, the eventual replacement chip would be a few bucks instead of a few hundred. In that situation, I wouldn't get too upset about it. It would be like, "Oh well, I guess I have an excuse to upgrade my CPU now."
- interfixus 9y agoHear! In them olden days of yore, writing x86 assembly, I had a decent mental model of what my code was doing when. I no longer do.
- jstewartmobile 9y ago"These days I spend more time optimizing code for ARM chips than for Intel chips. The real reason for this isn't any sort of assessment of current or future importance. The real reason is that ARM publishes the detailed pipeline documentation that I need, so squeezing out every last cycle for ARM is fun, while Intel hides the pipeline documentation, so squeezing out every last cycle for Intel is painful." https://blog.cr.yp.to/20140517-insns.html https://blog.cr.yp.to/20140517-insns.html
- darkmx0z 9y agodisable high resolution clocks for non-sudo programs?