GHOST glibc Security Alert January 2015

Summary

Epicor has been made aware of a critical vulnerability in the glibc library, which has been assigned CVE-2015-0235 and is commonly referred to as ‘GHOST’. All versions of glibc shipped with all variants of Red Hat Enterprise Linux are affected.

GHOST is a ‘buffer overflow’ bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker that is able to make an application call to either of these functions to execute arbitrary code with the permissions of the user running the application.

The gethostbyname() function calls are used for DNS resolving, which is a very common event. To exploit this vulnerability, an attacker must trigger a buffer overflow by supplying an invalid hostname argument to an application that performs a DNS resolution.

Checking Vulnerability

The easiest way to check for the vulnerability is to run the the Red Hat Access Lab’s “glibc (GHOST) Detector” script:

curl -s http://kb.eclipseinc.com/repo/GHOST-test.sh | bash

If the server is vulnerable, you will see output similar to:

Installed glibc version(s)
- glibc-2.5-42.i686: vulnerable
- glibc-2.5-42.x86_64: vulnerable

This system is vulnerable to CVE-2015-0235. <https://access.redhat.com/security/cve/CVE-2015-0235>
Please refer to <https://access.redhat.com/articles/1332213> for remediation steps

If the server is not vulnerable, you will see output similar to:

Installed glibc version(s)
- glibc-2.5-123.el5_11.1.x86_64: not vulnerable
- glibc-2.5-123.el5_11.1.i686: not vulnerable

Resolution

Update RHEL to patch the affected libraries:

yum -y update glibc nscd

Double-check that the patches have been applied by running the detection script again:

curl -s http://kb.eclipseinc.com/repo/GHOST-test.sh | bash

Reboot the server to finish applying the patches:

reboot

Troubleshooting

If you receive an error when attempting to run yum, it could be because your Red Hat subscription has expired. In this case, we’ve setup a package repository for you, which you can use by running the following commands:

curl -s -o /etc/yum.repos.d/eclipse.repo http://kb.eclipseinc.com/repo/eclipse.repo
yum -y update glibc nscd

If you receive an error similar to “Public key for glibc-headers-2.5-123.el5_11.1.x86_64.rpm is not installed”, then it means your Red Hat software is very much out of date, and you’ll need to first update some other packages:

curl -s -o /usr/share/rhn/RHNS-CA-CERT http://kb.eclipseinc.com/repo/RHNS-CA-CERT
curl -s -o /etc/yum.repos.d/eclipse.repo http://kb.eclipseinc.com/repo/eclipse.repo
yum --nogpgcheck -y update rhn*
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
yum -y update glibc nscd

Frequently Asked Questions

Q: I installed the patch, and now the script says my server is “not vulnerable”. Do I still need to reboot my server?
A: Yes.

Format RDX Cartridges for Linux

To format an RDX (e.g. Dell RD1000) drive cartridge for Linux for use with Eclipse backups:

Identify the drive’s device name (e.g. /dev/sdc) using the following command:

lsscsi

After you’ve identified the proper device, format the partition (e.g. /dev/sdc1):

CAUTION: This will destroy all data on the specified partition, so make sure you’ve identified the correct partition before proceeding.

mkfs -t ext4 -v -L RD1000 /dev/sdX1

Mount the drive:

mount /mnt/rd1000

Create the rsync directory:

mkdir -p /mnt/rd1000/rsync

The drive cartridge is now ready for use.

POODLE SSLv3 Security Alert October 2014

Summary

Epicor has been keeping apprised of a vulnerability in the SSL 3.0 protocol, which has been assigned CVE-2014-3566. All implementations of SSL 3.0 are affected.

POODLE stands for Padding Oracle On Downgraded Legacy Encryption. This vulnerability allows a man-in-the-middle attacker to decrypt ciphertext using a padding oracle side-channel attack. POODLE affects older standards of encryption, specifically Secure Socket Layer (SSL) version 3.0. It does not affect the newer encryption mechanism known as Transport Layer Security (TLS).

Because it’s a vulnerability in the protocol, not a bug in the implementation, there is no “patch,” so SSLv3 should be disabled in all client and server software.

Epicor’s Response

There are functions of the Eclipse server software that initiate HTTPS connections to external servers (e.g. for credit card processing). Those connections previously allowed SSLv3, so we have updated the code to explicitly require TLS connections. The patch (DNV616) can be applied manually, or it will be included by default in the customer’s next point upgrade.

