Re: openssl

[Stephen John Smoogen]

On 4 March 2016 at 08:24, Connie Sieh  wrote:
> I do not think it will.  You will notice that there is nothing in that
> directory newer than 2012.
>
> The RHEL support matrix is at
>
> https://access.redhat.com/support/policy/updates/errata
>
> If you need errata support for RHEL 4 then I suggest you purchase a RHEL 4
> subscription and "purchase annual Add-on subscriptions called Extended Life
> Cycle Support (ELS) that provide similar support to Production Phase 3
> through March 31, 2017" .  Red Hat does not publish the srpm to the ELS
> support packages in the public ftp area .
>

That is correct. Fixed RPMS for various security issues are only
available through this method. In about 12 months this will be the
case for EL5 packages also.

> --
>
> Connie J. Sieh
> Computing Services Specialist III
>
> Fermi National Accelerator Laboratory
> 630 840 8531 office
>
> http://www.fnal.gov
> cs...@fnal.gov
>
> On Fri, 4 Mar 2016, Paul Casteels wrote:
>
>> Thanks for the link. I hope it will become available there in a few days.=
>>
>>
>> Kind regards
>> Paul Casteels
>>
>



-- 
Stephen J Smoogen.

Re: openssl

[Connie Sieh]

I do not think it will.  You will notice that there is nothing in that 
directory newer than 2012.


The RHEL support matrix is at

https://access.redhat.com/support/policy/updates/errata

If you need errata support for RHEL 4 then I suggest you purchase a RHEL 4 
subscription and "purchase annual Add-on subscriptions called Extended 
Life Cycle Support (ELS) that provide similar support to Production Phase 
3 through March 31, 2017" .  Red Hat does not publish the srpm to the ELS 
support packages in the public ftp area .


--

Connie J. Sieh
Computing Services Specialist III

Fermi National Accelerator Laboratory
630 840 8531 office

http://www.fnal.gov
cs...@fnal.gov

On Fri, 4 Mar 2016, Paul Casteels wrote:


Thanks for the link. I hope it will become available there in a few days.=


Kind regards
Paul Casteels

Re: openssl

[Paul Casteels]

Thanks for the link. I hope it will become available there in a few days.

Kind regards
Paul Casteels

Re: openssl

[Bonnie King]

On 03/03/2016 02:47 PM, Connie Sieh wrote:

On Thu, 3 Mar 2016, Paul Casteels wrote:


For the DROWN security vulnerability a patch for RHEL4 was released by
Re=
dHat:
 openssl-0.9.7a-43.23.el4.ia64.rpm
 openssl-devel-0.9.7a-43.23.el4.ia64.rpm
Is there any chance it will become available for SL4?



It does not seem to be available via the "free" ftp.redhat.com site.

-rw-r--r--5 ftp  ftp   2816961 Feb 01  2012
openssl-0.9.7a-43.18.el4.src.rpm
lftp ftp.redhat.com:/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS>




SL4 has been end of life for 4 years. No SL4 updates will be released.

--
Bonnie King
Assistant Group Leader
Scientific Linux & Architecture Management

Fermi National Accelerator Laboratory
630-840-8761 office
773-799-4608 cell
www.fnal.gov

Re: openssl

[Connie Sieh]

On Thu, 3 Mar 2016, Paul Casteels wrote:


For the DROWN security vulnerability a patch for RHEL4 was released by Re=
dHat:
 openssl-0.9.7a-43.23.el4.ia64.rpm
 openssl-devel-0.9.7a-43.23.el4.ia64.rpm
Is there any chance it will become available for SL4?



It does not seem to be available via the "free" ftp.redhat.com site.

-rw-r--r--5 ftp  ftp   2816961 Feb 01  2012 
openssl-0.9.7a-43.18.el4.src.rpm
lftp ftp.redhat.com:/pub/redhat/linux/updates/enterprise/4AS/en/os/SRPMS>


--
--

Connie J. Sieh
Computing Services Specialist III

Fermi National Accelerator Laboratory
630 840 8531 office

http://www.fnal.gov
cs...@fnal.gov

openssl

[Paul Casteels]

For the DROWN security vulnerability a patch for RHEL4 was released by RedHat:
  openssl-0.9.7a-43.23.el4.ia64.rpm
  openssl-devel-0.9.7a-43.23.el4.ia64.rpm
Is there any chance it will become available for SL4?

Re: Security ERRATA Important: openssl on SL5.x i386/x86_64

[P. Larry Nelson]

Pat,

I am now thoroughly confused.
Two erratas just arrived for openssl - both with the same CVE numbers,
but different Advisory ID's, *and* with different versions of openssl.
(see referenced emails below).

I just checked my SL5.x systems and they are showing
openssl-0.9.8e-27.el5_10.3.i686 updated 6/5/14, the same version
your showing in the 2nd email (2nd email below).

I checked my SL6.x systems and they are showing
openssl-1.0.1e-16.el6_5.14.x86_64, a *later* version than what
your showing in the first email (1st email below)

Thanks!
- Larry

Pat Riehecky wrote on 6/11/2014 10:32 AM: Synopsis:  Important: openssl 
security update

 Advisory ID:   SLSA-2014:0627-1
 Issue Date:2014-06-05
 CVE Numbers:   CVE-2014-0224
 --

 It was found that OpenSSL clients and servers could be forced, via a
 specially crafted handshake packet, to use weak keying material for
 communication. A man-in-the-middle attacker could use this flaw to decrypt
 and modify traffic between a client and a server. (CVE-2014-0224)

 Note: In order to exploit this flaw, both the server and the client must
 be using a vulnerable version of OpenSSL; the server must be using OpenSSL
 version 1.0.1 and above, and the client must be using any version of
 OpenSSL. For more information about this flaw, refer to:

 For the update to take effect, all services linked to the OpenSSL library
 (such as httpd and other SSL-enabled services) must be restarted or the
 system rebooted.
 --

 SL5
x86_64
  openssl-0.9.8e-12.el5_6.12.i686.rpm
  openssl-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i386.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i686.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-devel-0.9.8e-12.el5_6.12.i386.rpm
  openssl-devel-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-perl-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-0.9.8e-26.el5_9.4.i686.rpm
  openssl-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i386.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i686.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-devel-0.9.8e-26.el5_9.4.i386.rpm
  openssl-devel-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-perl-0.9.8e-26.el5_9.4.x86_64.rpm
i386
  openssl-0.9.8e-12.el5_6.12.i386.rpm
  openssl-0.9.8e-12.el5_6.12.i686.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i386.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i686.rpm
  openssl-devel-0.9.8e-12.el5_6.12.i386.rpm
  openssl-perl-0.9.8e-12.el5_6.12.i386.rpm
  openssl-0.9.8e-26.el5_9.4.i386.rpm
  openssl-0.9.8e-26.el5_9.4.i686.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i386.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i686.rpm
  openssl-devel-0.9.8e-26.el5_9.4.i386.rpm
  openssl-perl-0.9.8e-26.el5_9.4.i386.rpm
 SL6
x86_64
  openssl-1.0.0-25.el6_3.3.i686.rpm
  openssl-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.i686.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-1.0.0-27.el6_4.4.i686.rpm
  openssl-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.i686.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-devel-1.0.0-25.el6_3.3.i686.rpm
  openssl-devel-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-perl-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-static-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-devel-1.0.0-27.el6_4.4.i686.rpm
  openssl-devel-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-perl-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-static-1.0.0-27.el6_4.4.x86_64.rpm
i386
  openssl-1.0.0-25.el6_3.3.i686.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.i686.rpm
  openssl-devel-1.0.0-25.el6_3.3.i686.rpm
  openssl-1.0.0-27.el6_4.4.i686.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.i686.rpm
  openssl-devel-1.0.0-27.el6_4.4.i686.rpm
  openssl-perl-1.0.0-25.el6_3.3.i686.rpm
  openssl-static-1.0.0-25.el6_3.3.i686.rpm
  openssl-perl-1.0.0-27.el6_4.4.i686.rpm
  openssl-static-1.0.0-27.el6_4.4.i686.rpm

 - Scientific Linux Development Team




Pat Riehecky wrote on 6/11/2014 10:33 AM:

Synopsis:  Important: openssl security update
Advisory ID:   SLSA-2014:0624-1
Issue Date:2014-06-05
CVE Numbers:   CVE-2014-0224
--

It was found that OpenSSL clients and servers could be forced, via a
specially crafted handshake packet, to use weak keying material for
communication. A man-in-the-middle attacker could use this flaw to decrypt
and modify traffic between a client and a server. (CVE-2014-0224)

Note: In order to exploit this flaw, both the server and the client must
be using a vulnerable version of OpenSSL; the server must be using OpenSSL
version 1.0.1 and above, and the client must be using any version of
OpenSSL. For more information about this flaw, refer to:

