On Tue, April 8, 2014 18:55, Lars Hecking wrote:
> Leon Fauster writes:
>> Am 08.04.2014 um 23:08 schrieb Keith Keller
>> <kkeller@xxxxxxxxxxxxxxxxxxxxxxxxxx>:
>> > On 2014-04-08, Robert Arkiletian <robark@xxxxxxxxx> 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?
--
*** E-Mail is NOT a SECURE channel ***
James B. Byrne mailto:ByrneJB@xxxxxxxxxxxxx
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
