On Tue, April 8, 2014 18:55, Lars Hecking wrote:
Leon Fauster writes:
Am 08.04.2014 um 23:08 schrieb Keith Keller kkeller@wombat.san-francisco.ca.us:
On 2014-04-08, Robert Arkiletian robark@gmail.com wrote:
if you include libcrypto in the grep then sshd is affected.
That's unfortunate. :( Is the bug in libssl, libcrypto, or both?
looking inside - its seems that this issue (cve-2014-0160) is resolved in ssl/d1_both.c and ssl/t1_lib.c and not in files under crypto/ ... to say more i have to take a look into the build process.
The OpenBSD note for the patch reads (http://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/007_openssl.patch)
| Only SSL/TLS services are affected. Software that uses libcrypto alone | is not affected. In particular, ssh/sshd are not affected and there | is no need to regenerate SSH host keys that have not otherwise been | exposed.
The patched code is the same everywhere, ssl subdirectory only. Code in the crytpo subdirectory is not affected or patched.
However, if one was running an affected service, say httpd/ mod_ssl, on a host that had sftp sessions connected to it then would not the ssh private keys of the host and local users be in memory and therefore readable by the exploit? If so then are not all these keys potentially compromised as we have no idea how long this exploit has been known to others prior to the community's own discovery?
I have only a vague idea how all this stuff works but it seems to me that it is necessary that the private keys of all PKI implementations at some point have to be somewhere in memory in their usable, and therefore observable, state. As I understand the exploit it allows systematic transfer of every byte in memory which would include the unprotected keys would it not?
On Wed, Apr 09, 2014 at 09:36:25AM -0400, James B. Byrne wrote:
However, if one was running an affected service, say httpd/ mod_ssl, on a host that had sftp sessions connected to it then would not the ssh private keys of the host and local users be in memory and therefore readable by the exploit?
[...]
state. As I understand the exploit it allows systematic transfer of every byte in memory which would include the unprotected keys would it not?
I'm pretty sure the exploit can only read the memory of the process and not of the kernel; "apache" shouldn't be able to read the memory space of a root process. If it could then we'd have no key security at all, anyway! This isn't a privilege escalation attack...
On 04/09/2014 07:40 AM, Stephen Harris wrote:
On Wed, Apr 09, 2014 at 09:36:25AM -0400, James B. Byrne wrote:
However, if one was running an affected service, say httpd/ mod_ssl, on a host that had sftp sessions connected to it then would not the ssh private keys of the host and local users be in memory and therefore readable by the exploit?
[...]
state. As I understand the exploit it allows systematic transfer of every byte in memory which would include the unprotected keys would it not?
I'm pretty sure the exploit can only read the memory of the process and not of the kernel; "apache" shouldn't be able to read the memory space of a root process. If it could then we'd have no key security at all, anyway! This isn't a privilege escalation attack...
According to heartbleed,org, private keys for httpd (or other TLS / SSL services) are readable. Though the 64KB bit of memory obtainable is random, so its not like they can just ask for the private keys or query a database for someone's password, etc. They could only get a random chunk of things active in memory when they make the request. For what its worth, CentOS.org is replacing our certificate private keys. Others can obviously make their own choices.
Thanks, Johnny Hughes
-
James B. Byrne -
Johnny Hughes -
Stephen Harris