For the update to take effect, all services linked to the OpenSSL library
(such as httpd and other SSL-enabled

Re: [SCIENTIFIC-LINUX-USERS] Security ERRATA Important: openssl on SL5.x i386/x86_64

[Pat Riehecky]

Hi Larry,

Good call.

The most recent announcements seem to be for the EUS (extended update 
support) for the upstream product.


Looks like somehow I sent those off rather than archiving them.

Sorry for the confusion.  I probably shouldn't multi-task quite so much

Pat

On 06/11/2014 12:56 PM, P. Larry Nelson wrote:

Pat,

I am now thoroughly confused.
Two erratas just arrived for openssl - both with the same CVE numbers,
but different Advisory ID's, *and* with different versions of openssl.
(see referenced emails below).

I just checked my SL5.x systems and they are showing
openssl-0.9.8e-27.el5_10.3.i686 updated 6/5/14, the same version
your showing in the 2nd email (2nd email below).

I checked my SL6.x systems and they are showing
openssl-1.0.1e-16.el6_5.14.x86_64, a *later* version than what
your showing in the first email (1st email below)

Thanks!
- Larry

Pat Riehecky wrote on 6/11/2014 10:32 AM: Synopsis: Important: 
openssl security update

 Advisory ID:   SLSA-2014:0627-1
 Issue Date:2014-06-05
 CVE Numbers:   CVE-2014-0224
 --

 It was found that OpenSSL clients and servers could be forced, via a
 specially crafted handshake packet, to use weak keying material for
 communication. A man-in-the-middle attacker could use this flaw to 
decrypt

 and modify traffic between a client and a server. (CVE-2014-0224)

 Note: In order to exploit this flaw, both the server and the client 
must
 be using a vulnerable version of OpenSSL; the server must be using 
OpenSSL

 version 1.0.1 and above, and the client must be using any version of
 OpenSSL. For more information about this flaw, refer to:

 For the update to take effect, all services linked to the OpenSSL 
library

 (such as httpd and other SSL-enabled services) must be restarted or the
 system rebooted.
 --

 SL5
x86_64
  openssl-0.9.8e-12.el5_6.12.i686.rpm
  openssl-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i386.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i686.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-devel-0.9.8e-12.el5_6.12.i386.rpm
  openssl-devel-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-perl-0.9.8e-12.el5_6.12.x86_64.rpm
  openssl-0.9.8e-26.el5_9.4.i686.rpm
  openssl-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i386.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i686.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-devel-0.9.8e-26.el5_9.4.i386.rpm
  openssl-devel-0.9.8e-26.el5_9.4.x86_64.rpm
  openssl-perl-0.9.8e-26.el5_9.4.x86_64.rpm
i386
  openssl-0.9.8e-12.el5_6.12.i386.rpm
  openssl-0.9.8e-12.el5_6.12.i686.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i386.rpm
  openssl-debuginfo-0.9.8e-12.el5_6.12.i686.rpm
  openssl-devel-0.9.8e-12.el5_6.12.i386.rpm
  openssl-perl-0.9.8e-12.el5_6.12.i386.rpm
  openssl-0.9.8e-26.el5_9.4.i386.rpm
  openssl-0.9.8e-26.el5_9.4.i686.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i386.rpm
  openssl-debuginfo-0.9.8e-26.el5_9.4.i686.rpm
  openssl-devel-0.9.8e-26.el5_9.4.i386.rpm
  openssl-perl-0.9.8e-26.el5_9.4.i386.rpm
 SL6
x86_64
  openssl-1.0.0-25.el6_3.3.i686.rpm
  openssl-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.i686.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-1.0.0-27.el6_4.4.i686.rpm
  openssl-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.i686.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-devel-1.0.0-25.el6_3.3.i686.rpm
  openssl-devel-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-perl-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-static-1.0.0-25.el6_3.3.x86_64.rpm
  openssl-devel-1.0.0-27.el6_4.4.i686.rpm
  openssl-devel-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-perl-1.0.0-27.el6_4.4.x86_64.rpm
  openssl-static-1.0.0-27.el6_4.4.x86_64.rpm
i386
  openssl-1.0.0-25.el6_3.3.i686.rpm
  openssl-debuginfo-1.0.0-25.el6_3.3.i686.rpm
  openssl-devel-1.0.0-25.el6_3.3.i686.rpm
  openssl-1.0.0-27.el6_4.4.i686.rpm
  openssl-debuginfo-1.0.0-27.el6_4.4.i686.rpm
  openssl-devel-1.0.0-27.el6_4.4.i686.rpm
  openssl-perl-1.0.0-25.el6_3.3.i686.rpm
  openssl-static-1.0.0-25.el6_3.3.i686.rpm
  openssl-perl-1.0.0-27.el6_4.4.i686.rpm
  openssl-static-1.0.0-27.el6_4.4.i686.rpm

 - Scientific Linux Development Team




Pat Riehecky wrote on 6/11/2014 10:33 AM:

Synopsis:  Important: openssl security update
Advisory ID:   SLSA-2014:0624-1
Issue Date:2014-06-05
CVE Numbers:   CVE-2014-0224
--

It was found that OpenSSL clients and servers could be forced, via a
specially crafted handshake packet, to use weak keying material for
communication. A man-in-the-middle attacker could use this flaw to 
decrypt

and modify traffic between a client and a server. (CVE-2014-0224)

Note: In order to exploit this flaw, both the server and the client

Re: Security ERRATA Important: openssl on SL6.x i386/x86_64

[Dag Wieers]

On Wed, 9 Apr 2014, David Sommerseth wrote:


On 09/04/14 16:42, Pat Riehecky wrote:


All applications linked against openssl must be restarted for this
update to take effect.


I installed lsof on my boxes and used

 [root@host: ~]# lsof | grep -E libcrypto|libssl | grep DEL

to identify processes/services which needs to be restarted.


This is incorrect, only libssl is relevant. Therefore sshd, snmpd, 
saslauthd or ntpd are not affected since they link only to libcrypto.so.


So this suffices:

# lsof | grep -P \bDEL\b.+libssl.so.1.0.1e$

and it will not catch any older processes still using the RHEL6.4 openssl 
libraries (in case your system was not rebooted after the upgrade to 
RHEL6.5).


--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, cont...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

heartbleed and openssl update

[William Lutter]

I see this link relative to openssl and heartbleed exploit...

https://www.openssl.org/news/secadv_20140407.txt

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 
and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 
will be fixed in 1.0.2-beta2.

My SL 6.5 lists
openssl-1.0.1e-16.el6_5.7.x86_64
openssl098e-0.9.8e-17.el6_2.2.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64

so, it is a vulnerable version of openssl.

Question 1
I enabled fastbugs in sl-other.repo and well as usual enables in sl.repo, 
however, do not see an update for openssl.

Will there be one forthcoming from SL or have I missed the proper repository to 
get it? 
I have no server on this PC, so I am not worried yet.

Question 2
I surmise that older versions of openssl on older SLs are not impacted
such as
openssl-0.9.8e-26.el5_9.1.i686

Bill Lutter

Re: heartbleed and openssl update

[Connie Sieh]

On Thu, 10 Apr 2014, William Lutter wrote:


I see this link relative to openssl and heartbleed exploit...

https://www.openssl.org/news/secadv_20140407.txt

A missing bounds check in the handling of the TLS heartbeat extension can be
used to reveal up to 64k of memory to a connected client or server. Only 1.0.1 
and 1.0.2-beta releases of OpenSSL are affected including
1.0.1f and 1.0.2-beta1.

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately
upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. 1.0.2 
will be fixed in 1.0.2-beta2.

My SL 6.5 lists
openssl-1.0.1e-16.el6_5.7.x86_64
openssl098e-0.9.8e-17.el6_2.2.x86_64
openssl-devel-1.0.1e-16.el6_5.7.x86_64

so, it is a vulnerable version of openssl.


No,  that is the updated version.  TUV backports security errata.  They 
key is the .7 in el6_5.7 .




Question 1 I enabled fastbugs in sl-other.repo and well as usual enables 
in sl.repo, however, do not see an update for openssl.


Will there be one forthcoming from SL or have I missed the proper 
repository to get it? I have no server on this PC, so I am not worried 
yet.


It was released on Tuesday morning.



Question 2
I surmise that older versions of openssl on older SLs are not impacted
such as
openssl-0.9.8e-26.el5_9.1.i686


Not impacted.



Bill Lutter



-Connie Sieh

Fwd: Security ERRATA Important: openssl on SL6.x i386/x86_64

[Pat Riehecky]

This is a reminder of this security errata.

Any SL6 system should apply this update.  If your system has been 
applying security errata regularly it is vulnerable until this update is 
applied.


Systems with yum-autoupdate enabled using the default configuration have 
the update applied and only need to restart applications linked against 
openssl.


All applications linked against openssl must be restarted for this 
update to take effect.


Pat


 Original Message 
Subject: 	[SCIENTIFIC-LINUX-ERRATA] Security ERRATA Important: openssl 
on SL6.x i386/x86_64

Date:   Tue, 8 Apr 2014 13:39:35 +
From:   Pat Riehecky riehe...@fnal.gov
Reply-To:   scientific-linux-users@listserv.fnal.gov
To: scientific-linux-err...@listserv.fnal.gov



Synopsis:  Important: openssl security update
Advisory ID:   SLSA-2014:0376-1
Issue Date:2014-04-08
CVE Numbers:   CVE-2014-0160
--

An information disclosure flaw was found in the way OpenSSL handled TLS
and DTLS Heartbeat Extension packets. A malicious TLS or DTLS client or
server could send a specially crafted TLS or DTLS Heartbeat packet to
disclose a limited portion of memory per request from a connected client
or server. Note that the disclosed portions of memory could potentially
include sensitive information such as private keys. (CVE-2014-0160)

For the update to take effect, all services linked to the OpenSSL library
(such as httpd and other SSL-enabled services) must be restarted or the
system rebooted.
--

SL6
  x86_64
openssl-1.0.1e-16.el6_5.7.i686.rpm
openssl-1.0.1e-16.el6_5.7.x86_64.rpm
openssl-debuginfo-1.0.1e-16.el6_5.7.i686.rpm
openssl-debuginfo-1.0.1e-16.el6_5.7.x86_64.rpm
openssl-devel-1.0.1e-16.el6_5.7.i686.rpm
openssl-devel-1.0.1e-16.el6_5.7.x86_64.rpm
openssl-perl-1.0.1e-16.el6_5.7.x86_64.rpm
openssl-static-1.0.1e-16.el6_5.7.x86_64.rpm
  i386
openssl-1.0.1e-16.el6_5.7.i686.rpm
openssl-debuginfo-1.0.1e-16.el6_5.7.i686.rpm
openssl-devel-1.0.1e-16.el6_5.7.i686.rpm
openssl-perl-1.0.1e-16.el6_5.7.i686.rpm
openssl-static-1.0.1e-16.el6_5.7.i686.rpm

- Scientific Linux Development Team

Re: Security ERRATA Important: openssl on SL6.x i386/x86_64

[David Sommerseth]

On 09/04/14 16:42, Pat Riehecky wrote:
 This is a reminder of this security errata.
 
 Any SL6 system should apply this update.  If your system has been
 applying security errata regularly it is vulnerable until this update is
 applied.
 
 Systems with yum-autoupdate enabled using the default configuration have
 the update applied and only need to restart applications linked against
 openssl.
 
 All applications linked against openssl must be restarted for this
 update to take effect.

I installed lsof on my boxes and used

  [root@host: ~]# lsof | grep -E libcrypto|libssl | grep DEL

to identify processes/services which needs to be restarted.


--
kind regards,

David Sommerseth

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Pat Riehecky]

