Security: News and Update Notifications

The Security Team posts up-to-the-minute security information important to the university community in the comments section of this page. Most recent posts appear at the top.



  1. Blake Chapman
    Security Analyst
    4:25 pm

    Bash Shellshock vulnerability affects UNIX-based hosts.  Remote command execution possible.

    A critical vulnerability affecting the bash shell on UNIX variants including Linux, Solaris and OS X was announced on September 24th. Code that is executed by a web server (or any other service) which then invokes bash may be vulnerable. Environment variables are able to be established which then execute code with the same permissions as the service which invoked it.

    At this time web applications that are encapsulated by mod_php, mod_perl  and mod_python are not believed to be vulnerable because they do not  export variables. [1]

    This vulnerability is not restricted to hosts that run a web server, but any service which invokes bash, including dhcpd. For example, if you travel with an OS X laptop and connect to a nefarious dhcp server, it has the capability of executing malicious code.

    Major Linux distributions have started to release patches and it is  highly recommended to upgrade to the latest release of bash for your platform.


    The following shell script would demonstrate if bash is vulnerable:

    echo -e '#!/bin/bash\n/bin/true' > /tmp/
    chmod +x /tmp/
    x='() { :;}; echo vulnerable'
    export x
    /bin/rm /tmp/ 

    If it outputs the string "vulnerable," the shell is vulnerable and any  subshell that inherits the environment is vulnerable.


    Apply operating system, vendor or community patches which address the  vulnerability. Some vendors may have issued multiple patches to address this vulnerability.

    In the event the host is a managed appliance, research appropriate knowledge bases for an update or open a support ticket.  It is the opinion of Information Security that the long-term risk will focus on embedded devices.



  2. Blake Chapman
    Security Analyst
    3:39 pm

    A critical vulnerability affecting OpenSSL 1.0.1 (and services that rely on it) was announced on Monday, April 7. A remote attacker is able to read up to 64K of memory per attack. Memory leaked through this method may contain sensitive data including, but not limited to, the SSL private key. This attack works against servers as well as clients. Proof of concept exploits are publicly available. [1]

    Information Security Recommends that system administrators inspect the version of OpenSSL installed and patch if affected. Maintainers of third party software and appliances should contact their vendor or community for an affirmative affected/not-affected statement. We also recommend generating new SSL certificates for any affected systems.

    The minimum safe version of OpenSSL is 1.0.1g. Other major versions (0.9x, 1.0.0) are not vulnerable.

    Only OpenSSL builds with a major version number of 1.0.1 are vulnerable up to build "1.0.1g", regardless of system architecture. At the time of this article, most Linux distributions, including Ubuntu, RHEL and CentOS, have patches available. OS X 10.8 ships with version 0.9.8y which is not affected. It is still worth verifying.

    Be aware that on RHEL / CentOS distributions the version number did not change after patching - it will remain "1.0.1g", but the compile time will show a date of Monday, March 7 or later.

    Any SSL/TLS application may be affected - not just web servers. All encrypted services that run on any port should be inspected.

    Perform the following command on the host to determine if the system is affected:
    $ openssl version -a
    OpenSSL 1.0.1-fips 29 Mar 2010
    built on: Mon Mar 4 22:19:53 UTC 2013
    platform: linux-x86_64

    In this example, OpenSSL is vulnerable judging by the version number and having a build date prior to Monday, March 7.

    After applying patches for OpenSSL, identify running processes which have old libraries mapped and restart:

    $ sudo grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u
    root 1645 0.0 0.0 95084 1044 ? Ss 2013 3:41 sendmail: accepting connections

    If console access is not available, use the Qualys SSL Server Test application to check for vulnerability. Be sure to check the box titled "Do not show the results on the boards".

    Apply operating system, vendor or community patches which address the vulnerability. Then either restart the operating system or restart daemons which use the OpenSSL libraries.
    In the event the host is a managed appliance, research appropriate knowledge bases for an update or open a support ticket.
    In addition, it is recommended that a new private key is generated and CSR generated in order to request a replacement SSL certificate - especially if the services provided are Internet-facing. Instructions are available at: .

    Audit and Forensics
    Apache does not render access logs between SSL connection and beginning of HTTP transmission. Probes will not be evident. However, ITS has attack signatures installed on its firewalls and intrusion detection systems and is actively monitoring the situation.


  3. Don Faulkner
    Chief Information Security Off
    4:05 pm

    New Linux 0-Day Vulnerability: Root Access Possible

    A zero-day exploit in the Linux kernel was identified on May 14th. When successfully exploited, the vulnerability permits a regular shell user to gain ROOT level access. Countermeasures are available while waiting on patches from vendors. The vulnerability affects the following versions, and may affect others as well:

    • Linux kernel 2.6.37-3
    • Linux kernel 2.6.32

    Information Security Recommends that system administrators running kernels near the listed versions test their systems manually, and employ the appropriate countermeasures if vulnerable.


    The vulnerability applies to Linux distributions (RHEL 6 and CentOS 6) running the 2.6.3x x86_64 kernel. 32-bit kernels are not presently vulnerable. Initial reports indicated the vulnerable kernel is 2.6.37-3, but has been successfully tested with 2.6.32. In order to test the vulnerability, establish that you are running a target kernel and compile the proof of concept source code (with the -O2 flag) available at

    $ uname -a
    Linux ... 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
    $ wget
    $ gcc -O2 -o semtex semtex.c
    $ ./semtex
    2.6.37-3.x x86_64
    sd@[redacted] 2010
    -sh-4.1# exit

    Being presented with a root shell prompt indicates vulnerability; if the core dumps the host is not vulnerable.


    The following temporary measure resolves the vulnerability and results in a core dump:

    # sysctl kernel.perf_event_paranoid=2
    kernel.perf_event_paranoid = 2
    $ ./semtex
    semtex: semtex.c:51: sheep: Assertion `!close(fd)' failed.
    Aborted (core dumped)

    The tradeoff to setting kernel.perf_event_paranoid=2 is that a non-superuser cannot take any perf measurements. The perf utility might still be useful to analyze existing records with perf ls, perf report, perf timechart or perf trace. It should be noted that this countermeasure is sufficient for the current unmodified exploit, but does not resolve the issue in general. Subsequent related exploits may appear in the future.

    A more complete mitigation for systems supporting "systemtap" is available from Petr Matousek of the RedHat Security Response Team.

    Audit and Forensics

    If a user attempted to (unsuccessfully) escalate permissions, evidence may be located in syslog, perhaps in /var/log/messages or /var/log/syslog:

    May 14 10:34:30 ... abrtd: Directory 'ccpp-2013-05-14-10:34:30-25755' creation detected
    May 14 10:34:30 ... abrt[25756]: Saved core dump of pid 25755 (/home/pbc/semtex) to /var/spool/abrt/ccpp-2013-05-14-10:34:30-25755 (268763136 bytes)
    May 14 10:34:31 ... abrtd: Executable '/home/pbc/semtex' doesn't belong to any 

    A successful compromise does not log; nor should local logs be relied upon if a user attains superuser status. There is no evidence of logging action in /var/log/audit.


Feel free to leave your questions or comments.

(Login required)