Various vulnerability notices and updates

There is a vulnerability in the libsdp package which is used to enablean
application to communicate over the Infiniband SDP protocol instead of
ordinary TCP:

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

Sites that use infiniband will want to look at the measures in the
notification above.

---

Updated openssl packages that fix one security issue are now available for
Red Hat Enterprise Linux 6.

https://www.redhat.com/security/data/cve/CVE-2010-3864.html
https://rhn.redhat.com/errata/RHSA-2010-0888.html

---

Updated systemtap packages that fix two security issues are now available
for Red Hat Enterprise Linux 5 and 6.

https://rhn.redhat.com/errata/RHSA-2010-0894.html

---

There is a security vulnerability in PGP Desktop versions 10.0.3 and
earlier, as well as the upcoming 10.1 release. This vulnerability
may allow someone to spoof emails signed by the OSG security team.
For OSG users who use this version there is a knowledge base page,
as well as remediation steps at:

https://pgp.custhelp.com/app/answers/detail/a_id/2290

GNU libc vulnerability

The OSG Security Team wants you to be aware of a vulnerability impacting the glibc library.

Introduction
============

Tavis Ormandy recently released information about a vulnerability in GNU libc, complete with an exploit that on many systems can give any local user root privileges. (For full details, see the link below in the References section.)

This vulnerability has been labelled CVE-2010-3847, and is present on many Linux distributions, including RHEL/CentOS/SL 5 (but *not* RHEL 3 and 4 and their derivatives). Vendor patches are not yet available.

Details
=======

As far as is known, the vulnerability can only be exploited if users can write to a file system that contains binaries with suid root permissions. (Since it is necessary for the attacker to create a hard link to a suid root binary.)

This is, for instance, the case if /bin is located on the same filesystem as /tmp (or any other user writable location, like /var/tmp, /home, /var/lib/texmf, and so on). This is unfortunately a common configuration.

Mitigation
==========

To make it impossible to make the required hard link, directories containing suid/sgid binaries can be made to appear to as separate file systems by doing

mount -o bind /sbin /sbin

for each such directory.

Please note that these commands must be re-run whenever the system is rebooted, for example by adding them to a suitable init script.

A baseline list of directories with suid/sgid binaries on a typical RHEL 5 system is:

/bin
/sbin
/usr/bin
/usr/libexec
/usr/lpp
/usr/sbin

You should check for any additional site specific locations using a command like

find / -type f \( -perm /u+s -o -perm /g+s \)

that will list all files with suid/sgid permissions.


Recommendations
===============

Apply the mitigation method above for all relevant locations.

You may wish to suspend user logins and job submission until these steps have been taken; please refer to your local site policy.

Apply vendor updates as soon as they become available.

References
==========

[3]http://seclists.org/fulldisclosure/2010/Oct/257

The majority of this announcement was put together by Nuno Dias - EGI CSIRT

Linux Kernel "snd_ctl_new()" Integer Overflow Vulnerability SA41650

From Secunia:
http://secunia.com/advisories/41650/
Description
A vulnerability has been reported in the Linux Kernel, which can be exploited by malicious, local users to cause a DoS (Denial of Service) or potentially gain escalated privileges.

The vulnerability is caused due to an integer overflow error when allocating memory within the "snd_ctl_new()" function in sound/core/control.c, which can be exploited to cause a heap-based buffer overflow.

Criticality: Less Critical

OSG Recommendation:
If you think your systems may have this vulnerability you can consider removing or limiting access to the sound (or audio) subsystem.

Kernel updates for CVE-2010-3081

The OSG security team announced last week an important kernel vulnerabilitythat affected 64 bit systems (announcement OSG-SEC-2010-09-16). Most of the vendors have now come out with patched kernels and the OSG security team is encouraging all sites to update any kernels that are currently affected.

Here are the links or instructions to the patched kernels for the following OS versions:

RedHat
https://rhn.redhat.com/errata/RHSA-2010-0704.html

Fedora
https://admin.fedoraproject.org/updates/search/CVE-2010-3081