The updated package should be available now.

Pat

On 04/08/2014 05:43 AM, Adam Bishop wrote:

Good Morning,

I’ve not seen a fixed OpenSSL package drop into the repo’s as of yet.

Apologies for asking the question, but how quickly will this be packaged and 
made available (i.e. should I start building the package myself)?

Regards,

Adam Bishop
Systems Development Specialist

   gpg: 0x6609D460
 t: +44 (0)1235 822 245
  xmpp: ad...@jabber.dev.ja.net

Janet, the UK's research and education network.


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
not-for-profit company which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

RE: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Bohmer, Andre ten]

Yep it is and a heartbleed check now fails (don't forget to restart httpd and 
other  services which do relay on openssl)

Thanks!
Andre

 -Original Message-
 From: owner-scientific-linux-us...@listserv.fnal.gov [mailto:owner-
 scientific-linux-users@listserv.fnal.gov] On Behalf Of Pat Riehecky
 Sent: dinsdag 8 april 2014 16:10
 To: Adam Bishop; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
 Subject: Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability
 
 The updated package should be available now.
 
 Pat
 
 On 04/08/2014 05:43 AM, Adam Bishop wrote:
  Good Morning,
 
  I’ve not seen a fixed OpenSSL package drop into the repo’s as of yet.
 
  Apologies for asking the question, but how quickly will this be packaged
 and made available (i.e. should I start building the package myself)?
 
  Regards,
 
  Adam Bishop
  Systems Development Specialist
 
 gpg: 0x6609D460
   t: +44 (0)1235 822 245
xmpp: ad...@jabber.dev.ja.net
 
  Janet, the UK's research and education network.
 
 
  Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
  not-for-profit company which is registered in England under No.
  2881024 and whose Registered Office is at Lumen House, Library Avenue,
  Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
 
 
 --
 Pat Riehecky
 
 Scientific Linux developer
 http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Adam Bishop]

On 8 Apr 2014, at 15:10, Pat Riehecky riehe...@fnal.gov wrote:
 
 The updated package should be available now.

Brilliant, thanks for update.

Regards,

Adam Bishop

  gpg: 0x6609D460

Janet, the UK's research and education network.



Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Steven Miano]

The advise so far is to not only patch up, and restart services/hosts; but
to also revoke the certs and create new ones.

As the vulnerability left no trace of its happenings in any logs - and
someone who was actively exploiting it could still use the private key or
other ill begot materials.

Just a heads up.

RHEL/SL/Ubuntu/etc really aren't the big cause for concern (in many cases),
but more so the appliances that many enterprises use/buy/deploy..


On Tue, Apr 8, 2014 at 10:47 AM, Adam Bishop adam.bis...@ja.net wrote:

 On 8 Apr 2014, at 15:10, Pat Riehecky riehe...@fnal.gov wrote:
 
  The updated package should be available now.

 Brilliant, thanks for update.

 Regards,

 Adam Bishop

   gpg: 0x6609D460

 Janet, the UK's research and education network.



 Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
 not-for-profit company which is registered in England under No. 2881024
 and whose Registered Office is at Lumen House, Library Avenue,
 Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238




-- 
http://stevenmiano.com/ Miano, Steven M.
http://stevenmiano.com

RE: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[peter.chiu]

Hello Pat,

Just tried yum clean all; yum repolist; yum check-update

but not show for the latest OpenSSL fixes.
Is there a particular repository to use?

Regards,
Peter

[root@geant ~]# yum clean all; yum repolist; yum check-update
Loaded plugins: refresh-packagekit, security
Cleaning repos: atrpms elrepo epel rpmforge sl sl-security sl6x sl6x-security
Cleaning up Everything
Loaded plugins: refresh-packagekit, security
atrpms| 
3.5 kB 00:00 
atrpms/primary_db | 
1.7 MB 00:00 
elrepo| 
2.9 kB 00:00 
elrepo/primary_db | 
612 kB 00:00 
epel/metalink | 
 25 kB 00:00 
