29 ms·
Intel SA-00145: Lazy FP State Restore
- 0x0 8y agoStatus in Debian: https://security-tracker.debian.org/tracker/CVE-2018-3665 https://security-tracker.debian.org/tracker/CVE-2018-3665
- cperciva 8y agoI posted some details about this to Twitter: https://twitter.com/cperciva/status/1007010583244230656 https://twitter.com/cperciva/status/1007010583244230656
- jetrink 8y agoHere is the text of the tweets for convenience: So about that "Lazy FPU" vulnerability (CVE-2018-3665)... this probably ought to be a blog post, but the embargo just ended and I think it's important to get some details out quickly. This affects recent Intel CPUs. It might affect non-Intel CPUs but I have no evidence of that. It is an information leak caused by speculative execution, affecting operating systems which use "lazy FPU context switching". The impact of this bug is disclosure of the contents of FPU/MMX/SSE/AVX registers. This is very bad because AES encryption keys almost always end up in SSE registers. You need to be able to execute code on the same CPU as the target process in order to steal cryptographic keys this way. You also need to perform a specific sequence of operations before the CPU pipeline completes, so there's a narrow window for execution. I'm not going to say that it's impossible that this could be executed via a web browser or a similarly "quasi-remote" attack, but it's much harder than Meltdown was. I was not part of the coordinated disclosure process for this vulnerability. I became aware of this issue after attending a session organized by Theo de Raadt at @BSDCan. It took me about 5 hours to write a working exploit based on the details he announced. Theo says that he was not under NDA and was not part of the coordinated disclosure process. I believe him. However, there were details which he knew and attributed to "rumours" which very clearly came from someone who was part of the embargo. My understanding is that the original disclosure date for this was some time in late July or early August. After I wrote an exploit for this, I contacted the embargoed people to say "look, if I can do this in five hours, other people can too; you can't wait that long". While I have exploit code and it is being circulated among some of the relevant security teams, I'm not going to publish it yet; the purpose was to convince the relevant people that they couldn't afford to wait, and that purpose has been achieved. I know from the years that I spent as FreeBSD security officer that it takes some time to get patches out, and my goal is to make the world more secure, not less. But after everybody has had time to push their patches out I'll release the exploit code to help future researchers. I think that's everything I need to say about this vulnerability right now. Happy to answer questions, but I'm not part of the FreeBSD security team and don't have any inside knowledge here -- FreeBSD takes embargoes seriously and they didn't share anything with me. </thread> One more thing, some advisories are going out giving me credit for co-discovering this. I didn't; I just reproduced it and wrote exploit code after all the important details leaked.
- nbsd4life 8y agohow do you feel about how Intel gives every big customer a nice presentation about every vuln ahead of the disclosure?
- andreiw 8y agoWhat are we calling this Spectre variant?
- andreiw 8y agoDo we have PoC code? Has anyone tried attacking FP/SIMD state on other ISAs like Power or AArch64?
- cperciva 8y agoI have exploit code -- took me about 5 hours to write after Theo announced all the important details of the vulnerability. I'm not going to publish it yet, though. AFAIK other systems aren't affected -- is lazy context switching even a thing on them? The fundamental issue here is that one process' data is still in registers when another process is running and we've been relying on getting a trap to tell us when we need to restore the correct FP state.
- monocasa 8y agoLazy context switching is a thing on pretty much every architecture with an FPU.
- cperciva 8y agoHmm, I thought most RISCy CPUs kept FP values in GP registers?
- monocasa 8y agoNo, I can't think of an arch that does that. Power, SH, Mips, Sparc, Alpha, ARM, and RISC-V all have separate architectural register files for the floating point state. Some ARM ABIs end up passing floats in integer registers, but that's just for compatibility for code that doesn't assume the presence of an FPU and might be doing everything soft float.
- cperciva 8y agoHmm, ok. It's a long time since I've looked at that. Come to think of it, I think it might be 20 years since I opened CA:QA...
- sctb 8y agoWe'll let this thread take the frontpage spot now that the announcement is official. Previous one: https://news.ycombinator.com/item?id=17304233 https://news.ycombinator.com/item?id=17304233.
- kentonv 8y agoAndy Lutomirski noted on another thread that he unintentionally fixed this two years ago in Linux: https://news.ycombinator.com/item?id=17304947 https://news.ycombinator.com/item?id=17304947 (He switched it to eager FP because it's faster on modern hardware.) But a lot of people running old LTS kernels may be affected. EDIT: Looks like Luto's change landed in kernel version 4.6. https://kernelnewbies.org/Linux_4.6#List_of_merges https://kernelnewbies.org/Linux_4.6#List_of_merges https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecc026bff6e8444c6b50dcde192e7acdaf42bf82 https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
- techntoke 8y agoDoes that include Red Hat Enterprise Linux? I can't believe how old of a kernel they use still. I have to use it for work, but I run Arch at home which is running 4.16.13. I'm honestly surprised that Red Hat can't manage to keep their distros current with stable package builds.
- snuxoll 8y agoRed Hat backports security fixes, hardware support and certain new features to their kernel packages, staying on a stable kernel version throughout the product lifecycle is what allows them to guarantee a consistent kernel ABI that virtually every other distribution throws to the wayside. Personally I prefer not having third-party kernel modules on my servers break every time I run `yum upgrade` like I do with Fedora (oh VMWare, how I hate you so).
- readams 8y agoexcept they still break because Red Hat backports bleeding-edge features but doesn't change the version number.
- vbezhenar 8y agoI'm using HP B120i fakeraid controller with proprietary driver and it broke after 7.4 upgrade, so while they probably doing a good job about binary compatibility (7.5 didn't broke it), it's not ideal.
- cmsimike 8y agoSerious question - should we considering speculative cpu execution to be A Bad Idea (tm) and move on from it (since these problems keep coming up), or is the thought that we more or less have been gaining performance on the back on incorrectly written software (which does not take these speculative execution edge cases into account), and the only forward is patching? I guess a another question I have is can we win the performance back through fixes on the cpu or will speculative execution always be insecure and thus need patching in software? Try as I might, I am not a CPU person.
- shawnz 8y agoPersonally I wonder if it will ever be possible to have a platform totally free of side-channel attacks, whether or not it uses speculative execution.
- evancox100 8y agoNo, probably not, but as with all security, electronic and otherwise, the goal is to make breaking the security cost more than whatever it's protecting is worth (for some arbitrary definitions of "cost" and "worth").
- Tuna-Fish 8y agoCompletely dropping all forms of speculative execution means dropping overall performance to a tenth of today. There are really hard limits on how fast any operation, especially memory operations, can be done. The way we have made our CPUs faster is by making them do more operations in parallel, at all levels. At the lowest level, in straight line code, this very often requires speculation to achieve. Speculation is not fundamentally incompatible with security. It's just that literally everyone in the industry never though that leaking information out of speculative context was possible -- and so there is no hardening anywhere. Now that it was proven possible, people are rushing to find all the ways this can be exploited. New CPUs currently being designed will fix all these, and then eventually we will have speculation without security issues. Except for Spectre variant 1. That will always stay with us, because there is no sensible fix for it. The only real solution to that is to accept that branches cannot be used as a security boundary. This is mostly relevant to people implementing secure sandboxes and language runtimes. Going forward, the only reasonable assumption is that if you let a third party run their code in a process, no matter how you verify accesses or otherwise try to contain that code, you should assume it has a read access to the entire process. Any real security requires you to make use of the proper OS-provided isolation.
- kanox 8y agoWhat is the impact of this exactly? If "FP State" just means floating point register values then those rarely contain interesting stuff. If this also affects register used for crypto acceleration then it could be used for stuff like leaking browser secrets from javascript, right?
- cperciva 8y ago"FP State" in this case includes MMX and SSE registers; they're handled via the same "lazy context switching" mechanism. Yes, you can steal keys which are being used for AESNI. Leaking secrets via javascript -- I'll be impressed if someone pulls that off. There's a very tight timing window to exploit this before a trap fires and flushes your pipeline, and I doubt you can get the right instructions in there using javascript.
- caf 8y agoCan't you executive the trapping access in a not-taken speculatively-executed branch à la Meltdown?
- cperciva 8y agoSure, but that gives you an even shorter window because the pipeline flushes as soon as the CPU realizes that it mis-speculated.
- caf 8y agoIt is my understanding that you can make that window very long by having the mis-speculated branch depend on a value that has to be loaded from main memory.
- cperciva 8y agoHmm, good point. Yes, that would probably make this much easier to exploit. Unless the CPU does a partial pipeline flush upon realizing that there would be a trap. I don't know -- do Intel CPUs check for exceptions in order?
- jibanes 8y agoIs it fixable by microcode update?
- cperciva 8y agoVery unlikely. The key issue here is that traps aren't handled until a long way down the pipeline. But it's a (relatively) simple OS fix.