A race condition flaw has been fixed in the mainline Linux kernel, but some Red Hat, Canonical, and Debian distributions don't yet have patches
A local privilege escalation flaw has been fixed in the Linux kernel, but several upstream distributions have yet to release updates. Administrators should plan on mitigating the vulnerability on Linux servers and workstations themselves and monitor the distributions for their update plans.
The race condition flaw in the n_hdlc driver (drivers/tty/n_hdlc.c) in the Linux kernel through 4.10.1 (CVE-2017-2636) can lead to a double-free error in n_hdlc_release() when accessing the n_hdlc.tbuf list, said Alexander Popov, a researcher at Russia-based Positive Technologies who found and reported the flaw. A local, unprivileged user able to set the HDLC line discipline on the tty device could exploit this flaw and gain increased privileges over the affected system or cause a denial-of-service condition.
[ Also on InfoWorld: 19 open source GitHub projects for security pros. | Discover how to secure your systems with InfoWorld's Security Report newsletter. ] The vulnerability, which got a base score of 7.8 under Common Vulnerability Scoring System (CVSS) 3.0, doesn't need to be triggered by any user interaction, and the attack complexity is considered low. Exploiting this flaw does not require specialized hardware or peripherals to be attacked in the targeted system. Under CVSS, the vulnerability is considered High severity because of its impact.
The patch was sent to the Linux kernel mainline on Feb. 28, and the new version of the kernel was released March 7. All versions of the Linux kernel up to 4.10.1 are considered vulnerable.
The vulnerability would affect Linux servers and workstations, as well as virtual machines, but not most containers. "Due to the ioctl settings on Docker, this shouldn't be executable from within a container," said Patrick Carey of open source security company Black Duck Software. "Obviously if you have access to the container host, all bets are off."
Waiting for the patches
Red Hat has rated the issue as Important severity and promised to fix the bug in future updates. The issue affects the realtime-kernel package shipped with Red Hat Enterprise MRG 2, the kernel-rt package shipped with Red Hat Enterprise Linux 7, and the kernel packages in Red Hat Enterprise Linux 5/6/7. It does not affect the Linux kernel packages shipped with Red Hat Enterprise Linux 5.
Canonical has rated the issue as High severity as all Ubuntu versions are affected, and the company has released the fixes for the main Linux kernel for Ubuntu Linux 12.04 LTS (Precise Pangolin), 14.04 LTS (Trust Tahr), Ubuntu 16.04 LTS (Xenial Xerus), and Ubuntu 16.10 (Yakket Yak). Updates for Ubuntu Core 15.04 and Ubuntu Linux 17.04 (Zesty Zapus) are still pending. Canonical has updated some kernel packages, such as linux-ti-omap4 package (for 12.04 LTS) and linux-gke (16.04 LTS), but doesn't plan to update others, such as linux-maguro package (for 14.04 LTS). Fixes still need to be incorporated for such packages as linux-lts-vivid for 14.04 LTS and linux-rapi2 for 17.04. Administrators should reference Canonical's complete list to determine the state of their kernel and distribution.
Various Debian Linux 6.0 packages for sparc, s/390, powerpc, mips, ia-64, ua-32, arm, amd64, the Linux kernel in Debian wheezy 3.2.78-1, jessie 3.16.39-1, and stretch 4.9.13-1 are vulnerable. The most recent versions of Debian jessie, 3.16.39-1+deb8u2, and wheezy, 3.2.86-1, already have the fixed kernel modules.
What to do in the meantime
Until the updated kernel is available, Linux administrators can mitigate the vulnerability by manually preventing the kernel from being loaded. The n_hdlc kernel module is usually automatically loaded whenever an application attempts to use the HDLC line discipline from userspace, but it can be blocked using systemwide modprob rules. Running # echo "install n_hdlc /bin/true" >> /etc/modprobe.d/disable-n_hdlc.conf as root will prevent accidental or intentional loading of the module. The system will need to be restarted if n_hdlc modules have already been loaded.
"Red Hat Product security believe this method is a robust method to prevent accidental loading of the module, even by privileged users," Red Hat wrote in its own advisory of the flaw.
Any Linux distribution that has CONFIG_N_HDLC=m in the kernel configuration likely is affected as it uses the vulnerable driver.
Popov discovered the bug while investigating a suspicious kernel crash from using an unsupervised Linux system call fuzzing tool, syzkaller. The vulnerability has to do with the fact that n_hdlc uses self-made singly linked lists for data buffers and an n_hdlc.tbuf pointer to resend buffers after an error. If the data buffer can't be sent for whatever reason, then the address is saved in n_hdlc.tbuf. The buffer is the first thing sent the next time hdlc_send_frames() is called. The flux_tx_queue() and hdlc_send_frames() can put the buffer into tx_free_buf_list twice, causing the double-free error.
The bug appears to be nearly eight years old, as it was introduced in 2009 when code was added to bring buffer flushing to n_hdlc. It was fixed by using a standard kernel linked list protected a spinlock and by removing the pointer, Popov said. In case of transmission error, the data buffer gets placed after the head of the tx_bf_list instead.
The vulnerability exists in a widely used open source component -- in this case, the actual Linux kernel -- across all major versions and distributions. But "the only way most Linux users will know about it is if they are actively monitoring the NVD [National Vulnerability Database] or a security feed from their Linux provider," Carey said. It's highly likely that thousands of systems will remain unpatched and vulnerable, especially when running Linux on nonstandard hardware such as the Raspberry Pi.
"If organizations aren't making a concerted effort to track and manage their open source, they're leaving the door wide open for exploit," Carey said.