epel  | 
4.4 kB 00:00 
epel/primary_db   | 
6.0 MB 00:00 
rpmforge  | 
1.9 kB 00:00 
rpmforge/primary_db   | 
2.7 MB 00:00 
sl| 
3.6 kB 00:00 
sl/primary_db | 
4.1 MB 00:00 
sl-security   | 
3.0 kB 00:00 
sl-security/primary_db| 
1.9 MB 00:00 
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.z2:
 [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
 bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
Unknown
Trying other mirror.
http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
 bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
Unknown
Trying other mirror.
ftp://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.b
 2: [Errno -1] Metadata file does not match checksum
Trying other mirror.
sl-security/primary_db| 
1.9 MB 00:00 
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.
 z2: [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
 bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
Unknown
Trying other mirror.
http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
 bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
Unknown
Trying other mirror.
ftp://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.b
 2: [Errno -1] Metadata file does not match checksum
Trying other mirror.
repo idrepo name
   statu 
atrpms Red Hat Enterprise Linux 6.5 - x86_64 - ATrpms   
2,79 
elrepo ELRepo.org Community Enterprise Linux Repository - 
el6 275
epel   Extra Packages for Enterprise Linux 6 - x86_64   
   10,681
rpmforge   RHEL 6.5 - RPMforge.net - dag
4,678
sl Scientific Linux 6.5 - x86_64
6,524
sl-securityScientific Linux 6.5 - x86_64 - security updates 
0
sl6x   Scientific Linux 6x - x86_64 
0
sl6x-security  Scientific Linux 6x - x86_64 - security updates  
0
repolist: 24,954
Loaded plugins: refresh-packagekit, security
sl-security/primary_db| 
1.9 MB 00:00 
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz2:
 [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.
bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
Unknown
Trying other mirror.
http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata

RE: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[peter.chiu]

Thanks, Pat,

From a web browser, I can see the updates openssl-1.0.1e-16.el6_5.7.x86_64.rpm  
under:
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/

So your updates are there,  but my yum installation could not reach them.

I have tried: yum clean expire-cache; yum repolist still reports the errors:

http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz2:
 [Errno -1] Metadata file does not match checksum
Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz2
  [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 Unknown
Trying other mirror.

I did try yum clean metadata, no joy.

I have also tried wget:
[root@geant ~]# wget 
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz
--2014-04-08 16:45:08--  
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz
Resolving wwwcache.rl.ac.uk... 130.246.132.179
Connecting to wwwcache.rl.ac.uk|130.246.132.179|:8080... connected.
Proxy request sent, awaiting response... 404 Not Found
2014-04-08 16:45:08 ERROR 404: Not Found.

Any idea?

Peter


-Original Message-
From: Pat Riehecky [mailto:riehe...@fnal.gov] 
Sent: 08 April 2014 16:05
To: Chiu, Peter (STFC,RAL,RALSP); SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
Subject: Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

H.

I'll run another fsync to make sure everything is down on disk.

Can I have you run:

yum clean expire-cache

And try another yum check-update?

Pat

On 04/08/2014 10:00 AM, peter.c...@stfc.ac.uk wrote:
 Hello Pat,

 Just tried yum clean all; yum repolist; yum check-update

 but not show for the latest OpenSSL fixes.
 Is there a particular repository to use?

 Regards,
 Peter
 
 [root@geant ~]# yum clean all; yum repolist; yum check-update Loaded 
 plugins: refresh-packagekit, security Cleaning repos: atrpms elrepo 
 epel rpmforge sl sl-security sl6x sl6x-security Cleaning up Everything 
 Loaded plugins: refresh-packagekit, security
 atrpms
 | 3.5 kB 00:00
 atrpms/primary_db 
 | 1.7 MB 00:00
 elrepo
 | 2.9 kB 00:00
 elrepo/primary_db 
 | 612 kB 00:00
 epel/metalink 
 |  25 kB 00:00
 epel  
 | 4.4 kB 00:00
 epel/primary_db   
 | 6.0 MB 00:00
 rpmforge  
 | 1.9 kB 00:00
 rpmforge/primary_db   
 | 2.7 MB 00:00
 sl
 | 3.6 kB 00:00
 sl/primary_db 
 | 4.1 MB 00:00
 sl-security   
 | 3.0 kB 00:00
 sl-security/primary_db
 | 1.9 MB 00:00
 http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/sec
 urity/repodata/primary.sqlite.z2: [Errno -1] Metadata file does not match 
 checksum Trying other mirror.
 http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 ftp://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/secu
 rity/repodata/primary.sqlite.b 2: [Errno -1] Metadata file does not match 
 checksum Trying other mirror.
 sl-security/primary_db
 | 1.9 MB 00:00
 http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/sec
 urity/repodata/primary.sqlite. z2: [Errno -1] Metadata file does not match 
 checksum Trying other mirror.
 http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 ftp

RE: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[peter.chiu]

Hello Pat,

With the help by an local admin, this mystery is solved by adding this entry in 
/etc/yum.conf:

http_caching=packages

If I understand this correctly, this entry will enable the software packages to 
be cached by the site web cache, but
not the metadata.

yum update now show the openssl updates.

Thanks.
Regards,
Peter

-Original Message-
From: Chiu, Peter (STFC,RAL,RALSP) 
Sent: 08 April 2014 16:51
To: Pat Riehecky; SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
Cc: Chiu, Peter (STFC,RAL,RALSP)
Subject: RE: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

Thanks, Pat,

From a web browser, I can see the updates openssl-1.0.1e-16.el6_5.7.x86_64.rpm  
under:
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/

So your updates are there,  but my yum installation could not reach them.

I have tried: yum clean expire-cache; yum repolist still reports the errors:

http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz2:
 [Errno -1] Metadata file does not match checksum Trying other mirror.
http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz2
  [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 Unknown
Trying other mirror.

I did try yum clean metadata, no joy.

I have also tried wget:
[root@geant ~]# wget 
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz
--2014-04-08 16:45:08--  
http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite.bz
Resolving wwwcache.rl.ac.uk... 130.246.132.179 Connecting to 
wwwcache.rl.ac.uk|130.246.132.179|:8080... connected.
Proxy request sent, awaiting response... 404 Not Found
2014-04-08 16:45:08 ERROR 404: Not Found.

Any idea?

Peter


-Original Message-
From: Pat Riehecky [mailto:riehe...@fnal.gov]
Sent: 08 April 2014 16:05
To: Chiu, Peter (STFC,RAL,RALSP); SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV
Subject: Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

H.

I'll run another fsync to make sure everything is down on disk.

Can I have you run:

yum clean expire-cache

And try another yum check-update?

Pat

On 04/08/2014 10:00 AM, peter.c...@stfc.ac.uk wrote:
 Hello Pat,

 Just tried yum clean all; yum repolist; yum check-update

 but not show for the latest OpenSSL fixes.
 Is there a particular repository to use?

 Regards,
 Peter
 
 [root@geant ~]# yum clean all; yum repolist; yum check-update Loaded
 plugins: refresh-packagekit, security Cleaning repos: atrpms elrepo 
 epel rpmforge sl sl-security sl6x sl6x-security Cleaning up Everything 
 Loaded plugins: refresh-packagekit, security
 atrpms
 | 3.5 kB 00:00
 atrpms/primary_db 
 | 1.7 MB 00:00
 elrepo
 | 2.9 kB 00:00
 elrepo/primary_db 
 | 612 kB 00:00
 epel/metalink 
 |  25 kB 00:00
 epel  
 | 4.4 kB 00:00
 epel/primary_db   
 | 6.0 MB 00:00
 rpmforge  
 | 1.9 kB 00:00
 rpmforge/primary_db   
 | 2.7 MB 00:00
 sl
 | 3.6 kB 00:00
 sl/primary_db 
 | 4.1 MB 00:00
 sl-security   
 | 3.0 kB 00:00
 sl-security/primary_db
 | 1.9 MB 00:00
 http://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/sec
 urity/repodata/primary.sqlite.z2: [Errno -1] Metadata file does not match 
 checksum Trying other mirror.
 http://ftp1.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 http://ftp2.scientificlinux.org/linux/scientific/6.5/x86_64/updates/security/repodata/primary.sqlite
  bz2: [Errno 14] PYCURL ERROR 22 - The requested URL returned error: 416 
 Unknown
 Trying other mirror.
 ftp://ftp.scientificlinux.org/linux/scientific/6.5/x86_64/updates/secu
 rity/repodata/primary.sqlite.b 2: [Errno -1] Metadata file does not match 
 checksum Trying other mirror.
 sl-security/primary_db
 | 1.9 MB 00:00
 http://ftp.scientificlinux.org/linux

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Kelsey Cummings]

On 4/8/2014 7:10 AM, Pat Riehecky wrote:
 The updated package should be available now.

Pat, can you clarify if this is the Real Fix from the upstream or just a
build with with heartbeats disabled.  I grabbed the Centos quick fix and
pushed it out to all of our SL systems last night in part since their
announcement stated that their package versioning would be overridden
when the upstream released the fix.  Just trying to figure out if I have
to force the new one out or if there's going to be another version bump
soon.

-- 
Kelsey Cummings - k...@corp.sonic.net  sonic.net, inc.
System Architect  2260 Apollo Way
707.522.1000  Santa Rosa, CA 95407

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Jamie Duncan]

CentOS hacked up a fix that disabled the feature prior to Red Hat pushing
the official errata. CentOS replaced the hack ~90 minutes later. FWIW


On Tue, Apr 8, 2014 at 1:28 PM, Kelsey Cummings k...@corp.sonic.net wrote:

 On 4/8/2014 7:10 AM, Pat Riehecky wrote:
  The updated package should be available now.

 Pat, can you clarify if this is the Real Fix from the upstream or just a
 build with with heartbeats disabled.  I grabbed the Centos quick fix and
 pushed it out to all of our SL systems last night in part since their
 announcement stated that their package versioning would be overridden
 when the upstream released the fix.  Just trying to figure out if I have
 to force the new one out or if there's going to be another version bump
 soon.

 --
 Kelsey Cummings - k...@corp.sonic.net  sonic.net, inc.
 System Architect  2260 Apollo Way
 707.522.1000  Santa Rosa, CA 95407




-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Jeffrey Anderson]

Is SL5 vulnerable, and will there be a patch?




On Tue, Apr 8, 2014 at 7:10 AM, Pat Riehecky riehe...@fnal.gov wrote:

 The updated package should be available now.

 Pat


 On 04/08/2014 05:43 AM, Adam Bishop wrote:

 Good Morning,

 I've not seen a fixed OpenSSL package drop into the repo's as of yet.

 Apologies for asking the question, but how quickly will this be packaged
 and made available (i.e. should I start building the package myself)?

 Regards,

 Adam Bishop
 Systems Development Specialist

gpg: 0x6609D460
  t: +44 (0)1235 822 245
   xmpp: ad...@jabber.dev.ja.net

 Janet, the UK's research and education network.


 Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
 not-for-profit company which is registered in England under No. 2881024
 and whose Registered Office is at Lumen House, Library Avenue,
 Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



 --
 Pat Riehecky

 Scientific Linux developer
 http://www.scientificlinux.org/




-- 
--
Jeffrey Anderson| jdander...@lbl.gov
Lawrence Berkeley National Laboratory   |
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-4204

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Jamie Duncan]

The bug was only applicable to RHEL/CentOS/OEL/SL 6.5+
https://access.redhat.com/site/solutions/781793



On Tue, Apr 8, 2014 at 1:36 PM, Jeffrey Anderson jdander...@lbl.gov wrote:

 Is SL5 vulnerable, and will there be a patch?




 On Tue, Apr 8, 2014 at 7:10 AM, Pat Riehecky riehe...@fnal.gov wrote:

 The updated package should be available now.

 Pat


 On 04/08/2014 05:43 AM, Adam Bishop wrote:

 Good Morning,

 I've not seen a fixed OpenSSL package drop into the repo's as of yet.

 Apologies for asking the question, but how quickly will this be packaged
 and made available (i.e. should I start building the package myself)?

 Regards,

 Adam Bishop
 Systems Development Specialist

gpg: 0x6609D460
  t: +44 (0)1235 822 245
   xmpp: ad...@jabber.dev.ja.net

 Janet, the UK's research and education network.


 Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
 not-for-profit company which is registered in England under No. 2881024
 and whose Registered Office is at Lumen House, Library Avenue,
 Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



 --
 Pat Riehecky

 Scientific Linux developer
 http://www.scientificlinux.org/




 --
 --
 Jeffrey Anderson| jdander...@lbl.gov
 Lawrence Berkeley National Laboratory   |
 Office: 50A-5104E   | Mailstop 50A-5101
 Phone: 510 486-4208 | Fax: 510 486-4204




-- 
Thanks,

Jamie Duncan
@jamieeduncan

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Pat Riehecky]

On 04/08/2014 12:28 PM, Kelsey Cummings wrote:

On 4/8/2014 7:10 AM, Pat Riehecky wrote:

The updated package should be available now.

Pat, can you clarify if this is the Real Fix from the upstream or just a
build with with heartbeats disabled.  I grabbed the Centos quick fix and
pushed it out to all of our SL systems last night in part since their
announcement stated that their package versioning would be overridden
when the upstream released the fix.  Just trying to figure out if I have
to force the new one out or if there's going to be another version bump
soon.


The SL package is the official fix from upstream.

Pat

--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Patrick J. LoPresti]

On Tue, Apr 8, 2014 at 10:36 AM, Jeffrey Anderson jdander...@lbl.gov wrote:
 Is SL5 vulnerable, and will there be a patch?

RHEL / CentOS / SL 5.x ship with OpenSSL 0.9.8(x), which is NOT vulnerable.

 - Pat

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[Kelsey Cummings]

On 4/8/2014 10:43 AM, Pat Riehecky wrote:
 The SL package is the official fix from upstream.

Thanks for the clarification Pat.

-- 
Kelsey Cummings - k...@corp.sonic.net  sonic.net, inc.
System Architect  2260 Apollo Way
707.522.1000  Santa Rosa, CA 95407

Re: [SCIENTIFIC-LINUX-USERS] OpenSSL Vulnerability

[P. Larry Nelson]

In case this helps, here's what our campus security folks sent out this morning.

==

Mitigation:
Affected users should upgrade to OpenSSL 1.0.1g. Users unable to
immediately upgrade can alternatively recompile OpenSSL with
- -DOPENSSL_NO_HEARTBEATS.

Quick remote test for potential vulnerability (from linux):
echo |openssl s_client -connect $MYHOST:443 -tlsextdebug 21 \
 | egrep 'heartbeat'

An example response of a potentially vulnerable host would be:
TLS server extension heartbeat (id=15), len=1