Scientific Linux
Dear SLC5 x86_64 (64 bit) platform users.
We have released in production a new SLC5 kernel addressing the locally exploitable security issue CVE-2010-3081. This kernel 2.6.18-194.11.4.el5 superseeds the "hotfix" kernel 2.6.18-194.11.3.el5.cve20103081 released last Thursday.

In order to protect your system please apply urgently following update by running as root:

# yum install kernel

and if your system is an Xen virtual machine or hypervisor also run:

# yum install kernel-xen

and reboot your system for the update to take effect.


Ubuntu
https://lists.ubuntu.com/archives/ubuntu-security-announce/2010-September/001159.html

SUSE
http://lists.opensuse.org/opensuse-security-announce/2010-09/msg00004.html

RedHat xorg-x11-server important security vulnerability

An important vulnerability regarding RedHat xorg-x11-server has been reported. The vulnerability could lead to a root-level compromise. RedHat has classified the severity level as "important" and detailed information is available at https://rhn.redhat.com/errata/RHSA-2010-0382.html
Although the vulnerability is not likely to affect the grid environment, we recommend all site admins to apply the patch on their systems as soon as possible for their site's protection.

Make sure your service is getting updates of CA certificates

We have received information about storage services which had failed data transfers (FTS and srm services) because the CA certificates package has not been updated and the old CA package has an expired CA and not the new CA certificate that replaced the expired one.
The best way to update the CA certificates is using vdt-update-certs. Read about this and other important CA certificates information at https://twiki.grid.iu.edu/bin/view/Security/CADistribution.

CRL update problems

As you probably know, CRLs are a vital part of the x509 security model; they are the only way CAs can invalidate compromised, or otherwise revoked certificates. Every time a user credential is presented to Grid-aware software, the appropriate CRL is checked to make sure the credential was not revoked.

CRLs has expiration dates like everything else in the x509 world. A side effect of this is that if a CRL is not updated locally (by being downloaded from the CA site) before it expires, all credentials from that CA will be treated as invalid. So sites must download fresh updates frequently; the recommended policy in OSG is to do it once every 6 hours. The tool fetch-crl is used for the task.

Several OSG site admins have notified us that fetch-crl occasionally fails to download a CRL one or more CAs, and has asked up (the security team) for guidance on what to do in those events.

Ideally, we would like to debug each and every such event and make sure it is just a transient error, but given the distributed nature of the Grid this will not scale. OSG has hundreds of sites and there are hundreds of CAs, and problem is combinatorial. Unless such errors are very rare events, we need an alternative approach.

One possibility would be for OSG to centrally serve the CRLs from all the supported CAs; this would allow us to more easily track problems since we can separately debug CA and site problems, thus going from a quadratical to a linear problem. Of course we still want to allow sites to go directly to the CAs for the CRLs if they want, for example when they are supporting a CA that is not part of the official OSG CA distribution; but we offer only limited support in such cases anyhow.

However, the above solution is likely to create its own set of problems (still to be determined), so before we start any design and implementation effort we would like to know how important is to solve this for sites.

Right now we don't even have clear statistics on how often sites have problems with their CRLs, nor if the problems are due to specific CAs. So input from sites is highly desirable.

Changes in new version of OpenSSL

This is an informational notice only, there is no current action that is needed to be taken for OSG sites.

This is a notice that OpenSSL 1.x is changing the way they name the certificate files in the trust anchor store (the certificate files for grid middleware are usually stored in the "/etc/grid-security/certificates/" directory).

Traditionally OpenSSL was using a MD5 hash for naming the certificate files (which would look something like 9ff26ea4.0). The new version has moved to using a SHA1 hash to create the certificate names. Installing the new openSSL version on a machine would mean that openSSL will NOT find the certificates installed in the trust stores due to different naming used by IGTF distribution. In short, the authentication on the installed machine will stop working. IGTF distribution has proposed changes which will fix this issue and a new distribution will be released once these changes have been completed.

If you have other concerns related to this, please let us know. We are also investigating how other pieces of our distribution may be affected by this change.