14 ms·
In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending. > Linu
by gzer0 4y ago
In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending.
> Linux creator Linus Torvalds famously rejected such warnings, arguing that such exploits weren’t practical.
And I would certainly agree with Linus, here's why:
> Retbleed can leak kernel memory from Intel CPUs at about 219 bytes per second and with 98 percent accuracy.
Retbleed adds more credence to this idea of impractical-yet-technically-feasible exploits; where do you draw the line? Do you choose to be vulnerable to this 219 bytes per second leak at the cost of 28% CPU overhead? I would imagine, one could toggle on or off the mitigations they'd want with the implications provided in the future via modifying BIOS settings.
- nneonneo 4y agoA Bitcoin private key is 32 bytes long. /etc/shadow on my machine is 1080 bytes long. Heck, my entire password manager database is probably no more than a few KB in size. Sure, chasing the necessary pointers and data structures through the kernel or other user programs might add some overhead, but don't write off a 200b/s leak as harmless. It may well be enough to steal the secrets you care about the most.
- deleted 4y ago[deleted]
- deleted 4y ago[deleted]
- shepherdjerred 4y agoThis is a great case for developers using Electron. Nobody is every going to get anything meaningful from those apps at 219b/s -- there's far too much memory to read!
- keyle 4y agoI think you're mixing things up. The valuable data isn't related to the load time of an application into memory.
- RandomThrow321 4y agoThe joke was that there would be more memory to sift through.
- Blahah 4y ago
- na85 4y agoHey as long as we all agree Electron sucks, amirite
- IntelMiner 4y agoHow dare people make jokes I don't personally find funny!
- coconut08 4y agoYou need to mellow out.
- labster 4y agoIf you want to substantiate the jab, just go run literally any Electron app.
- kelnos 4y agoI didn't find the joke particularly funny, but how is it unsubstantiated that Electron apps use a lot of memory? That seems to be a pretty easy thing to check, and see that a fairly simple Electron app... uses a lot of memory.
- weberer 4y agoIt's a joke whether you found it funny or not. Using scare quotes like that doesn't mean anything.
- mcronce 4y agoGood point. I'm going to start allocating tens of megabytes of random data all over my address space at the beginning of execution so that I too can gain this advantage :)
- B1FF_PSUVM 4y agoMy leg, hand it back, sir. ;-)
- caeril 4y agoYou joke, but allocating and writing random data all over the heap and hiding and constantly moving key material through it is the idea behind Schneier's Boojum.
- bredren 4y agoI searched for this term, "Schneier's Boojum" and the results suggest clearly this is Bruce Schneier you're referring to. But I'm not seeing this Boojum as a concept explained in quick results, actually, one of your prior comments mentioning it is top result. [1] Would you please explain what you mean by Boojum / link to what you're referring to? [1] https://news.ycombinator.com/item?id=27941909 https://news.ycombinator.com/item?id=27941909
- josephg 4y agoI don’t care about my /etc/shadow since my machine isn’t network accessible. I’m much more worried about: - The login cookies I have for my email account, my bank or my GitHub account - My password vault - My ssh private keys - which could be used to mess with production systems or make changes to repositories on GitHub without my knowledge All of this data is extremely small (handfuls of bytes) and could cause lots of harm. Giving malicious javascript the power to exfiltrate any of these secrets would be a disaster.
- seanhunter 4y agoThis is a very interesting insight. The vast majority of traditional unix security mitigations are about securing a multi-user system from malicious users. However a lot of the most frightening threat models now are about using data from a single-user system to hijack session tokens or other secrets and thereby compromise external systems that it has some sort of trust relationship with. That's why you see spearphishing attacks that compromise the clipboard - they are hoping that a useful secret gets copied from a password manager or similar. You don't need to elevate priviledge on the local machine if all the secrets are owned by the user you have compromised, and all these secrets are very small numbers of bytes because they are designed to go into a challenge response type flow.
- josephg 4y agoYep. The Unix security model feels out of date these days. Who cares about privilege escalation attacks when all my most sensitive data (ssh keys, browser cookies and saved passwords, code repositories, etc) is already readable by every program I run in my user account? Desktop computing needs application sandboxing like phones have. I find it remarkable that nobody in the opensource world seems to care about this problem.
- EricE 4y agoI think people care, just not enough to deal with the huge PITA that sandboxing turns out to be. It takes a significant amount of discipline - and meticulous detail - to start going down the sandboxing path. In other words, it's tedious and not fun at all.
- titzer 4y agoNow it's all a matter of bandwidth and reliability. The world of digital computers is overlaid with an analog world of side-channels that are measured in frequency and signal-to-noise ratio. I worked on Spectre for a couple years when on V8 and read a couple books on information theory, signals, and probability. Computer science is catching up to EE little by little :-)
- danachow 4y ago> 219 bytes per second and with 98 percent accuracy. Perhaps I'm a boomer, but 219 Bps is damn fucking fast - faster then the first few modems I used. > where do you draw the line? Probably somewhere fucking much further below any point where human communication was deemed practical in the past 150 years. Somewhat pathetic to me that people can't imagine 200 Bps as a usable bandwidth.
- nneonneo 4y agoYeah, it's between 1200 baud and 2400 baud - which would be right around where dialup was in the 80s. Plus the attack runs at 3.9KB/s on AMD processors - over 10 times faster!
- cptskippy 4y agoThat's like AOL dailup territory right there.
- girvo 4y agoHell it’s not much slower than the UART comms we’re using in our product at work.
- Jedd 4y ago> Yeah, it's between 1200 baud and 2400 baud - which would be right around where dialup was in the 80s. Eh? 219 Bps ~= 2100 bps (effective) Assuming QAM that'd be something under 600 baud. Baud and bps are not the same thing.
- nneonneo 4y agoFair! Thanks for the correction. I intended to say bits per second. Luckily I think I’m still in the right ballpark for speeds (at least in the early 80s). Did any of those old modems use QAM? It seems like many of the older protocols were FSK/PSK-based (yes, special cases of QAM, but not decoded the same way).
- 4y ago
- ec109685 4y agoAre you saying windows runs 28% slower than Linux systems? “Intel has worked with the Linux community and VMM vendors to provide customers with software mitigation guidance which should be available on or around today's public disclosure date,” Intel wrote in a blog post. “Note that Windows systems are not affected given that these systems use Indirect Branch Restricted Speculation (IBRS) by default which is also the mitigation being made available to Linux users. Intel is not aware of this issue being exploited outside of a controlled lab environment.” There’s also other mitigations that don’t have that penalty that are working on employing: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/advisory-guidance/return-stack-buffer-underflow.html https://www.intel.com/content/www/us/en/developer/articles/t...
- ploxiln 4y agoYes, context switching specifically. It's well known that if spawning thousands of child processes, or if walking a directory of 100k small files to get metadata, linux can be much faster than windows. You might consider these just bad program design - on windows you'd strongly prefer to use many threads, and pack files of some kind (zip, cab, etc). There ends up being lots of different reasons why this kind of stuff can be rather slow on windows (but if you deal with fewer processes and fewer files you won't notice, it'll be fine). Some fascinating details: https://randomascii.wordpress.com/2019/04/21/on2-in-createprocess/ https://randomascii.wordpress.com/2019/04/21/on2-in-createpr... (and that blog has many similar fascinating posts)
- SnowHill9902 4y agoHigh security systems don’t allow even 1 bit per second as it can leak keys.
- WhitneyLand 4y agoSay what?! Didn’t they say they were able to find the root pwd hash in less than 30min? It looks like downplaying the potential of ret attacks was at best overly optimistic.
- AlexCoventry 4y agoThis is probably another spike through the heart for SGX, at any rate. If you could use this to leak the attestation keys, SGX is useless for secure execution of code on a hostile system.
- CircleSpokes 4y agoSGX is already dead on consumer chips, but I don't think this has any impact on SGX. SGX keys aren't stored in kernel memory so being able to leak data from kernel memory isn't going to leak the keys. Of course there are other attacks that can get SGX keys or 'protected data'
- throwaway81523 4y agoSomeday we will learn that allowing adversaries to run code on our computers will always create leaks. In the old days whenever a new exploit was discovered, advisories would go out telling people to disable Javascript in their browsers. Now JS can no longer be disabled, and way too many sites rely on it unnecessarily, so we are stuck. Oops.
- akira2501 4y agoOur business has windows. Someone drove up, kicked in a window, stole some things and left. I keep trying to tell people to tear all their windows out, but I guess people think they add value to their home and so now we're stuck. Oops. What we actually did was add "glass break sensors" to our security system.
- KennyBlanken 4y agoYou can also install glass that is 'vandal proof', with a plastic layer. It'll slow down whoever is trying to smash it enough until the police show up.
- retcon 4y ago3M sell a range of security film for after market application. Also IR/UV blocking films. Former external latter internal. Worth looking at the energy savings because which can be significant depending on your local climate. Variants provide internal reflection suppression and tints which might make it attractive to executive pursors. The (public SKU) electrically conductive window film was discontinued unfortunately..
- lazide 4y agoThe difference now is we made it easier for people to break everyone’s windows at scale and take what they want from another country with unfriendly extradition rules. Oops.
- snovv_crash 4y agoNo, we just need deterministic processing capabilities for untrusted code. So, no caches, no speculation, guaranteed cycles and memory bandwidth. It will be dog slow, but it can't leak the behaviour of other components on the system.
- woodruffw 4y ago> In today's arms race of exploits, you need to operate and prepare your interactions with computers with a defined threat scenario. This is never-ending. There are very, very few threat models in which a 219 bytes/sec kernel memory disclosure is not catastrophic. Even in an ideal world where disclosing kernel memory wouldn't help an attacker bypass KASLR, it's catastrophic for any key material that happens to be in kernel memory.
- paulmd 4y agoKASLR is already broken on AMD systems. #1 is unpatched (AMD says "it doesn't directly leak memory", only the page table mappings, ie breaks KASLR) and #2 the PREFETCH+TLB-Evict combo is still unpatched unless you use non-default hardened configs (only mitigated by enabling KPTI which AMD recommends be disabled by default). #2 also allows a Meltdown-style attack which exfils data directly but hey, also breaks KASLR too. https://mlq.me/download/takeaway.pdf https://mlq.me/download/takeaway.pdf https://mlq.me/download/amdprefetch.pdf https://mlq.me/download/amdprefetch.pdf
- staticassertion 4y ago219bytes per second is extremely practical, not sure why you think it isn't. Like, that is plenty. Linus's statement was sheer ignorance, as usual.
- d--b 4y agoI would add that if you’re in a position to actually exploit this (having a process running on the target computer and an access to exfiltrate the data), there is a good chance that you have access to simpler vulnerabilities than raw memory leaks from the cpu.
- deleted 4y ago[deleted]