Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 04/08/2014 02:15 PM, Peter van Hooft wrote: I use this (crude) script to find what processes have files open from an rpm: Does that work like /usr/bin/needs-restarting ? Mogens -- Mogens Kjaer, m...@lemo.dk http://www.lemo.dk ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On Tue, April 8, 2014 18:55, Lars Hecking wrote: Leon Fauster writes: Am 08.04.2014 um 23:08 schrieb Keith Keller kkel...@wombat.san-francisco.ca.us: On 2014-04-08, Robert Arkiletian rob...@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? -- *** E-Mail is NOT a SECURE channel *** James B. Byrnemailto:byrn...@harte-lyne.ca 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@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
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... -- rgds Stephen ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
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 signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: Earlier in the day today, we were made aware of a serious issue in openssl as shipped in CentOS-6.5 ( including updates issued since CentOS-6.5 was released ); This issue is addressed in detail at http://heartbleed.com/ So it looks like new packages were issued by upstream pretty quickly. So one question is, is there an easy way to know which services need to be kicked? I was surprised (not unpleasantly) to note that sshd is not linked against libssl, but if you do a naive check against httpd, you won't find it linked either--because it's mod_ssl that's linked against it. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: Earlier in the day today, we were made aware of a serious issue in openssl as shipped in CentOS-6.5 ( including updates issued since CentOS-6.5 was released ); This issue is addressed in detail at http://heartbleed.com/ is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Message: 23
Date: Tue, 8 Apr 2014 07:08:30 -0400
From: Steven Tardy sjt5a...@gmail.com
Subject: Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed
workaround
To: CentOS mailing list centos@centos.org
Message-ID:
CAG2k2x9udVEty0BRS+pEj0Hy3Mrt5N7NeCfZZC1r9qyv0M=r...@mail.gmail.com
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller
kkel...@wombat.san-francisco.ca.us wrote:
On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote:
Earlier in the day today, we were made aware of a serious
issue in openssl as shipped in CentOS-6.5 ( including updates issued
since CentOS-6.5 was released ); This issue is addressed in detail at
http://heartbleed.com/
is there an easy way to know which services need to be kicked?
rpm -q --whatrequires openssl
That should work, in theory.
On one of my machines:
# rpm -q --whatrequires openssl
postfix-2.6.6-2.2.el6_1.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64
#
Then try:
# yum remove openssl 21 | grep 'will be erased' | wc -l
421
#
I use this (crude) script to find what processes have files open from an rpm:
--
#! /bin/bash -p
if [[ $(whoami) != root ]]; then
echo $0: must be root 2
exit 1
fi
if [[ -z $1 ]]; then
echo usage: $0 rpm... 2
exit 1
fi
tmpfile=$(mktemp) || {
echo $0: couldn't create temporary file 2
exit 1
}
trap rm -f $tmpfile EXIT
for rpm in $*; do
if ! rpm -q $rpm /dev/null 21; then
echo $0: no such rpm $1 2
exit 1
fi
rpm -ql $rpm $tmpfile
done
fgrep -f $tmpfile /proc/*/maps | awk -F/ '{print $3}' | sort -u | while read
pid; do
echo $(ls -l /proc/$pid/exe | awk '{print $NF}') ($pid) ($(tr '\0' ' '
/proc/$pid/cmdline))
done | sort -u
--
# ./processes-that-use-files-from-an-rpm openssl
/usr/bin/python (13146) (/usr/bin/python /usr/bin/fail2ban-server -b -s
/var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x )
/usr/libexec/mysqld (1626) (/usr/libexec/mysqld --basedir=/usr
--datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log
--pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock )
/usr/sbin/certmonger (1776) (/usr/sbin/certmonger -S -p /var/run/certmonger.pid
)
/usr/sbin/httpd (1709) (/usr/sbin/httpd )
/usr/sbin/httpd (20152) (/usr/sbin/httpd )
/usr/sbin/httpd (20153) (/usr/sbin/httpd )
/usr/sbin/httpd (20154) (/usr/sbin/httpd )
/usr/sbin/httpd (20155) (/usr/sbin/httpd )
/usr/sbin/httpd (20156) (/usr/sbin/httpd )
/usr/sbin/httpd (20157) (/usr/sbin/httpd )
/usr/sbin/httpd (20158) (/usr/sbin/httpd )
/usr/sbin/httpd (20159) (/usr/sbin/httpd )
/usr/sbin/httpd (20160) (/usr/sbin/httpd )
/usr/sbin/ntpd (1484) (ntpd -u ntp:ntp -p /var/run/ntpd.pid -g )
/usr/sbin/sendmail.sendmail (1667) (sendmail: accepting connections)
/usr/sbin/sendmail.sendmail (1678) (sendmail: Queue runner@01:00:00 for
/var/spool/clientmqueue)
/usr/sbin/sshd (1456) (/usr/sbin/sshd )
/usr/sbin/sshd (28396) (sshd: root@pts/0 )
#
And depending on this output I restart the services mentioned, or if there are
to many, reboot the box :-)
Regards,
Peter van Hooft
Philips Research
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 8 April 2014 12:08, Steven Tardy sjt5a...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: Earlier in the day today, we were made aware of a serious issue in openssl as shipped in CentOS-6.5 ( including updates issued since CentOS-6.5 was released ); This issue is addressed in detail at http://heartbleed.com/ is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl A slightly cleaner way: lsof -n | grep ssl | grep DEL That should show any processes that are using the old deleted library for you to restart... Tomcat, apache httpd, postfix, postgresl, mysql... best just to restart any network facing application that has SSL enabled ;) ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Am 08.04.2014 um 15:02 schrieb James Hogarth james.hoga...@gmail.com: On 8 April 2014 12:08, Steven Tardy sjt5a...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl A slightly cleaner way: lsof -n | grep ssl | grep DEL lsof -n | grep -E 'libcry|libssl' | grep DEL :-) -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 2014-04-08, James Hogarth james.hoga...@gmail.com wrote: Tomcat, apache httpd, postfix, postgresl, mysql... best just to restart any network facing application that has SSL enabled ;) Actually, I should have been more thorough: I am also interested in knowing which credentials were vulnerable, so I can set policy on what passwords must be changed as soon as possible. If sshd had been vulnerable, for example, I would have to force them to change that password immediately. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
In article a46cca43-0ba5-43bb-9659-176311bf8...@googlemail.com, Leon Fauster leonfaus...@googlemail.com wrote: Am 08.04.2014 um 15:02 schrieb James Hogarth james.hoga...@gmail.com: On 8 April 2014 12:08, Steven Tardy sjt5a...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl A slightly cleaner way: lsof -n | grep ssl | grep DEL lsof -n | grep -E 'libcry|libssl' | grep DEL Actually, on CentOS it appears that DEL doesn't show you. The actual string to grep on is 'deleted': [root@vps1 ~]# lsof -n | grep -E 'libcry|libssl' | grep deleted vsftpd 804root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) vsftpd 804root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) mysqld 996 mysql mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) mysqld 996 mysql mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) saslauthd 1042root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) saslauthd 1043root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) sendmail 1058root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) sendmail 1058root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) sendmail 1066 smmsp mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) sendmail 1066 smmsp mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) fail2ban- 1090root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) fail2ban- 1090root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) assp.pl1198assp mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) assp.pl1198assp mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) miniserv. 1223root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) miniserv. 1223root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) miniserv. 1229root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) miniserv. 1229root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) named 12887 named mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) And I notice that the new libraries after applying the update are STILL called 1.0.1e - is that correct? Could be confusing. [root@vps1 ~]# lsof -n | grep -E 'libcry|libssl' | grep -v deleted httpd 7495root mem REG 0,701950976 73794323 /usr/lib64/libcrypto.so.1.0.1e httpd 7495root mem REG 0,70 441112 73794344 /usr/lib64/libssl.so.1.0.1e httpd 7495root mem REG 0,70 250168 151994454 /usr/lib64/libssl3.so httpd 7495root mem REG 0,70 40400 73728467 /lib64/libcrypt-2.12.so ... now to go and reboot the server. Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Le 08/04/2014 19:05, Tony Mountifield a écrit : And I notice that the new libraries after applying the update are STILL called 1.0.1e - is that correct? Could be confusing. Because at this time, it's only a workaround that disable certain services, not a fix to the libraries, as I read in the annoucement ? Alain -- Administrateur Système/Réseau Laboratoire de Photonique et Nanostructures (LPN/CNRS - UPR20) Centre de Recherche Alcatel Data IV - Marcoussis route de Nozay - 91460 Marcoussis Tel : 01-69-63-61-34 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 04/08/2014 01:12 PM, Alain Péan wrote: Le 08/04/2014 19:05, Tony Mountifield a écrit : And I notice that the new libraries after applying the update are STILL called 1.0.1e - is that correct? Could be confusing. Because at this time, it's only a workaround that disable certain services, not a fix to the libraries, as I read in the annoucement ? Alain According to the changelog this update 5.7 fixed the cve. $ rpm -qa|grep openssl openssl-1.0.1e-16.el6_5.7.x86_64 openssl-devel-1.0.1e-16.el6_5.7.x86_64 Tue Apr 8 12:17:25 EDT 2014 Z643357:~ $ rpm -q --changelog openssl | less * Mon Apr 07 2014 Tomás( Mráz tm...@redhat.com 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension -- Stephen Clark *NetWolves Managed Services, LLC.* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On Tue, 2014-04-08 at 19:12 +0200, Alain Péan wrote:
Le 08/04/2014 19:05, Tony Mountifield a écrit :
And I notice that the new libraries after applying the update are
STILL called 1.0.1e - is that correct? Could be confusing.
Because at this time, it's only a workaround that disable certain
services, not a fix to the libraries, as I read in the annoucement ?
Alain
If you: rpm -qa | grep openssl
If you have: openssl-1.0.1e-16.el6_5.4.0.1
You have the package with affected elements disabled. These were made
until the final fixes could be brought in and applied.
If you have: openssl-1.0.1e-16.el6_5.7
You have the package with the upstream fix(es) applied and supersedes
the openssl-1.0.1e-16.el6_5.4.0.1 packages.
Regards
Phil
--
Phil Wyett
{
GNU Linux User and Developer
Leigh GNU Linux User Group (http://leigh.lug.org.uk)
IRC: philwyett
Twitter: philwyett and leigh_lug
}
signature.asc
Description: This is a digitally signed message part
___
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On Tue, Apr 8, 2014 at 6:23 AM, Leon Fauster leonfaus...@googlemail.com wrote: Am 08.04.2014 um 15:02 schrieb James Hogarth james.hoga...@gmail.com: On 8 April 2014 12:08, Steven Tardy sjt5a...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl A slightly cleaner way: lsof -n | grep ssl | grep DEL lsof -n | grep -E 'libcry|libssl' | grep DEL if you include libcrypto in the grep then sshd is affected. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 2014-04-08, Robert Arkiletian rob...@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? Since sshd is in doubt, I would like to force my users to change their password, which is stored on a central openldap server. What's the canonical CentOS way to do this? I've done some web searches for some answers, but haven't found anything really definitive, just some workarounds and some crude hacks. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Hi, What else needs to be restarted ? Anything reported by the lsof commands above ? Thank you, I. On Tue, Apr 8, 2014 at 9:33 PM, Robert Arkiletian rob...@gmail.com wrote: On Tue, Apr 8, 2014 at 6:23 AM, Leon Fauster leonfaus...@googlemail.com wrote: Am 08.04.2014 um 15:02 schrieb James Hogarth james.hoga...@gmail.com: On 8 April 2014 12:08, Steven Tardy sjt5a...@gmail.com wrote: On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Karanbir Singh kbsi...@centos.org wrote: is there an easy way to know which services need to be kicked? rpm -q --whatrequires openssl A slightly cleaner way: lsof -n | grep ssl | grep DEL lsof -n | grep -E 'libcry|libssl' | grep DEL if you include libcrypto in the grep then sshd is affected. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On Tue, Apr 8, 2014 at 2:08 PM, Keith Keller kkel...@wombat.san-francisco.ca.us wrote: On 2014-04-08, Robert Arkiletian rob...@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? Since sshd is in doubt, I would like to force my users to change their password, which is stored on a central openldap server. What's the canonical CentOS way to do this? I've done some web searches for some answers, but haven't found anything really definitive, just some workarounds and some crude hacks. I'm not positive but from reading other forums it seems sshd is *not* affected. http://security.stackexchange.com/questions/55076/what-should-a-website-operator-do-about-the-heartbleed-openssl-exploit snip--- It's worth pointing out that OpenSSH is not affected by the OpenSSL bug. While OpenSSH does use openssl for some key-generation functions, it does not use the TLS protocol (and in particular the TLS heartbeat extension that heartbleed attacks). So there is no need to worry about SSH being compromised, though it is still a good idea to update openssl to 1.0.1g or 1.0.2-beta2 (but you don't have to worry about replacing SSH keypairs). snip Can someone confirm the above to be true. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Am 08.04.2014 um 23:08 schrieb Keith Keller kkel...@wombat.san-francisco.ca.us: On 2014-04-08, Robert Arkiletian rob...@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. -- LF ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
On 2014-04-08, Leon Fauster leonfaus...@googlemail.com wrote: 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. So if it turns out to be true that the bug is in libssl, and not libcrypto (which so far seems like a reasonable guess, but has not yet been confirmed), then the following lsof should work to report active processes which are still vulnerable: lsof -n | grep -E libssl | grep -i DEL The -i makes the grep case-insensitive. I've seen both DEL and deleted in the lsof output for various CentOS versions; it's possible that an old lsof could still be running on a box with a vulnerable openssl, though, so it's safest to look for both patterns. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2014-0160 CentOS 6 openssl heartbleed workaround
Leon Fauster writes: Am 08.04.2014 um 23:08 schrieb Keith Keller kkel...@wombat.san-francisco.ca.us: On 2014-04-08, Robert Arkiletian rob...@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. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
