5 ms·
NSA?
by neduma 9y ago
NSA?
- 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?