DROWN SSL Security Alert March 2016


Epicor has been keeping apprised of a vulnerability in the SSL 2.0 protocol, CVE-2016-0800, also known as DROWN, which stands for Decrypting RSA using Obsolete andWeakened eNcryption and is a Man-in-the-Middle (MITM) attack against servers running TLS for secure communications. The issue is actually quite tricky to exploit by itself, but made easier on servers that are not up to date with some previous year-old OpenSSL security updates. Red Hat has a vulnerability article in the Customer Portal which explains the technical attack and the dependencies in more detail.

Recommended Customer Actions

Red Hat recommends that customers immediately apply available updates to remediate the issue. Rebooting the system after updating is the safest way to ensure all affected services use the updated ssl library.

Microsoft IIS versions 7.0 and above should have SSLv2 disabled by default. If you are running an older version of IIS, you will need to disable insecure protocols following these instructions from Microsoft.


Q. How can I check whether or not my Linux server is vulnerable?
A. Log into your Linux server and run the command below:

curl -Ls http://bit.ly/checkDROWN | sh

For example, the following output, run against an Eclipse Linux server shows that the software needs to be updated:

[root@eclipsetest ~]# curl -Ls http://bit.ly/checkDROWN | sh

WARNING: The installed version of openssl (openssl-1.0.1e-16.el6_5.14) is vulnerable to both general and special DROWN attack and should be upgraded!
See https://access.redhat.com/security/vulnerabilities/drown for more information.

The installed version of openssl-libs (package openssl-libs is not installed) is not vulnerable to DROWN.

Q. How can I check whether my external web server (e.g. WOE, mobile) is vulnerable?
A. Use this tool.

Fix Dell Cannot retrieve repository metadata Error


When running yum update on a RHEL 5 system, the following error is shown:

http://linux.dell.com/repo/hardware/latest/platform_independent/rh50_64/repodata/repomd.xml: [Errno 14] HTTP Error 404: Not Found
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: dell-omsa-indep. Please verify its path and try again


Dell discontinued support for RHEL 5 in the latest version of their yum repo, which is enabled by default, but they keep the old copies online.


Point the Dell repo at an older version:

sed -i 's/latest/Linux_Repository_14.12.00/g' /etc/yum.repos.d/dell-omsa-repository.repo

You may now re-run yum.

Solar Application Blocked by Security Settings


When launching Solar, you receive an “Application Blocked by Security Settings” error message.

Application Blocked


Add the Eclipse server’s IP address or hostname to Java’s security exception site list by following these steps:

Open the Java control panel:

Launch the Windows Start menu
Click on Programs
Find the Java program listing
Click Configure Java to launch the Java Control Panel ((If you can’t find the control panel, please see this Java support page for more information.))

In the “Java Control Panel” window that appears, select the “Security” tab.

If there is a “Exception Site List” section in this window, click on the “Edit Site List…” button. ((If there is no “Exception Site List” section in this window, slide the “Security Level” indicator from “High” down to “Medium” and click the “OK” button.))

Java Control Panel Security Tab

In the “Exception Site List” window:

Click the “Add” button
Enter the Eclipse server’s web start address, including port (e.g.
Click the “OK” button
Confirm by clicking “OK” once again.

Java Exception Site List

Finally, click the “OK” button to exit the “Java Control Panel”.

Launch Solar again.


For reference, here is a video showing the error and workaround:



Q: Why did this error appear suddenly?
A: The certificate that was previously used to sign the Solar code expired on 10/26/15, so if you are using an older version of Solar that was signed by the expired certificate, Java’s default security settings will now block it from running.

Q: Is there a way to add an exception to the site list without using the GUI (i.e. for automating the changes across many computers)?
A: Yes, you may add the same entry to the text file located at %APPDATA%\..\LocalLow\Sun\Java\Deployment\security\exception.sites. For more information, see Java’s documentation. For information on deploying these changes via group policy, see this article for an example.

Formscape CPU Affinity

On servers with more than 2 CPU cores, Formscape may fail to license and start properly until you restrict the service process to run on 2 or fewer CPUs.

To set the CPU affinity:

  • Open the Windows services window (Start -> Run -> services.msc)
  • Right-click on the “Eclipse Forms” service and select Properties
  • Select the General tab
  • Click on the Stop button to halt the FormScape service
  • In the Start Parameters field, enter: –a “0 1”
  • Click on the Start button and then on the OK button.

GHOST glibc Security Alert January 2015


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


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:



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.