On 2014-04-08, Karanbir Singh kbsingh@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
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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
On 8 April 2014 12:08, Steven Tardy sjt5atra@gmail.com wrote:
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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 ;)
Am 08.04.2014 um 15:02 schrieb James Hogarth james.hogarth@gmail.com:
On 8 April 2014 12:08, Steven Tardy sjt5atra@gmail.com wrote:
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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
In article A46CCA43-0BA5-43BB-9659-176311BF8471@googlemail.com, Leon Fauster leonfauster@googlemail.com wrote:
Am 08.04.2014 um 15:02 schrieb James Hogarth james.hogarth@gmail.com:
On 8 April 2014 12:08, Steven Tardy sjt5atra@gmail.com wrote:
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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 804 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) vsftpd 804 root 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 1042 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) saslauthd 1043 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) sendmail 1058 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) sendmail 1058 root 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- 1090 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) fail2ban- 1090 root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) assp.pl 1198 assp mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) assp.pl 1198 assp mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) miniserv. 1223 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) miniserv. 1223 root mem REG 0,70 73794353 (deleted)/usr/lib64/libssl.so.1.0.1e (stat: No such file or directory) miniserv. 1229 root mem REG 0,70 73794333 (deleted)/usr/lib64/libcrypto.so.1.0.1e (stat: No such file or directory) miniserv. 1229 root 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 7495 root mem REG 0,70 1950976 73794323 /usr/lib64/libcrypto.so.1.0.1e httpd 7495 root mem REG 0,70 441112 73794344 /usr/lib64/libssl.so.1.0.1e httpd 7495 root mem REG 0,70 250168 151994454 /usr/lib64/libssl3.so httpd 7495 root mem REG 0,70 40400 73728467 /lib64/libcrypt-2.12.so
... now to go and reboot the server.
Cheers Tony
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
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 tmraz@redhat.com 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
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
On 04/08/2014 10:37 AM, Phil Wyett wrote:
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.
What packages do I look for on EL5.X?
Thanks,
Ben
On Tue, 2014-04-08 at 12:08 -0600, Frank Cox wrote:
On Tue, 08 Apr 2014 11:03:50 -0700 Lists wrote:
What packages do I look for on EL5.X?
You don't. The bug doesn't affect el5.
Frank is correct.
https://bugzilla.redhat.com/show_bug.cgi?id=1084875#c9
The above link has the info within the relevant bug report.
Regards
Phil
On Tue, Apr 8, 2014 at 6:23 AM, Leon Fauster leonfauster@googlemail.com wrote:
Am 08.04.2014 um 15:02 schrieb James Hogarth james.hogarth@gmail.com:
On 8 April 2014 12:08, Steven Tardy sjt5atra@gmail.com wrote:
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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.
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?
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
On Tue, Apr 8, 2014 at 2:08 PM, Keith Keller kkeller@wombat.san-francisco.ca.us wrote:
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?
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-oper... ----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.
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.
-- LF
On 2014-04-08, Leon Fauster leonfauster@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
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.
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 robark@gmail.com wrote:
On Tue, Apr 8, 2014 at 6:23 AM, Leon Fauster leonfauster@googlemail.com wrote:
Am 08.04.2014 um 15:02 schrieb James Hogarth james.hogarth@gmail.com:
On 8 April 2014 12:08, Steven Tardy sjt5atra@gmail.com wrote:
On Tue, Apr 8, 2014 at 2:56 AM, Keith Keller < kkeller@wombat.san-francisco.ca.us> wrote:
On 2014-04-08, Karanbir Singh kbsingh@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
On 2014-04-08, James Hogarth james.hogarth@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
-
Alain Péan -
Frank Cox -
Ionut Hoza -
James Hogarth -
Keith Keller -
Lars Hecking -
Leon Fauster -
Lists -
Phil Wyett -
Robert Arkiletian -
Steve Clark -
Steven Tardy -
tony＠softins.co.uk