Slashdot videos: Now with more Slashdot!

View

Discuss

Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

Any data kept in RAM on an open-ssl box has probably been compromised. It sounds like that includes private keys, root certs, passwords, etc.

This is why passwords etc should be encrypted in RAM. It's funny, there's a Security Technical Implementation Guides (STIG) on that very item. It always sounded sort of ridiculous, but now I know why it was there.

No, you got it quite right. A server could grab browsing history, JS memory contents, stored passwords, and authentication cookies from a browser. It's not just web browsers, though; a malicious server could also steal email (from other email accounts) out of a mail client, and so on. For the handful of services that use client certificates, a server could steal the *client's* secret key.

Browsers (or other clients) that use multiple processes have some degree of safety, as this exploit can't read across process boundaries. It's also completely passive; just because every Chrome tab *can* get the cookies that are currently being used in every other Chrome tab doesn't mean that they are always loaded in each tab's process' address space (though I don't know if they are in practice or not).

Still, this is a grade-A clusterfuck security-wise. The ability for an unauthenticated attacker (all you need is an open TLS connection; that could be the login screen) to read memory off the other side of the connection is the kind of exploit you can make movie-grade "hacker" scenes out of. For a simple example you might see somebody pulling, you could use this exploit to decrypt any connection you recorded, assuming the server hadn't rotated its private key since then. If you can be fast enough and are in an intercept (MitM) position rather than just monitoring passively, you could even grab the keys in real-time and have complete control, invisibly, over the connection. From there, you could even read memory from the client and (continue reading from) the server at the same time!

You could probably do it automatically using a Raspberry Pi hiding behind the flowerpot in a café. I'm not joking.

I've been in the security world for years and I don't think I've ever seen so bad a vuln. Yes, things like "goto fail" were mind-blowingly stupid, but they still only let you MitM connections if you were in the right place at the right time. This one is strictly better and enables a huge number of alternative attacks.

Don't just encrypt them - move them out of process entirely. Have a security broker that knows your secrets, but doesn't talk to *anything* except local clients (on the assumption that if the attacker has arbitrary code execution, it's game over anyhow). Use inter-process communication to get secrets when needed, but preferably don't *ever* hold sensitive data in memory (for example, instead of using your private key directly, you ask he broker process to sign a binary blob for you, and it does so using your key and returns just the signature). Use "secure buffers" in managed code, or "secure zero" functions otherwise, to eliminate any sensitive data from memory as quickly as possible.

Yes, this used to sound paranoid. Actually, it still does sound paranoid. But, there's now a great example of a scenario where this is a Good Idea.

Of course, you have to make sure that broker is Really Damn Secure. Keep its attack surface minimal, make sure the mechanism by which it identifies whose key to use is extremely robust, and if possible make it a trusted part of the OS that is as secure from tampering as possible (Microsoft already has something like this built into Windows). There's also a question of how far to take it. For example, you could have the broker handle the symmetric encryption and decryption of TLS data (the bulk data part, after handshaking is completed) but that could impact performance a lot. Keeping the symmetric key in memory isn't so bad, really; it's ephemeral. However, if an attacker has a vuln like this and wants to read the traffic of a target user, they could attack the server while the user is using it, extract the symmetric key, and use it to decrypt the captured TLS stream. Keeping the key in-memory only while actually losing and (securely) purging it between response and the next request might be a good middle ground, perhaps?

After so many years of this shit, it has to be intentional, just so people will post corrections.

Of course it is intentional, and yet no naming and shaming appears to be going on... why is that? Only a small handful of people are responsible for bringing this to our linux distros, and a few more responsible for keeping it there. Those people have lost the trust of the community and should never have any of their code submissions or bug priority lists accepted ever again, otherwise there is just no consequence for nefariously subverting the security of us all.