July 30, 2014

Two machines attacked within the FreeBSD.org cluster

(LiveHacking.Com) – Just over a week ago the FreeBSD team detected an intrusion on two of its machines in the FreeBSD.org cluster. As a result the affected machines were taken offline while they investigated.  Also as a precaution, most of the remaining infrastructure machines were also taken offline. The investigation has revealed that the compromise occurred due to a leaked SSH key. No vulnerability or code exploit within FreeBSD was found. However the most alarming thing is that the attack and subsequent  compromise may have occurred as early as the 19th September 2012.

FreeBSD is divided into two segments: the “base” which includes the kernel; the system libraries; the compiler; and the core command-line tools and daemons, and the “packages” which are the third-party components distributed as part of the overall FreeBSD system. According to the security advisory published by the FreeBSD team, “no part of the base FreeBSD system has been put at risk. At no point has the intruder modified any part of the FreeBSD base system software in any way. However, the attacker had access sufficient to potentially allow the compromise of third-party packages.”

The investigation has concluded that although the attacker had sufficient access to compromise the third-party packages, no evidence has been found that any packages were modified. But the FreeBSD team is taking an extremely conservative view and is working on the assumption that packages generated and distributed between the 19th September and 11th November 2012 could theoretically have been modified.

Who’s affected?

You have no reason to worry if:

  • you are running a system that has had no third-party packages installed or updated on it between the 19th September and 11th November 2012.
  • you reply in the Source, Ports and Documentation Subversion repositories to make updates.
  • you use the freebsd-update binary upgrade mechanism (it uses an entirely separate infrastructure).

However for everyone else the FreeBSD project cannot cannot guarantee the integrity of any packages available for installation between 19th September 2012 and 11th November 2012, or of any ports compiled from trees obtained via any means other than through svn.freebsd.org or one of its mirrors. Those affect should re-install any machines from scratch, using trusted sources.

The package set built for the upcoming 9.1-RELEASE has been deleted, and will be rebuilt from source before 9.1 is released. With regards to the cluster machines, all suspect machines are being either reinstalled, retired, or thoroughly audited before being brought back online.

NVIDIA fixes root privilege escalation in its Linux drivers

(LiveHacking.com) — Over a month ago an anonymous coder sent a small C program to Dave Airlie, who maintains the Direct Rendering Manager (DRM) subsystem in the Linux kernel, that allows an attacker to gain root access to a Linux machine by exploiting a vulnerability in NVIDIA’s Linux drivers.

The exploit works by using a vulnerability in the /dev/nvidiao device which allows the VGA window to be moved around until it can read and write to somewhere useful in physical RAM. Then the exploit performs a root privilege escalation by writing directly to kernel memory.

Over a month passed since information about the vulnerability was submitted to NVIDIA and the graphics company has not responded. As a result Airlie has made the exploit public.

“I was given this anonymously, it has been sent to nvidia over a month ago with no reply or advisory and the original author wishes to remain anonymous but would like to have the exploit published at this time, so I said I’d post it for them,” wrote Dave Airlie in a post to a security mailing list.

NVIDIA has now released version 304.32 of its drivers for Linux, FreeBSD and Solaris. The updated driver contains a hotfix to block access to the registers involved in this attack. At the same time NVIDIA has also blocked access to some other registers which it identified as being susceptible to a similar type of attack.

The 295.71 driver is available for download at the NVIDIA FTP site:

32-bit Linux: ftp://download.nvidia.com/XFree86/Linux-x86/295.71/
64-bit Linux: ftp://download.nvidia.com/XFree86/Linux-x86_64/295.71/

Solaris: ftp://download.nvidia.com/solaris/295.71/

32-bit FreeBSD: ftp://download.nvidia.com/XFree86/FreeBSD-x86/295.71/
64-bit FreeBSD: ftp://download.nvidia.com/XFree86/FreeBSD-x86_64/295.71/

The 304.32 driver is also available for download at the NVIDIA FTP site:

