-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
Heartbleed only potentially exposed data the memory space of the TLS-running process. So if the private ssh host keys were available in the memory space of the webserver (or other TLS-using process), then something is terribly and horribly wrong with the way the server is set up. If, however, heartbleed was used to gain knowledge used to escalate to high (root) privilege, then you have to consider the entire machine exposed and nuke it/restore from backup before the breach. But that's a significant undertaking, and would only be indicated if there were some reasonable evidence that the machine had indeed been compromised. I cannot see how a machine, which is only known to have been vulnerable to heartbleed for some period of time, needs any private data replaced other than that which the vulnerable process had access to or could reasonably have had in memory. I am, however, happy to be enlightened (and probably saddened at the same time) On Tue, 13 May 2014 16:21:15 -0400 David Nolan <[email protected]> wrote: > While SSH is not affected directly by the heartbleed bug, if you have a > server that was affected by the heartbleed bug there is some risk that the > SSH private key may have been exposed. I would consider any private data > (ssh keys, database passwords, cloud API credentials, etc) on a machine > that was vulnerable to heartbleed as potentially exposed. If you're > replacing the SSL certificate on a machine you should probably replace all > those other things as well. > > -David > > > > On Tue, May 13, 2014 at 4:06 PM, Robert Hajime Lanning > <[email protected]>wrote: > > > SSH is not affected by the Heartbleed bug. > > > > Heartblead is a vulnerability in the implementation of SSL/TLS protocol, > > not the actual encryption. > > > > SSH is it's own protocol. The only OpenSSL calls are for libcrypt.so, not > > libssl.so. > > > > There is no such thing as an SSL Heartbeat in SSH. > > > > > > On 05/13/14 12:57, Mathew Snyder wrote: > > > >> SSH.com states that SSH is _not_ affected by the bug. I haven't found > >> anything regarding openSSH, though. > >> > >> We are currently in a discussion as to whether or not we should be > >> updating the host keys across our entire enterprise. If SSH doesn't use > >> TLS, which the bug affects, is it necessary to replace the host keys? > >> > > > > -- > > Mr. Flibble > > King of the Potato People > > http://www.linkedin.com/in/RobertLanning > > _______________________________________________ > > Tech mailing list > > [email protected] > > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > > This list provided by the League of Professional System Administrators > > http://lopsa.org/ > > - -- - --- Craig Miskell, System Administrator, Catalyst IT Ltd DDI: +64 4 802-0427 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBAgAGBQJTcoEZAAoJENezkH+p+mMX3d0P/1K+ngtVedJaZGaP2tMS029H QN10xbspJmORafDVPlpyciDMWuMbPE9e85aMxMAHlsNcv4rs0u5vunq2E5BY1rqN SAeYTXazj+pgZb8WdRfeQEhSoYkNS+wBsFqamYy8JrulKy4udxZ3uxa6MjOfGQX/ ciJ3ncLohf2xsnk116nmqO2OHSzDDmGhick+I3zlbldd/w9WISSdry+svHRD4EBX JK5ejjdvsgmT/uOlF28XZvJMwQa5TBOQntRHBZUKqV7J3Wsv1nH3n+Pmm20FQ6+E 3v42Ev+z18lHubmYNIbIv4rG9Qqzt2Q5LZGVNMDuInMquJQFt+4AVWk32/cIQHVb NM2CgpXIXtpOs/XzrPxyVjtS7npvYcTL3IjwsgnrQ44GfegpL5aaE/kjPgmEGes0 rI8mXH3uxxHWNJ+zxJhbuhv5vQqnysr4m4NQjnEqEn3cE9U8/3sH9f9ApNh/d7Lu sXtDQLlq9//xyiwsV0hC1vMFABiFMZmX2lgh8ZIf8fT7im8Vfw74d02clgUOOS7h BsCKXXJ2h0+jSi3IsyaSBsouNyjtGVeWs3ncdjAtc3Qn/JZYlp49yEub6Med8R9P I4M5FtvPjClPWUAnvnpVKJm0p26fMkHG4obho/1YaCVjybwcGaelNJYOolLXWHhh QhDLO5MrZfsvvN5U9kZ8 =sSTH -----END PGP SIGNATURE----- _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
