Badlock Security Alert

What is Badlock?
Please see this article from Red Hat for an overview of the vulnerability.

How can I test my system to see if I’m vulnerable?
Run this script:

curl -s http://kb.eclipseinc.com/files/badlock-test.sh | sh

It will generate a report similar to the following if your system is vulnerable:

WARNING: The installed version of samba server (4.2.3-12.el7_2) is vulnerable to BADLOCK and should be upgraded! It is also enabled and/or running. Please update the package and restart the service.
See https://access.redhat.com/articles/2243351 and https://access.redhat.com/security/vulnerabilities/badlock for more information.

How do I patch my system?
Install Red Hat updates. If you don’t want to install all of the updates, you can optionally install only the samba updates:

yum update samba*
service smb restart

DROWN SSL Security Alert March 2016

Summary

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.

FAQ

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.

Configure Postfix Relay with Google Apps

 

Recommended Configuration (Google Apps paid accounts)

If you are using a paid version of Google Apps, and you would like to avoid Google rewriting the sender, you must first configure your Google Apps account for IP-based relay by following these instructions to allow relay from your server’s public IP address by any email addresses.

After Google Apps has been configured to allow relay from your server’s public IP address, you may configure postfix with:

relayhost = [smtp-relay.gmail.com]

Alternative Configuration (Google Apps free accounts, Gmail)

The correct SMTP server configuration for the free version of Google Apps and Gmail is:

relayhost = [smtp.gmail.com]:587

Please note that Google will automatically rewrite the sender (FROM) address to match whichever account is used for SMTP authentication (i.e. if you authenticate with eclipse@domain.com, all emails will appear to be sent from that address, regardless of which from address is specified in Eclipse). This is a limitation enforced on Google’s end, so there is no way around this on the Linux server side, other than to use a paid version of Google Apps (please see above) or use a mail relay service like SendGrid.

Fix Dell Cannot retrieve repository metadata Error

Symptom

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

Cause

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.

Fix

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

Problem

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

Application Blocked

Workaround

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. http://172.22.211.10:2080/).
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.

Screencast

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

[youtube=https://www.youtube.com/watch?v=pnPqgwzuObE&rel=0&showinfo=0]

FAQ

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.