32-bit Linux: ftp://download.nvidia.com/XFree86/Linux-x86/304.32/
64-bit Linux: ftp://download.nvidia.com/XFree86/Linux-x86_64/304.32/

Solaris: ftp://download.nvidia.com/solaris/304.32/

32-bit FreeBSD: ftp://download.nvidia.com/XFree86/FreeBSD-x86/304.32/
64-bit FreeBSD: ftp://download.nvidia.com/XFree86/FreeBSD-x86_64/304.32/

Details about the updated driver and the patches are available at: http://nvidia.custhelp.com/app/answers/detail/a_id/3140

System privilege escalation vulnerability found in XEN on 64-bit Intel hardware

(LiveHacking.Com) – Rafal Wojtczuk of Bromium, Inc. has found a new vulnerability that could possibility be exploited for local privilege escalation. The bug in several different operating systems and Hypevisors, like the XEN virtualization software, affects systems using 64-bit Intel CPU hardware. To exploit the vulnerability an attacker needs to create a special stack frame which will be executed by the kernel of the host operating system after a general protection fault. The problem is that the general protection fault will be handled before the stack switch, which means the exception handler will be run in the kernel of the host operating system using the specially created stack frame, in short – a privilege escalation.

The error only exhibts itself on Intel 64-bit CPUs. AMD CPUs are not affected. Also the vulnerability seems to exist only in the XEN hypervisor (or its variants). VMware is not vulnerable. According to Xen Security Advisory 7, the result of a successful exploitation is that administrators of guest OSes can gain control of the host OS.

Modern operating systems implement a rings model of security, where privileged operations are performed in RING 0 (the kernel). Most applications run in RING 3 and request access to RING 0 by making system calls. The calls put the CPU into the required privilege level and passes control to the kernel. By using the combination of a special stack frame and a general protection fault the attackers force the system to run their code in RING 0 rather than RING 3.

Microsoft released a patch for Windows a few days ago as part of June’s Patch Tuesday. According to Microsoft the fix changes the way that the Windows User Mode Scheduler handles a particular system request and the way that Windows manages BIOS ROM.

Vendor specific information on this vulnerability have been published by XenFreeBSD and Microsoft. Linux vendor Red Hat has also published two security advisories: RHSA-2012:0720-1 and RHSA-2012:0721-1.

On some operating systems, like FreeBSD, running the 32-bit variant of the OS on a 64 bit capable CPUs means the operating systems is not vulnerable.

ISC’s DHCP Client Could Allow Remote Code Execution

The Internet Systems Consortium (ISC), a non-profit company which develops software for the infrastructure of the Internet (like BIND and DHCP), has released details of a new remote code execution vulnerability present in its dhclient software.

dhclient is ISC’s DHCP client and can be found on most Linux systems as well as other Unix-like platforms such as FreeBSD. When a machine is configured to use DHCP (Dynamic Host Configuration Protocol) the dhclient broadcasts a request asking for hostname and IP configuration information. A DHCP server will then reply with the corresponding information.

The problem is that dhclient does not strip or escape certain shell meta-characters in responses from the dhcp server (like hostname) before passing the responses on to dhclient-script. Depending on the script and OS, this can result in execution of exploit code on the client. dhclient versions 3.0.x to 4.2.x are affected.

ISC have issued new versions of the software: 3.1-ESV-R1, 4.1-ESV-R2 or 4.2.1-P1 which can be downloaded from here. No patch is available for 4.0.x as it has reached its end of life. Anyone running 4.1.x should upgrade to 4.1-ESV-R2.

If you don’t want to rebuild the software yourself you should consider the immediate workarounds given below or wait until your Linux distribution issues an update.

Immediate workarounds

On SUSE systems, it is possible to disable hostname update by setting DHCLIENT_SET_HOSTNAME=”no” in /etc/sysconfig/network/dhcp. Other systems may add following line to dhclient-script at the beginning of the set_hostname() function:

new_host_name=${new_host_name//[^-.a-zA-Z0-9]/}