Hacker News Reader

Comment by nneonneo | Hacker News Reader

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.

View on HN

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!

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

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.

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

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com