Hacker News Reader

Oh it's even worse, basically every secret you had in your server processes' RAM was potentially read in real-time by an attacker for the last 2 years.

View on HN

Isn't there any memory protection on Linux? Something running as www-data shouldn't be able to read the ssh-server's RAM?

So it's bad, but it's not that bad unless something exposing this bug (webserver with ssl, vpn, or other service) runs as root?

It can only access memory of the process running openssl. So if you got nginx in front of your webprocesses they are protected. However anything in the nginx process is accessible (e.g certificates).

It might be able to read the memory of the ssl server that's making the response. Including maybe the ssl private key

Yes, to be clear (esp. for others reading this thread) this is really bad, but shouldn't be able to compromise your ssh server keys.

However -- ssl certs and session keys are a likely target, and combined with passively logging traffic that is enough to compromise all data going over ssl, such as login/passwords and data.

Problem servers include not only web servers, but also imap/pop and smtp servers supporting tls (via openssl -- afaik gnutls isn't vulnerable to this bug).

Unless you used forward secrecy, which you should anyway in case of a key compromise. Key compromises can happen in many ways.

Reply on news.ycombinator.com