Hacker News Reader

HNHacker News

Top New Best Ask Show Jobs

Comment by lawl | Hacker News Reader

Parent Full thread

lawl·

Holy shit. That seems worse than the debian openssl debacle.

If i got that right ALL openssl private keys are now potentially compromised.

I hope vendors push fixes soon, and then I guess I'm busy for a few days regenerating private keys.

View on HN

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.

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