Quick local check for vulnerability:
openssl version -a
Any version other than 1.0.1 through 1.0.1f should be safe. In any
1.0.1 version if the -DOPENSSL_NO_HEARTBEATS flag listed in the
compiler flags that should mean you're safe.

Spot check:

openssl version -a| grep -oE '1.0.1[a-g]{1}?|DOPENSSL_NO_HEARTBEATS'

This should give you the version, if it's 1.0.1, and if the
OPENSSL_NO_HEARTBEATS was listed.

Adding to the spot checks above, once you patch with the official
patches from Ubuntu/Debian/RHEL these simple openssl checks will still
show the heartbeat extension enabled but it shouldn't be vulnerable
anymore. If you have access to Qualys for scanning, the QID for
scanning for this vulnerability is 42430.

The http://heartbleed.com/ site recommends re-issuing certificates
in case of prior compromise of existing private keys as there is no
way to differentiate from normal traffic.

We are recommending to our users to do this as well as any credentials
used over the SSL connection, especially in the last few days. The
vulnerability is easily exploitable and a few tests have returned
valid session cookies at the very least. Supposedly the server's
private key can be exposed as well. Passively there's no way to
determine if this is being exploited. I haven't had time to test with
debugging enabled.

===


Jamie Duncan wrote on 4/8/2014 12:44 PM:

The bug was only applicable to RHEL/CentOS/OEL/SL 6.5+
https://access.redhat.com/site/solutions/781793



On Tue, Apr 8, 2014 at 1:36 PM, Jeffrey Anderson jdander...@lbl.gov
mailto:jdander...@lbl.gov wrote:

Is SL5 vulnerable, and will there be a patch?




On Tue, Apr 8, 2014 at 7:10 AM, Pat Riehecky riehe...@fnal.gov
mailto:riehe...@fnal.gov wrote:

The updated package should be available now.

Pat


On 04/08/2014 05:43 AM, Adam Bishop wrote:

Good Morning,

I’ve not seen a fixed OpenSSL package drop into the repo’s as of 
yet.

Apologies for asking the question, but how quickly will this be
packaged and made available (i.e. should I start building the
package myself)?

Regards,

Adam Bishop
Systems Development Specialist

gpg: 0x6609D460
  t: +44 (0)1235 822 245 tel:%2B44%20%280%291235%20822%20245
   xmpp: ad...@jabber.dev.ja.net mailto:ad...@jabber.dev.ja.net

Janet, the UK's research and education network.


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a
not-for-profit company which is registered in England under No. 
2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238



--
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.__org/ http://www.scientificlinux.org/




--
--
Jeffrey Anderson| jdander...@lbl.gov
mailto:jdander...@lbl.gov
Lawrence Berkeley National Laboratory   |
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 tel:510%20486-4208 | Fax: 510
486-4204 tel:510%20486-4204




--
Thanks,

Jamie Duncan
@jamieeduncan




--
P. Larry Nelson (217-244-9855) | Systems/Network Administrator
461 Loomis Lab | High Energy Physics Group
1110 W. Green St., Urbana, IL  | Physics Dept., Univ. of Ill.
MailTo:lnel...@illinois.edu| http://www.roadkill.com/lnelson/
---
 Information without accountability is just noise.  - P.L. Nelson

Re: openssl-1.0.1e-15 - openssl-1.0.1e-16 update?

[Connie Sieh]

On Sat, 7 Dec 2013, Kelsey Cummings wrote:


Looks like RH botched the upgrade to openssl-1.0.1e-15, any chance that
the .16 update could be pushed out ASAP?  The .15 release advertises
support for curves it doesn't support which arguably is quite a bit
worse than not supporting EC in the first place.

https://bugzilla.redhat.com/show_bug.cgi?id=1022468




It was already pushed out.

lftp sldist:/linux/scientific/6.4/x86_64/updates/security ls -ltr

openssl-1.0.1e-15.el6.i686.rpm
openssl-1.0.1e-15.el6.x86_64.rpm
openssl-1.0.1e-16.el6_5.i686.rpm
openssl-1.0.1e-16.el6_5.x86_64.rpm

-Connie Sieh

openssl-1.0.1e-15 - openssl-1.0.1e-16 update?

[Kelsey Cummings]

Looks like RH botched the upgrade to openssl-1.0.1e-15, any chance that 
the .16 update could be pushed out ASAP?  The .15 release advertises 
support for curves it doesn't support which arguably is quite a bit 
worse than not supporting EC in the first place.


https://bugzilla.redhat.com/show_bug.cgi?id=1022468

--
Kelsey Cummings - k...@corp.sonic.net  sonic.net, inc.
System Architect  2260 Apollo Way
707.522.1000  Santa Rosa, CA 95407

Re: OpenSSL 1.x

[Steve Traylen]

On Jan 28, 2010, at 9:15 PM, P. Larry Nelson wrote:

 Hi Troy,
 
 Troy Dawson wrote on 1/28/2010 1:55 PM:
 P. Larry Nelson wrote:
 Hi,
 
 I just received a HIGH criticality email from
 secur...@opensciencegrid.org stating:
 
 Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
 certificate authentication for OSG/VDT.
 
 Not having my ear to the ground vis-a-vis openssl, does anyone know if
 that version is due to be released soon?  Will it come from TUV or
 directly from openssl.org?  (Troy/Connie question)
 
 Right now, we have openssl-0.9.8e-12.el5_4.1.
 
 I suppose the thing to do is to go and edit the yum.cron.excludes on
 all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]
 
 - Larry
 
 
 Scientific Linux, and RHEL are enterprise linux distributions.
 This means that they do *not* just update to the latest versions of 
 packages.  RedHat and SL will *not* just update to the latest version of 
 openssl, just because it was released.
 
 SL 4.0 had openssl 0.9.7a
 SL 4.8 has openssl 0.9.7a
 
 Thas is after five years, we still have the same version of openssl.
 RedHat backports all the security fixes into the 0.9.7a version for 
 RHEL4 (and hense SL4).
 
 SL 5.0 had openssl 0.9.8b
 SL 5.4 has openssl 0.9.8e

Even SL6 won't have openssl 1. It was only added after FC12 that SL6 will 
eventually be based on.
 Steve


 
 After 3 years, SL5 is still at version 0.9.8, although we have moved 
 from b to e.
 I cannot say for 100% certain, because we are not RedHat.  But according 
 to all their policies, goals, statements and past history, they are not 
 going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5)
 
 Troy
 
 Thanks for the info and history lesson.  I didn't know and didn't want
 to assume.  As far as I knew, openssl 1.x might have been a big hairy
 deal security fix that was imminent.
 
 - Larry
 
 -- 
 P. Larry Nelson (217-244-9855) | Systems/Network Administrator
 461 Loomis Lab | High Energy Physics Group
 1110 W. Green St., Urbana, IL  | Physics Dept., Univ. of Ill.
 MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/
 ---
  Information without accountability is just noise.  - P.L. Nelson

OpenSSL 1.x

[P. Larry Nelson]

Hi,

I just received a HIGH criticality email from
secur...@opensciencegrid.org stating:

Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
certificate authentication for OSG/VDT.

Not having my ear to the ground vis-a-vis openssl, does anyone know if
that version is due to be released soon?  Will it come from TUV or
directly from openssl.org?  (Troy/Connie question)

Right now, we have openssl-0.9.8e-12.el5_4.1.

I suppose the thing to do is to go and edit the yum.cron.excludes on
all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]

- Larry

--
P. Larry Nelson (217-244-9855) | Systems/Network Administrator
461 Loomis Lab | High Energy Physics Group
1110 W. Green St., Urbana, IL  | Physics Dept., Univ. of Ill.
MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/
---
 Information without accountability is just noise.  - P.L. Nelson

Re: OpenSSL 1.x

[Doug Olson]

Hi Larry,
I am on the OSG security team.  The message also stated
that no action is required at this point.
If you block openssl updates you might miss important updates
before the v1.x comes out.
It should be that updated OSG software that can handle openssl 1.x will
be out before openssl v1.x comes through the OS distribution channels.
Doug

On 1/28/2010 11:25 AM, P. Larry Nelson wrote:
 Hi,

 I just received a HIGH criticality email from
 secur...@opensciencegrid.org stating:

 Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
 certificate authentication for OSG/VDT.

 Not having my ear to the ground vis-a-vis openssl, does anyone know if
 that version is due to be released soon?  Will it come from TUV or
 directly from openssl.org?  (Troy/Connie question)

 Right now, we have openssl-0.9.8e-12.el5_4.1.

 I suppose the thing to do is to go and edit the yum.cron.excludes on
 all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]

 - Larry




smime.p7s
Description: S/MIME Cryptographic Signature

Re: OpenSSL 1.x

[Troy Dawson]

P. Larry Nelson wrote:

Hi,

I just received a HIGH criticality email from
secur...@opensciencegrid.org stating:

Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
certificate authentication for OSG/VDT.

Not having my ear to the ground vis-a-vis openssl, does anyone know if
that version is due to be released soon?  Will it come from TUV or
directly from openssl.org?  (Troy/Connie question)

Right now, we have openssl-0.9.8e-12.el5_4.1.

I suppose the thing to do is to go and edit the yum.cron.excludes on
all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]

- Larry



Scientific Linux, and RHEL are enterprise linux distributions.
This means that they do *not* just update to the latest versions of 
packages.  RedHat and SL will *not* just update to the latest version of 
openssl, just because it was released.


SL 4.0 had openssl 0.9.7a
SL 4.8 has openssl 0.9.7a

Thas is after five years, we still have the same version of openssl.
RedHat backports all the security fixes into the 0.9.7a version for 
RHEL4 (and hense SL4).


SL 5.0 had openssl 0.9.8b
SL 5.4 has openssl 0.9.8e

