Hacker News Reader

Comment by gzer0 | Hacker News Reader

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.

View on HN

A 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.

This 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!

I think you're mixing things up. The valuable data isn't related to the load time of an application into memory.

The joke was that there would be more memory to sift through.

Good 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 :)

My leg, hand it back, sir. ;-)

You 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.

I 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

See here: https://spacetime.dev/memory-retention-attacks

Thank you for this clarification.

I 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.

This 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.

Yep. 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.

I 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.

Cubes OS care about this problem and have a really great solution. If you’re linux-savvy I would recommend it. There are some friction points but it is 100% usable even as a main work OS (I did this for a while in one of the startups I worked for).

As an example of something you can do trivially in cubes, say someone sends you a PDF that you don’t trust you can just right-click on it, the OS will spin up a temp vm, copy the PDF over and start the PDF viewer in the VM. When you’re done, the VM is nuked and any nefarious b/s the PDF tried to do is gone. Typically these tempvms have networking disabled so there’s no way it can communicate with the mothership either.

I have PDFs set to open with firejail. Adds about a second to launch times, acceptable IMO.

It won't prevent theft of ephemeral SSH session keys, but consider using a HSM or at least a TPM (with Termius, or Secretive) for long-term private key storage. 2FA will situationally help with the other concerns. (You can and probably should use 2FA with SSH as well.)

If someone has the ability to run things on my machine as my user (which presumably would be required to exploit Retbleed), then they can already read the login cookies for all my accounts, as they are stored in plaintext on disk in Firefox's cookies.sqlite file. Password vault is a little more work, since it's encrypted on disk, but presumably they could just read my password manager's memory space during a period when the database is unlocked. Same with SSH keys, though they'd have to poke into ssh-agent's memory.

Javascript/WebAssembly can run things on your machine but can normally not read any files.

Yep. I’d happily ditch all the spectre and meltdown mitigations if they make my machine run faster - so long as my browser is still a secure sandbox against malicious code.

Anything running natively with my user’s permissions already has access to everything of value on my computer.

> 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.

KASLR 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/amdprefetch.pdf

Someday 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.

Our 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.

You 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.

3M 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..

The 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.

No, 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.

Today's Javascript crowd has an even more insatiable appetite for cpu cycles than Microsoft Word did in the early 2000's. A 50x slowdown would do some good, I suppose, but there are also the many software escapes that keep occurring. "Trusted" execution environments have failed repeatedly in the past too. Remember SGX? I don't remember what went wrong with it but it wasn't timing related afair.

Wikipedia shows a spate of speculative execution/timing-based attacks against SGX, as recent as 2020. something like 10 different attacks.

business-wise, I think Intel's decision to gatekeep SGX and require developers to buy licenses to get signing keys probably doomed it, along with how weird and arcane it was to develop for. but the security was not good.

SGX is out there and being used. It's actually the solution to these problems, ultimately, because Intel CPUs are highly patchable via microcode and when you set up an enclave you're effectively opting in to better security for lower performance. For instance, a lot of the early attacks were blocked simply by making the CPU flush its state when entering or exiting an enclave. Intel could do that because an enclave is meant to be hardened, whereas other sorts of mitigations at e.g. syscall boundaries hit tough performance/security tradeoffs that are very different in different contexts.

Also, I'll say, having read a lot of SGX related research papers that many of the attacks were not really practical on close examination, or were immediately patched. The researchers don't tend to mention these things but e.g. using ancient crypto libraries without any side channel mitigations is rather common in that field.

For things like this, it'd probably make sense to use SGX more in the Linux kernel for holding secrets and doing other things. A lot of stuff in the kernel isn't really read sensitive (modulo generic secrets like KASLR slides). Having secrets like root hashes hanging around in kernel memory isn't a good idea but where to put them? One solution is to move stuff into enclaves. Unfortunately it would only help on server platforms.

219bytes 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.

Now 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 :-)

I 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.

High security systems don’t allow even 1 bit per second as it can leak keys.

Are 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/t...

Yes, 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-createpr... (and that blog has many similar fascinating posts)

This 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.

SGX 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'

> 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.

Yeah, 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!

That's like AOL dailup territory right there.

Hell it’s not much slower than the UART comms we’re using in our product at work.

> 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.

Fair! 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).

Good question. I've long since tossed my various modems from the epoch. I started using dial-up systems around 1987 or 1988, working through 300, 1200/75, and 2400bps, etc.

Referring to wikipedia [0] I note v22.bis was released in 1984, and while they're a bit vague, they suggest 2 or 3 bits per signalling change in those 1200bps modems.

I also recall, though perhaps later, vendors were often champing at the bit with 'proposed spec' compliant hardware available prior to the formal specifications dropping, so it was not uncommon to have some of those new speed devices prior earlier (obviously with some risk attached). I think that was more around the 14400bps era though.

Anyway, my extremely solid Telecom 2400bps modem was almost definitely running at 600baud (produced in the late 1980's, though in my possession from very early 1990's).

Depressingly, a lot of ostensibly tech articles (eg [1]) conflate baud with bps, making them poor-use / low-trust historical references.

[0] https://en.wikipedia.org/wiki/Modem#1980s

[1] https://www.techradar.com/au/news/internet/getting-connected...

It’s a fair point but also back in the day - “everybody” (especially the younger BBS and hobbyist crowd) incorrectly referred to them as 1200 baud or 2400 or even 9600 baud modem - as evidenced by the numerous historical references.

Sure, but we're on HN, not at a 1980's breakfast club.

Say 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.

Reply on news.ycombinator.com