4 ms·

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

• sp332 13y ago
  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.
  • e12e 13y ago
    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?
    • cjg_ 13y ago
      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).
    • rmc 13y ago
      It might be able to read the memory of the ssl server that's making the response. Including maybe the ssl private key
      • e12e 13y ago
        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).
  • zurn 13y ago
    Unless you used forward secrecy, which you should anyway in case of a key compromise. Key compromises can happen in many ways.