After 3 years, SL5 is still at version 0.9.8, although we have moved 
from b to e.
I cannot say for 100% certain, because we are not RedHat.  But according 
to all their policies, goals, statements and past history, they are not 
going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5)


Troy
--
__
Troy Dawson  daw...@fnal.gov  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__

Re: OpenSSL 1.x

[P. Larry Nelson]

Hi Doug,

Doug Olson wrote on 1/28/2010 1:48 PM:

Hi Larry,
I am on the OSG security team.  The message also stated
that no action is required at this point.


The email I got did not say that.  It did say: We have proposals to fix
this issue and you will be notified when we become compatible with OpenSSL.
So it was not clear that we did not need to take action at this point.


If you block openssl updates you might miss important updates
before the v1.x comes out.
It should be that updated OSG software that can handle openssl 1.x will
be out before openssl v1.x comes through the OS distribution channels.
Doug


Thanks for the clarification.  Maybe a followup email to 
g...@opensciencegrid.org
with that explanation might put some nerves at ease.  :-)

- Larry


On 1/28/2010 11:25 AM, P. Larry Nelson wrote:

Hi,

I just received a HIGH criticality email from
secur...@opensciencegrid.org stating:

Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
certificate authentication for OSG/VDT.

Not having my ear to the ground vis-a-vis openssl, does anyone know if
that version is due to be released soon?  Will it come from TUV or
directly from openssl.org?  (Troy/Connie question)

Right now, we have openssl-0.9.8e-12.el5_4.1.

I suppose the thing to do is to go and edit the yum.cron.excludes on
all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]

- Larry






--
P. Larry Nelson (217-244-9855) | Systems/Network Administrator
461 Loomis Lab | High Energy Physics Group
1110 W. Green St., Urbana, IL  | Physics Dept., Univ. of Ill.
MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/
---
 Information without accountability is just noise.  - P.L. Nelson

Re: OpenSSL 1.x

[P. Larry Nelson]

Hi Troy,

Troy Dawson wrote on 1/28/2010 1:55 PM:

P. Larry Nelson wrote:

Hi,

I just received a HIGH criticality email from
secur...@opensciencegrid.org stating:

Do NOT upgrade to OpenSSL 1.x. The new OpenSSL version breaks the
certificate authentication for OSG/VDT.

Not having my ear to the ground vis-a-vis openssl, does anyone know if
that version is due to be released soon?  Will it come from TUV or
directly from openssl.org?  (Troy/Connie question)

Right now, we have openssl-0.9.8e-12.el5_4.1.

I suppose the thing to do is to go and edit the yum.cron.excludes on
all our OSG nodes to block openssl* until this issue is fixed.  [sigh...]

- Larry



Scientific Linux, and RHEL are enterprise linux distributions.
This means that they do *not* just update to the latest versions of 
packages.  RedHat and SL will *not* just update to the latest version of 
openssl, just because it was released.


SL 4.0 had openssl 0.9.7a
SL 4.8 has openssl 0.9.7a

Thas is after five years, we still have the same version of openssl.
RedHat backports all the security fixes into the 0.9.7a version for 
RHEL4 (and hense SL4).


SL 5.0 had openssl 0.9.8b
SL 5.4 has openssl 0.9.8e

After 3 years, SL5 is still at version 0.9.8, although we have moved 
from b to e.
I cannot say for 100% certain, because we are not RedHat.  But according 
to all their policies, goals, statements and past history, they are not 
going to move openssl above version 0.9.8 for RHEL 5 (and hense SL5)


Troy


Thanks for the info and history lesson.  I didn't know and didn't want
to assume.  As far as I knew, openssl 1.x might have been a big hairy
deal security fix that was imminent.

- Larry

--
P. Larry Nelson (217-244-9855) | Systems/Network Administrator
461 Loomis Lab | High Energy Physics Group
1110 W. Green St., Urbana, IL  | Physics Dept., Univ. of Ill.
MailTo:lnel...@uiuc.edu| http://www.roadkill.com/lnelson/
---
 Information without accountability is just noise.  - P.L. Nelson

Re: openssl update in SL4.3 i386

[Troy Dawson]

Jean-Michel Barbet wrote:

Hello,

Someone knows why the package openssl-0.9.7a-43.17.1.i386.rpm
was removed in favor of openssl-0.9.7a-43.17.el4_6.1.i386.rpm
in the SL4.3 repository (date is 22/09/2008) ?

Thanks.

JM


Yes
openssl-0.9.7a-43.17.el4_6.1 is the name that RedHat uses, and is the name that 
is in SLF 4.7.  It is the same rpm in every way, but the name.
When RedHat started putting the %{dist} variable into their rpm names, it took 
us a while to believe that was what they were really going to settle on. 
(There were two other distribution naming schemes RedHat used before this, so 
we thought this one would only last a month or two.)  As a result, we ended up 
with several security updates with poor names.
This repository change was part of the update scheme that we are putting in 
place to allow you to actually update those poorly named rpm's.

Troy
--
__
Troy Dawson  [EMAIL PROTECTED]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__

Re: openssl update in SL4.3 i386

[Jean-Michel Barbet]

Troy Dawson wrote:

openssl-0.9.7a-43.17.el4_6.1 is the name that RedHat uses, and is the 
name that is in SLF 4.7.  It is the same rpm in every way, but the name.
When RedHat started putting the %{dist} variable into their rpm names, 


Thanks very much Troy.

Not sure I understand well but that's probably me.

So the last update for openssl would have this name
openssl-0.9.7a-43.17.el4_6.1 in all SL4.x errata repositories
(sorry I did not check) ?

Which sounds a little bit strange if I run SL4.3 as I do...

I do not understand the motivation for that naming scheme.

Also, I did not see the corresponding advisory on :
https://rhn.redhat.com/errata/rhel4as-errata.html

JM

--

Jean-michel BARBET| Tel: +33 (0)2 51 85 84 86
Laboratoire SUBATECH Nantes France| Fax: +33 (0)2 51 85 84 79
CNRS-IN2P3/Ecole des Mines/Universite | E-Mail: [EMAIL PROTECTED]

Re: openssl update in SL4.3 i386

[Troy Dawson]

Jean-Michel Barbet wrote:

Troy Dawson wrote:


openssl-0.9.7a-43.17.el4_6.1 is the name that RedHat uses, and is the
name that is in SLF 4.7.  It is the same rpm in every way, but the name.
When RedHat started putting the %{dist} variable into their rpm names,


Thanks very much Troy.

Not sure I understand well but that's probably me.

So the last update for openssl would have this name
openssl-0.9.7a-43.17.el4_6.1 in all SL4.x errata repositories
(sorry I did not check) ?

Which sounds a little bit strange if I run SL4.3 as I do...



If you look at many of the security errata, you'll see several with el4_5, 
el4_6, el4_7.



I do not understand the motivation for that naming scheme.



I don't either.  It seems to be on random rpm's.  It doesn't mean that it only 
works on that one distribution. It's sortof for the name of the distribution 
that is the newest when that security errata came out.
It's one of those RedHat things that I have no control over, and I haven't ever 
seen a web page or document stating their reasoning for those names.



Also, I did not see the corresponding advisory on :
https://rhn.redhat.com/errata/rhel4as-errata.html



https://rhn.redhat.com/errata/RHSA-2007-1003.html

This isn't a new errata.  It's just one that I didn't see and fix until now.

Troy
--
__
Troy Dawson  [EMAIL PROTECTED]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__

Re: openssl breaks ldap on SL5.0?

[Matteo Menguzzato]

Jeffrey D Anderson wrote:

On Sunday 25 May 2008 1:21:41 am Jan Iven wrote:

On 05/23/2008 07:07 PM, Jeffrey D Anderson wrote:
[..]


The pam_console_apply signal 13 (broken pipe) is obviously at the core
of the bug, but I don't know enough about pam to really understand what
is going wrong.

I would suggest to  set up a test:
# strace -s 256 -f -o /tmp/somefile -p PID_OF_GETTY_ON_CONSOLE

If you are running nscd, suggest to strace this as well.

Then repeat your login test, and search the tracefile(s) for signal 13,
identify which process held the other end of the pipe, and why it went
away - most likely some subprocess died/segfaulted without leaving other
traces in the logs.

Hope this helps
jan


Thanks for the suggestion.  I ran the strace with both the new, problematic 
nss_ldap, and the old version that works.  I find three places where broken 
pipes result.


Since this is obviously not an SL specific issue, I'm moving my debugging off 
the list.


It looks like this is already reported as 
https://bugzilla.redhat.com/show_bug.cgi?id=447881

No solution yet, though.



We have a similar problem on systems runnig SL5.1 after the update to 
nss_ldap-253-12.el5.i386.


If nscd is not running we have:
- dbus (messagebus service) fails to start and so also hal
- tcsh reports 'broken pipe' for any command issued
- 'su - user' doesn't work
- login from console fails because of the shell.

If ncsd is running:
- dbus still fails to start (because the service starts at 22, before 
ncsd (it starts at 30)) while all other problems seem to disappear.


We have investigated for a while and the problems are reproducible with:
- system just installed,
- ldap configurated with SSL support
- ncsd stopped
everythings works,
- yum update nss_ldap - breaks ldap as described
- start ncsd - fixes the problems as described

I don't think this problem is that already reported as 
https://bugzilla.redhat.com/show_bug.cgi?id=447881

Sorry if it is not an SL specific issue and hope this can help someone else.

thanks,

Matteo

--

