** This document may change throughout the duration of the event **
For those using OpenSSL 1.0.1 (most recent Unix systems), it is CRITICAL that you patch the openssl library, as well as binaries compiled statically with openssl, as soon as possible.
The attack will allow a remote attacker to read up to 64 kBytes of memory from your system per attack. The attack works against servers as well as against clients. While not all software using SSL necessarily uses the OpenSSL library, much of it does. Any services that use their own OpenSSL libraries will need to be updated independently of the operating system.
A proof of concept exploit has been made available and is being used broadly on the Internet. It can be used to remotely scan for vulnerable systems. While we have not yet detected wide spread use of the exploit, we expect an uptick in attack activity is imminent.
NOTE: This vulnerability has existed in the wild for over 2 years, so it is possible that SSL certificate keys and other data may have been compromised any time during that period.
What should you do first?
Check if your system is vulnerable. "openssl version -a" will return the version information. If your version is 1.0.1, you MAY be vulnerable. Only version 1.0.1g is NOT vulnerable. Other major versions (0.9x, 1.0.0 ...) are NOT VULNERABLE.
Rule of thumb: If you are using OpenSSL, and if you are supporting TLS 1.2 (check ssllabs.com) , then you are vulnerable unless patched.
Campus units making use of the Red Hat Network Satellite (RHNS) service that have access to the RHNS web console can use it to view which of their systems are still affected. In your group, click on the "Errata" tab. Then click ">|" to go to the last page of errata. RHSA-2014:0376 should be at or near the bottom. Under the "Affected Systems" column, you can click on the number to get to the list of your group's systems affected.
- More information on the campus RHNS service can be found here: http://www.utexas.edu/its/rhns/
- The campus satellite console is here: https://satellite.its.utexas.edu/
- RedHat has provided some good information on this vulnerability and determining if your RedHat system is affected here:
As stated in the overview above, it is possible that some software on your system uses its own SSL libraries. This software will need to be patched independently from the system library.
Will a message be sent to the campus about this issue?
Yes. The following content will be shared with the campus as we expect there to be rash of targeted phishing scams following various companies' efforts to have their users change their passwords:
A recent global security event has been unfolding this week (dubbed the
Please note that the University of Texas at Austin has responded swiftly to
the associated vulnerability to significantly reduce risk to systems and
customer information. At this point, the local risks are very well
Many Internet services across the globe did experience significant exposures
and will be asking their users to change passwords in the coming days.
This will unfortunately expose the Internet community to phishing scams
focused on stealing user account passwords.
In the event you receive an e-mail requesting you to change your password
for a given Internet service, we recommend that you avoid clicking any links
provided in the respective e-mail to effect a password change and instead
use an existing bookmark from your browser or manually enter the URL of the
site you are intending to visit.
Do not reply to any e-mails that ask you to confirm your passwords via
e-mail. E-mail is not a secure communications mechanism and no legitimate
company will ask you for your password to be e-mailed back to them.
Please note that there are no plans at this time to require University of
Texas at Austin affiliates to change their passwords. You can, however, change your
password at any time via the UT EID Self-Service Tools.
Feel free to contact the ITS Help Desk at (512) 475-9400 or
firstname.lastname@example.org if you should have any questions or concerns.
You can also search for a September 2013 article from the UT home page,
entitled "Don't Get Hooked - How To Avoid Phishing Scams" to learn more
about what you can do to build your defenses against such attacks.
What other companies have had problems?
Feel free to share the following with your users:
If I am vulnerable, what should I do?
Patch as soon as possible! Ubuntu, CentOS and other linux distributions have patches available. A default installation of Mac OS X 10.9 (Mavericks) is not vulnerable, but if you compiled your own version of OpenSSL or installed it using a ports manager such as Brew, Fink, or MacPorts, then you may be vulnerable. Windows is likely not vulnerable, but if you are running open source software like Apache that uses OpenSSL, then you may be vulnerable.
After patching, be sure to restart the service to ensure the patch has taken effect.
You must also take time to replace your SSL keys and certificates, as it is possible that the exploit was already used against your site. If you are using InCommon for your certificates you can cut new ones via the InCommon portal. Note that even if you generated your encryption keys with a non-vulnerable version of OpenSSL, they can still be leaked if you are currently running a vulnerable version.
If you aren't sure about how to use InCommon for SSL certificates, please see: InCommon Digital Server Certificates. If you have forgotten your InCommon password or been locked out, please contact email@example.com to have your password reset.
Is the ISO going to scan for vulnerable systems?
The ISO is actively scanning the campus network for systems that are vulnerable and will be reaching out to Technical Support Contacts (TSCs) in affected units. Since a proof of concept exploit is in the wild it is critical to quarantine services at this time until they are remediated.
How Can I Tell if Someone is Using the Exploit Against Me?
The ISO is actively monitoring for attacks and will report to vulnerable campus units as needed.
NOTE: that there is no log entry in your web server logs as the exploit happens after the SSL session is established, and before the HTTP request is sent.
nginx, after being patched, logs the following from the PoC exploit:
2014/04/08 12:37:18 [info] 4151#0: *724561 peer closed connection in SSL handshake while SSL handshaking, client: 184.108.40.206, server: 0.0.0.0:8443
Please contact the UT Information Security Office if you have any questions or concerns (firstname.lastname@example.org).