We have also reviewed the Eclipse application server and confirmed that SSLv3 is already disabled in the release, which uses TLS by default.

Recommended Customer Actions

We recommend that customers request the patch or a point upgrade to a release of Eclipse with SSLv3 client functionality disabled.

We also recommend that any customers running external web servers (e.g. web commerce, mobile) disable SSLv3 on IIS using Microsoft’s “fix it” tool.

FAQ

Q. How can I verify that my Solar application server (or any other secure web service) is not vulnerable?
A. Run the command below:

openssl s_client -connect HOSTNAMEORIPADDRESS:PORT -ssl3

For example, the following output, run against a the Solar application server running on the local server, shows that the service is not vulnerable:

[root@rs6k ~]# openssl s_client -connect localhost:2443 -ssl3
CONNECTED(00000003)
25211:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:284:

Bash Security Alert September 2014

Summary

A security vulnerability in the bash shell, the command-line shell used by the Linux operating system, could leave systems running those operating systems open to exploitation by specially crafted attacks.

Epicor’s Response

We have reviewed the Eclipse software and verified that none of our products are directly affected by this vulnerability.

Customer Action

While the Eclipse software is not directly affected by this vulnerability, we highly recommend that our customers take the following actions to safeguard their servers:

  1. Install the updated bash software update as soon as possible, using the command
    yum update bash
  2. Do not make the Linux server directly accessible on the Internet. Use a VPN to remotely access the server.
  3. Continue to install Red Hat software updates on a regular basis.

For more information, please read the following articles on Red Hat’s website:

FAQ

Q: Are web services that indirectly access the Linux database server affected?

A. No. Eclipse doesn’t use the affected Apache web server on Linux. Web services that use fastcgi (e.g. WOE, Web Integration) that run on the Windows IGATE server access the UniVerse SOCKET server, which isn’t affected. Web services that access JBoss on the database server (e.g. POD, JM) aren’t affected.

Q. The yum update tool is not working. Can I manually install the updated bash software?

A. Yes, you may use one of the alternative mirrors below:

For servers running RHEL 5:

rpm -Uvh http://f.cl.ly/items/0v0V430R0b3a3j3M4344/bash-3.2-33.el5_11.4.x86_64.rpm

For servers running RHEL 6:

rpm -Uvh http://f.cl.ly/items/3p083T2f1j3b191x423d/bash-4.1.2-15.el6_5.2.x86_64.rpm

Q. How do I test to see if my server is vulnerable?

A. Run this command:

env x='() { :;}; echo vulnerable' bash -c 'echo this is a test'

If you see the word “vulnerable” echoed back, then your system needs to be updated. If you only see “this is a test,” then your system has been patched.

Upgrading from RHEL 5 to 6

Here are answers to some common questions regarding upgrades from RHEL 5 to 6:

When I update the software using “yum,” will it upgrade me to the newest version?

It will only update you to the latest “minor” version (e.g. 5.9 to 5.10). It will not upgrade you to a new major version (e.g. 5.9 to 6.5).

Why would I want to upgrade to RHEL 6?

If you are on RHEL 5, you may stay on RHEL 5. Red Hat will provide technical support and updates for RHEL 5 until 3/31/17, and UniVerse will support it through 11.2.

If you are on RHEL 5, but you are moving to a new server, we recommend that you use the opportunity to migrate to RHEL 6 on the new server.

Can I perform an “in place” upgrade from RHEL 5 to 6?

No. Here’s Red Hat’s policy on “in place” upgrades:

Red Hat does not support in-place upgrades between any major versions of Red Hat Enterprise Linux. A major version is denoted by a whole number version change. For example, Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6.5 are both major versions of Red Hat Enterprise Linux.
In-place upgrades across major releases do not preserve all system settings, services or custom configurations. Consequently, Red Hat strongly recommends fresh installations when upgrading from one major version to another.

The recommended procedure is to perform a clean installation of RHEL 6, followed by clean installations of the Eclipse software packages (e.g. UniVerse, VSI-FAX), and finally restore the OS configuration data (e.g. users, passwords, printers, email relay settings) and database.

For more information, see these Red Hat articles:

I need to upgrade to RHEL 6 for another reason. Can Eclipse help?

If you need to upgrade from RHEL 5 to 6 for some reason (e.g. backup software requires RHEL 6), and you are not moving to a new server, the Eclipse team can help with the upgrade process. Please contact your account manager for more information.