Dott. Matteo |  Dip. Fisica - Universita` di Padova  | Ph. +390498277248
Menguzzato   | Via Marzolo, 8 - 35131 Padova - ITALY | Fax +390498277102

Re: openssl breaks ldap on SL5.0?

[Matthias Schroeder]

Hi,

Jeffrey D Anderson wrote:

On Sunday 25 May 2008 1:21:41 am Jan Iven wrote:

On 05/23/2008 07:07 PM, Jeffrey D Anderson wrote:
[..]


The pam_console_apply signal 13 (broken pipe) is obviously at the core
of the bug, but I don't know enough about pam to really understand what
is going wrong.

I would suggest to  set up a test:
# strace -s 256 -f -o /tmp/somefile -p PID_OF_GETTY_ON_CONSOLE

If you are running nscd, suggest to strace this as well.

Then repeat your login test, and search the tracefile(s) for signal 13,
identify which process held the other end of the pipe, and why it went
away - most likely some subprocess died/segfaulted without leaving other
traces in the logs.

Hope this helps
jan


Thanks for the suggestion.  I ran the strace with both the new, problematic 
nss_ldap, and the old version that works.  I find three places where broken 
pipes result.


Since this is obviously not an SL specific issue, I'm moving my debugging off 
the list.


It looks like this is already reported as 
https://bugzilla.redhat.com/show_bug.cgi?id=447881

No solution yet, though.


447881 is marked as a duplicate of 448014 
(https://bugzilla.redhat.com/show_bug.cgi?id=448014), and that one does 
have a proposed patch.


Matthias

Re: openssl breaks ldap on SL5.0?

[Jeffrey D Anderson]

On Sunday 25 May 2008 1:21:41 am Jan Iven wrote:
 On 05/23/2008 07:07 PM, Jeffrey D Anderson wrote:
 [..]

  The pam_console_apply signal 13 (broken pipe) is obviously at the core
  of the bug, but I don't know enough about pam to really understand what
  is going wrong.

 I would suggest to  set up a test:
 # strace -s 256 -f -o /tmp/somefile -p PID_OF_GETTY_ON_CONSOLE

 If you are running nscd, suggest to strace this as well.

 Then repeat your login test, and search the tracefile(s) for signal 13,
 identify which process held the other end of the pipe, and why it went
 away - most likely some subprocess died/segfaulted without leaving other
 traces in the logs.

 Hope this helps
 jan

Thanks for the suggestion.  I ran the strace with both the new, problematic 
nss_ldap, and the old version that works.  I find three places where broken 
pipes result.

Since this is obviously not an SL specific issue, I'm moving my debugging off 
the list.

It looks like this is already reported as 
https://bugzilla.redhat.com/show_bug.cgi?id=447881
No solution yet, though.

-- 
--
Jeffrey Anderson| [EMAIL PROTECTED]
Lawrence Berkeley National Laboratory   | 
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-6808

Re: openssl breaks ldap on SL5.0?

[Jan Iven]

On 05/23/2008 07:07 PM, Jeffrey D Anderson wrote:
[..]


The pam_console_apply signal 13 (broken pipe) is obviously at the core of 
the bug, but I don't know enough about pam to really understand what is going 
wrong.


I would suggest to  set up a test:
# strace -s 256 -f -o /tmp/somefile -p PID_OF_GETTY_ON_CONSOLE

If you are running nscd, suggest to strace this as well.

Then repeat your login test, and search the tracefile(s) for signal 13, 
identify which process held the other end of the pipe, and why it went 
away - most likely some subprocess died/segfaulted without leaving other 
traces in the logs.


Hope this helps
jan

Re: openssl breaks ldap on SL5.0?

[Troy Dawson]

Akemi Yagi wrote:

On Thu, May 22, 2008 at 1:40 PM, Troy Dawson [EMAIL PROTECTED] wrote:

Actually after I sent that and tried to look ... I cannot find any of their
packages from yesterday.  Which is odd.  They usually beat us on pushing
stuff out.
Troy


Because of 5.2?  Updates/fixes for 5.2 might not be released until
CentOS 5.2 is out?

Akemi


I did not think these were updates specifically for Update 2.  Yes, they are 
both security fixes and bug fixes, (which is irritating), but as far as I can 
see, the security fixes apply to all RHEL 5 releases, not just Update 2.

Or have I missed something.
Troy
--
__
Troy Dawson  [EMAIL PROTECTED]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__

Re: openssl breaks ldap on SL5.0?

[Akemi Yagi]

On Fri, May 23, 2008 at 9:45 AM, Troy Dawson [EMAIL PROTECTED] wrote:
 Akemi Yagi wrote:

 On Thu, May 22, 2008 at 1:40 PM, Troy Dawson [EMAIL PROTECTED] wrote:

 Actually after I sent that and tried to look ... I cannot find any of
 their
 packages from yesterday.  Which is odd.  They usually beat us on pushing
 stuff out.
 Troy

 Because of 5.2?  Updates/fixes for 5.2 might not be released until
 CentOS 5.2 is out?

 Akemi

 I did not think these were updates specifically for Update 2.  Yes, they are
 both security fixes and bug fixes, (which is irritating), but as far as I
 can see, the security fixes apply to all RHEL 5 releases, not just Update 2.
 Or have I missed something.
 Troy

I guess only CentOS devs can answer why those packages are being
held... But if those dated May 21 are regarded as zero-day updates,
then they may be released at the time of the CentOS 5.2 release.

Akemi

Re: openssl breaks ldap on SL5.0?

[Jeffrey D Anderson]

On Thursday 22 May 2008 3:45:44 pm you wrote:
 Jeffrey D Anderson wrote:
  On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote:
  On Thursday 22 May 2008 8:20:22 am you wrote:
  On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:
  Hi,
 
   Has anything relating to how ldap uses ssl changed in the last couple
  of days?
 
   In the last day or so our ldap servers (that are queried though SSL
  and the nss_ldap libs) have stopped working properly.
 
  They do part of the job then die with broken pipe signals (as seen by
  running strace on for example su).
 
  This has shown up on both 32 and 64 bit SL5.0 boxes.
 
  We're getting this as well since the update this mornig to
  nss_ldap-253-12.el5.x86_64.
 
  It looks like libnss_ldap.so.2 is now linked again SElinux.  Is that
  part of the problem?
 
  -jkl
 
  I am getting this on SL5.0 and SL5.1.
 
  We use LDAP with TLS for authentication for dozens of workstations, and
  it is totally broken at the moment.
 
  I've done a 'yum clean  yum update' to see if Troy's fixed packages
  from this morning rectify the situation, but still nothing.
 
  The symptoms are that users cannot login.  They type their password at
  KDM or at a text VT, the password apparently is authenticated, but the
  screen flashes and they are returned to the login screen.
  Also, I cannot 'su' to any users.  If I try, as root for example,
  'su SOMEUSER'  I am just brought back to the root bash prompt.  'whoami'
  verifies that I am still root, not su'd to SOMEUSER.
 
  finger and id both successfully lookup the user information, but for
  some reason su, login, KDM, do not successfully log people in.  I've
  verified this on a number of different boxes.  I've also rebooted the
  LDAP server without solving the problem.
 
  Bad for to reply to myself, but I wanted to add that reverting to
  nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is
  definitely some kind of critical bug in the updated nss_ldap.

 Jeffrey,

 My thread is directly related to this bug, I have to change
 ldaps://ldapserver in /etc/ldap.conf file to

 ldap://ldapserver
 ssl start_tls
 tls_checkpeer yes

 then, ldap query via nss_ldap is working again.

 Regards,

Hi:

Thanks for the input, but unfortunately this does not address my problem.

I'm already using TLS rather than ldaps://
Even if that were not the case, nss_ldap should support both methods, as long 
as the server is properly configured.

In my case I believe that the ldap queries are succeeding, since finger and id 
both work.  

Since there are so many different ways a login can fail through X, I tried to 
simplify the situation. 

With the new nss_ldap installed:
`rpm -q nss_ldap` - nss_ldap-253-12.el5

A user attempts to login at a text console on a workstation that authenticates 
via LDAP with TLS.
He enters his username and password.
The screen flashes and the login prompt is redrawn.

Here is the snippet from /var/log/secure relevant to this session:

May 23 09:54:28 theorytest login: pam_unix(login:auth): authentication 
failure; logname= uid=0 euid=0 tty=tty1 ruser= rhost=  user=anderson
May 23 09:54:28 theorytest login: pam_unix(login:session): session opened for 
user anderson by (uid=0)
May 23 09:54:28 theorytest login: pam_console(login:session): 
handler '/sbin/pam_console_apply' caught a signal 13
May 23 09:54:28 theorytest  -- anderson: LOGIN ON tty1 BY anderson

Here is /etc/ldap.conf on this box:

host ldapserver.mydomain
base dc=ldap-auth,dc=gov
scope one
ldap_version 3
pam_filter objectclass=posixaccount
pam_login_attribute uid
pam_member_attribute member
pam_password md5
nss_base_passwd ou=People,dc=ldap-auth,dc=gov
nss_base_shadow ou=People,dc=ldap-auth,dc=gov?one
nss_base_group  ou=Group,dc=ldap-auth,dc=gov
pam_groupdn cn=theoryaccess,ou=Group,dc=ldap-auth,dc=gov
ssl start_tls
TLS_REQCERT allow
TLS_CHECKPEER no
nss_initgroups_ignoreusers root,ldap

With nss_ldap-253-5.el everything works fine.

The pam_console_apply signal 13 (broken pipe) is obviously at the core of 
the bug, but I don't know enough about pam to really understand what is going 
wrong.

Just in case it is relevant, SELinux is turned off on all of these boxes.

-- 
--
Jeffrey Anderson| [EMAIL PROTECTED]
Lawrence Berkeley National Laboratory   | 
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-6808

openssl breaks ldap on SL5.0?

[Faye Gibbins]

Hi,

 Has anything relating to how ldap uses ssl changed in the last couple 
of days?


 In the last day or so our ldap servers (that are queried though SSL 
and the nss_ldap libs) have stopped working properly.


They do part of the job then die with broken pipe signals (as seen by 
running strace on for example su).


This has shown up on both 32 and 64 bit SL5.0 boxes.

Yours
Faye

--
-
Faye Gibbins, Computing Officer (Infrastructure Services)
  GeoS KB; Linux, Unix, Security and Networks.
Communications Technologist   -  IT  Professionals' Forum
Beekeeper  - The Apiary Project, KB -   www.bees.ed.ac.uk
-

  I grabbed at spannungsbogen before I knew I wanted it.

The University of Edinburgh is a charitable body,
registered in Scotland, with registration number SC005336.

Re: openssl breaks ldap on SL5.0?

[Josh Lothian]

On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:
 Hi,

  Has anything relating to how ldap uses ssl changed in the last couple of 
 days?

  In the last day or so our ldap servers (that are queried though SSL and 
 the nss_ldap libs) have stopped working properly.

 They do part of the job then die with broken pipe signals (as seen by 
 running strace on for example su).

 This has shown up on both 32 and 64 bit SL5.0 boxes.

We're getting this as well since the update this mornig to 
nss_ldap-253-12.el5.x86_64.

It looks like libnss_ldap.so.2 is now linked again SElinux.  Is that part of 
the problem?

-jkl

Re: openssl breaks ldap on SL5.0?

[Jeffrey D Anderson]

On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote:
 On Thursday 22 May 2008 8:20:22 am you wrote:
  On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:
   Hi,
  
Has anything relating to how ldap uses ssl changed in the last couple
   of days?
  
In the last day or so our ldap servers (that are queried though SSL
   and the nss_ldap libs) have stopped working properly.
  
   They do part of the job then die with broken pipe signals (as seen by
   running strace on for example su).
  
   This has shown up on both 32 and 64 bit SL5.0 boxes.
 
  We're getting this as well since the update this mornig to
  nss_ldap-253-12.el5.x86_64.
 
  It looks like libnss_ldap.so.2 is now linked again SElinux.  Is that part
  of the problem?
 
  -jkl

 I am getting this on SL5.0 and SL5.1.

 We use LDAP with TLS for authentication for dozens of workstations, and it
 is totally broken at the moment.

 I've done a 'yum clean  yum update' to see if Troy's fixed packages from
 this morning rectify the situation, but still nothing.

 The symptoms are that users cannot login.  They type their password at KDM
 or at a text VT, the password apparently is authenticated, but the screen
 flashes and they are returned to the login screen.
 Also, I cannot 'su' to any users.  If I try, as root for example,
 'su SOMEUSER'  I am just brought back to the root bash prompt.  'whoami'
 verifies that I am still root, not su'd to SOMEUSER.

 finger and id both successfully lookup the user information, but for some
 reason su, login, KDM, do not successfully log people in.  I've verified
 this on a number of different boxes.  I've also rebooted the LDAP server
 without solving the problem.

Bad for to reply to myself, but I wanted to add that reverting to 
nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is 
definitely some kind of critical bug in the updated nss_ldap.


-- 
--
Jeffrey Anderson| [EMAIL PROTECTED]
Lawrence Berkeley National Laboratory   | 
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-6808

Re: openssl breaks ldap on SL5.0?

[Jeffrey D Anderson]

On Thursday 22 May 2008 12:13:15 pm you wrote:
 Jeffrey D Anderson wrote:
  On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote:
  On Thursday 22 May 2008 8:20:22 am you wrote:
  On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:
  Hi,
 
   Has anything relating to how ldap uses ssl changed in the last couple
  of days?
 
   In the last day or so our ldap servers (that are queried though SSL
  and the nss_ldap libs) have stopped working properly.
 
  They do part of the job then die with broken pipe signals (as seen by
  running strace on for example su).
 
  This has shown up on both 32 and 64 bit SL5.0 boxes.
 
  We're getting this as well since the update this mornig to
  nss_ldap-253-12.el5.x86_64.
 
  It looks like libnss_ldap.so.2 is now linked again SElinux.  Is that
  part of the problem?
 
  -jkl
 
  I am getting this on SL5.0 and SL5.1.
 
  We use LDAP with TLS for authentication for dozens of workstations, and
  it is totally broken at the moment.
 
  I've done a 'yum clean  yum update' to see if Troy's fixed packages
  from this morning rectify the situation, but still nothing.
 
  The symptoms are that users cannot login.  They type their password at
  KDM or at a text VT, the password apparently is authenticated, but the
  screen flashes and they are returned to the login screen.
  Also, I cannot 'su' to any users.  If I try, as root for example,
  'su SOMEUSER'  I am just brought back to the root bash prompt.  'whoami'
  verifies that I am still root, not su'd to SOMEUSER.
 
  finger and id both successfully lookup the user information, but for
  some reason su, login, KDM, do not successfully log people in.  I've
  verified this on a number of different boxes.  I've also rebooted the
  LDAP server without solving the problem.
 
  Bad for to reply to myself, but I wanted to add that reverting to
  nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is
  definitely some kind of critical bug in the updated nss_ldap.

 Hi Jeff,
 I have been reading all of this with interest because I hate it when things
 break. Can you try updating nss_ldap using CentOS's rpm, and see if it
 still breaks. I want to see if it is us or RedHat who has the problem.

 Troy

Hi Troy:

I've looked all over and cannot seem to find a CentOS mirror that has the 
recent nss_ldap update -- nss_ldap-253-12.el5
I wonder if they are sitting on it for some reason, or if it has been 
withdrawn?

-- 
--
Jeffrey Anderson| [EMAIL PROTECTED]
Lawrence Berkeley National Laboratory   | 
Office: 50A-5104E   | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-6808

Re: openssl breaks ldap on SL5.0?

[Troy Dawson]

Jeffrey D Anderson wrote:

On Thursday 22 May 2008 12:13:15 pm you wrote:

Jeffrey D Anderson wrote:

On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote:

On Thursday 22 May 2008 8:20:22 am you wrote:

On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote:

Hi,

 Has anything relating to how ldap uses ssl changed in the last couple
of days?

 In the last day or so our ldap servers (that are queried though SSL
and the nss_ldap libs) have stopped working properly.

They do part of the job then die with broken pipe signals (as seen by
running strace on for example su).

This has shown up on both 32 and 64 bit SL5.0 boxes.

We're getting this as well since the update this mornig to
nss_ldap-253-12.el5.x86_64.

It looks like libnss_ldap.so.2 is now linked again SElinux.  Is that
part of the problem?

-jkl

I am getting this on SL5.0 and SL5.1.

We use LDAP with TLS for authentication for dozens of workstations, and
it is totally broken at the moment.

I've done a 'yum clean  yum update' to see if Troy's fixed packages
from this morning rectify the situation, but still nothing.

The symptoms are that users cannot login.  They type their password at
KDM or at a text VT, the password apparently is authenticated, but the
screen flashes and they are returned to the login screen.
Also, I cannot 'su' to any users.  If I try, as root for example,
'su SOMEUSER'  I am just brought back to the root bash prompt.  'whoami'
verifies that I am still root, not su'd to SOMEUSER.

finger and id both successfully lookup the user information, but for
some reason su, login, KDM, do not successfully log people in.  I've
verified this on a number of different boxes.  I've also rebooted the
LDAP server without solving the problem.

Bad for to reply to myself, but I wanted to add that reverting to
nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is
definitely some kind of critical bug in the updated nss_ldap.

Hi Jeff,
I have been reading all of this with interest because I hate it when things
break. Can you try updating nss_ldap using CentOS's rpm, and see if it
still breaks. I want to see if it is us or RedHat who has the problem.

Troy


Hi Troy:

I've looked all over and cannot seem to find a CentOS mirror that has the
recent nss_ldap update -- nss_ldap-253-12.el5
I wonder if they are sitting on it for some reason, or if it has been
withdrawn?



Actually after I sent that and tried to look ... I cannot find any of their 
packages from yesterday.  Which is odd.  They usually beat us on pushing stuff out.

Troy
--
__
Troy Dawson  [EMAIL PROTECTED]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__

Re: openssl patches changelog

[Adrian Sevcenco]

Akemi Yagi wrote:

On Jan 5, 2008 2:24 PM, Adrian Sevcenco [EMAIL PROTECTED] wrote:

Hi! I need to find the changelog of patches that are applied on RHEL
(and/or SL) version of openssl and i dont know how to start the search
(what and where). I am in a situation when it was said to me that a
certain program compiles fine with official openssl but not with the
version from SL 5.
Thank you for help,
Best regards,
Adrian


You can read the upstream errata at:

http://rhn.redhat.com/errata/RHSA-2007-0964.html

Or, download the latest openssl rpm from SL and do a:

rpm --changelog -qp openssl-x.rpm

Hope this helps,

Akemi


Thank you! Its exactly what i need.
Best regards,
Adrian




smime.p7s
Description: S/MIME Cryptographic Signature

openssl patches changelog

[Adrian Sevcenco]

Hi! I need to find the changelog of patches that are applied on RHEL 
(and/or SL) version of openssl and i dont know how to start the search 
(what and where). I am in a situation when it was said to me that a 
certain program compiles fine with official openssl but not with the 
version from SL 5.

Thank you for help,
Best regards,
Adrian



smime.p7s
Description: S/MIME Cryptographic Signature

Re: openssl patches changelog

[Akemi Yagi]

On Jan 5, 2008 2:24 PM, Adrian Sevcenco [EMAIL PROTECTED] wrote:
 Hi! I need to find the changelog of patches that are applied on RHEL
 (and/or SL) version of openssl and i dont know how to start the search
 (what and where). I am in a situation when it was said to me that a
 certain program compiles fine with official openssl but not with the
 version from SL 5.
 Thank you for help,
 Best regards,
 Adrian

You can read the upstream errata at:

http://rhn.redhat.com/errata/RHSA-2007-0964.html

Or, download the latest openssl rpm from SL and do a:

rpm --changelog -qp openssl-x.rpm

Hope this helps,

Akemi