8 ms·
How a researcher hacked his own computer and found 'worst' chip flaw
- neduma 9y agoNSA?
- crb002 9y agoHubris. I've been trying to wrap my head around for over a decade how these side channel attacks between L1 caches and branch prediction caches don't happen. Wish I had published my November 2016 research into function call leaks. CPU registers leaking information between function calls is still a huge unmitigated issue. You want to shit yourself, goose GCC or LLVM to instrument your function calls with a dump of everything in CPU registers before they start. Do this with libraries that people blindly link in dynamically.
- quacj 9y ago> CPU registers leaking information between function calls is still a huge unmitigated issue. How is that a security issue? It's in the same process.
- mikestew 9y agoA process to which one has invited unvetted visitors ("blindly link in dynamically"). I'm not particularly qualified to agree or disagree, but I think that's where parent is going with this. I'm with you, though, in that I can read the registers from a previous function call, but I'm already in the process so do I even need to work that hard? I eagerly await an answer from those better qualified than I. :-) (And maybe you're that person, quacj, dunno.)
- crb002 9y agoStatic linking too. Most of us rely on library code maintained by others we trust. Reads from registers that should be empty isn't flagged by most code auditing software.
- crb002 9y agoSay you have a memory pointer to sensitive info in a CPU register. Could the subroutine troll through memory and find it? Yes, but it would be orders of magnitude harder than having that pointer in a register. Better example is if you are using 64 bit ints in registers as security tokens. Those should be zeroed after use and the compiler needs to not accidentally optimize away zeroing them.
- quacj 9y agoDo you have a proof of concept you can share for this type of attack? I don't quite see how an attacker would take advantage of this is a real-world scenario.
- crb002 9y agoYes, John Deere tractor running Windriver Linux; heavy use of dbus and Qt. Any compromised tractor app vendor could inject it. Could probably reproduce from upstream Yocto distro and the free version of Qt. Much larger attack surfaces to worry about like their craptastic security around USBs that farmers stick in to read maps.
- nly 9y agoIt doesn't matter. If you call a library function you're giving that library license to run arbitrary code in your address space. An RPC is another matter.
- pjc50 9y agoIt's a subroutine. It has access to the entire program. There is no security boundary there. If you link against code, it's inside your security boundary. This is not something that can be secured.
- cryptonector 9y agoThink of system calls too.
- quacj 9y agoAre you referring to callbacks from kernel mode to user mode?
- cryptonector 9y agoIn the world of crypto we've known about cache timing issues forever. Writing cryptographic algorithm implementations so that they are constant-time is really hard, but also always the goal nowadays, as timing side-channels are and long have been a big deal. What's new here is exploitation of speculative execution (branch prediction). It takes what was already difficult in the world of crypto to a new level of difficulty (or maybe not; it looks like the fix for this will be to effectively disable branch prediction in sensitive code, or even preferably by default and enable it only where it's necessary and safe).
- gefh 9y agoI think you need to disable branch prediction on any core that has access to sensitive memory, not just during the execution of sensitive code. It's 'untrusted' code running on the same machine that you need to worry about.
- olfactory 9y agoWhat would be the sales pitch within the NSA to create tooling to allow this sort of stuff to be exploited for useful intelligence purposes? What would the tooling look like, how would it be used, etc?
- cjbenedikt 9y agoOnly one HN comment so far? Embarassing!
- cjbenedikt 9y agoWhy was this down voted? Danjoc said exactly the same: I'm surprised practically nobody cares about this. NPR was running a story about meditation this morning. Here at HN, we're all excited about a new Linux laptop with defective Intel chip included. https://news.ycombinator.com/item?id=16073039 https://news.ycombinator.com/item?id=16073039 I guess this is why Intel can get away with it. Nobody cares.
- swsieber 9y agoBecause that comment was incredibly wrong - look at the front page and see what's plastered all over it: Spectre and Meltdown. HN definitely "cares"
- danjoc 9y agoWhen I said we, I meant it. Even I find myself excited about the new Dell Laptop even though I know it has defective hardware in it, straight out of the box. NPR did run a meditation story this morning too, https://www.npr.org/sections/health-shots/2018/01/04/575167967/meditation-for-fidgety-skeptics-offers-practical-advice-for-stressed-out-cynics https://www.npr.org/sections/health-shots/2018/01/04/5751679... So I'm failing to see how it's wrong. Are you going to put off a purchase because of Meltdown? Are you going to do anything beyond complain for a few threads on HN, apply kenrel patches, and go back to business as usual? Are any of your actions going to cost Intel in any significant way? I did at least disable javascript in my browser. That's probably more than what most have done so far.
- seanalltogether 9y ago> “When I saw my private website addresses from Firefox being dumped by the tool I wrote, I was really shocked,” Gruss told Reuters in an email interview, describing how he had unlocked personal data that should be secured. I wish I knew how to interpret this comment. Did he manage to output his own firefox memory using client side javascript? Or perhaps a local script running in terminal? or is it totally different and hes describing running a process on his own webhost that broke the vm container and printed out other hosted websites ip addresses?
- gefh 9y agoI'm pretty sure he's running an unprivileged binary on his local machine, that shouldn't be able to see Firefox's memory, but can with this attack. I don't know of any js exploit - this attack relies on specific machine code instructions that would be very difficult to get a js engine to generate.
- Klathmon 9y ago>I don't know of any js exploit - this attack relies on specific machine code instructions that would be very difficult to get a js engine to generate. The Spectre paper outlines that this is not only possible to do in javascript, but they included a Proof-of-concept of it working in javascript to read anything from that process's memory.
- GunlogAlm 9y agoTheir proof-of-concept only reads memory from the browser it's running within, right? Violating browser sandboxing, yes, but does that mean it would also (theoretically) be able to access the memory of other programs?
- Klathmon 9y agoAs far as I understand it, the JavaScript PoC only allows you to read memory from the same process. Meaning if all processes are isolated, you can't read anything other than your own tab's memory. However many browsers don't do process isolation, and just about none of them do it completely (Even Chrome won't have mitigations to this that prevent iframes from other origins doing this attack for a week or 2). And while that alone might seem pretty innocuous, think of things that are kept in memory for a specific tab. This could make XSS attacks able to grab HTTP-Only cookies, or be able to read some autofill data or potentially password autofill information. I don't know enough about the architecture of those things to know if they are kept in the same process, but if they are it's possible. That being said, I didn't read any specific reason why that JavaScript PoC couldn't be expanded to work on other processes just like the rest of the Spectre attack. And personally I'm assuming it's only a matter of time before it is figured out.
- binaryapparatus 9y agoThis is so deep and complex that I don't expect to be at ease using computer in the future. There can only be more flaws that easily open this can every time somebody wants to open it. The only half secure way I see is to carefully pick what I install and forget running any JS code in browser, ever. Typing this in w3m/vim btw. Makes sense? FreeBSD I am using just issued news about not being ready yet to fix this vulnerability. Fun. https://www.FreeBSD.org/news/newsflash.html#event20180104:01 https://www.FreeBSD.org/news/newsflash.html#event20180104:01
- cryptonector 9y agohttps://news.ycombinator.com/item?id=16068363 https://news.ycombinator.com/item?id=16068363 > This could be an extinction level event for less popular OSes. Intel, and to a lesser extent AMD, may end up causing enormous damage for which they'll pay nothing much.
- anonacct37 9y agoThis is true, but like other extinction level events it might actually open up the space for some new ideas. Someone on my twitter put it this way: microkernels could see a resurgence if the cost of a context switch into kernel is just as high as the cost of context switching between 2 processes.
- nly 9y agoMicrokernels you say? Yay, more complexity! In all seriousness, the Nintendo Switch users a microkernel and just got completely p3wned. It's extremely fanciful that we know how to build robust modular microkernels when we can't even get the simple stuff right.
- willtim 9y agoI think you have it backwards. Monolithic kernels are by their very nature more complex to reason about due to all the communication backchannels made possible when everything sits in one process.
- tischler 9y agoHow was this bug independently discovered by three research teams (Graz University of Technology, Google's Project Zero, Cyberus Technology)? Was it known beforehand that such an attack or a similar one could be possible in theory such that all teams came up the same idea?
- exhilaration 9y agoThe article suggests that all the research teams were inspired by one source: The team quickly got in touch with Intel and learned that other researchers - inspired in part by Fogh’s blog - had made similar discoveries.
- tischler 9y agoThis is the blog article: https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/ https://cyber.wtf/2017/07/28/negative-result-reading-kernel-...
- Relys 9y agoBackstory: https://twitter.com/tehjh/status/948737135007424512 https://twitter.com/tehjh/status/948737135007424512 Original paper (which I actually read when it first came out earlier this year): http://www.cs.binghamton.edu/~dima/micro16.pdf http://www.cs.binghamton.edu/~dima/micro16.pdf First PoC for leaking ASLR based on timing side-channel attack: https://github.com/felixwilhelm/mario_baslr https://github.com/felixwilhelm/mario_baslr
- danjoc 9y agoI'm surprised practically nobody cares about this. NPR was running a story about meditation this morning. Here at HN, we're all excited about a new Linux laptop with defective Intel chip included. https://news.ycombinator.com/item?id=16073039 https://news.ycombinator.com/item?id=16073039 I guess this is why Intel can get away with it. Nobody cares.
- Pxtl 9y agoOkay, one thing I don't get: Fundamentally, the Meltdown problem comes from a process getting to inspect the wreckage after the the CPU tried to clean up access of protected memory, but failed to properly account for a fun trick of caching. That is, the process tried to read some data from protected memory A and did some fancy stuff with it such that left enough breadcrumbs that after the CPU responds to the illegal read, the process still has enough info to piece together what was in A, at least from timing of reads, right? Why not kill the process instantly on a prohibited read, then? Do these prohibited reads happen too often to switch from "oh, that's okay, you can try again and do other stuff" to "the punishment is death"?
- jchw 9y agoBecause other than the flaw that leaks information, speculative execution of instructions that never retire leave absolutely no trace at all. There's nothing to detect.
- willtim 9y agoNot true. It turns out that Speculative evaluation has side-effects, it changes the contents of the cache. This is the big issue. The contents of the cache are then detectable with timing attacks (the Spectre variants, but perhaps more will be discovered). Meltdown combines this flaw with Intel's own "surprising design" of speculative evaluation, which omits security checks and pulls kernel memory into the cache.
- jchw 9y agoYes that's what I was saying: >other than the flaw that leaks information, But that flaw is pretty hard or impossible to detect.
- conradev 9y agoSpeculative execution executes code that might not actually run. The following example could access protected memory even if `has_privileges` is false (i.e. the processor predicts it might be true): if (has_privileges) { // Access protected memory } else { // Do something else }
- forgot-my-pw 9y ago“Jann Horn developed all of this independently - that’s incredibly impressive,” he said. “We developed very similar attacks, but we were a team of 10 researchers.“ That is very impressive.