“Dirty Pipe” Linux Flaw Affects a Wide Range of QNAP NAS Devices
The Vulnerability Might be Used to Acquire Elevated Privileges and Control of Vulnerable Systems.
One of Taiwan’s leading manufacturers of network storage systems, QNAP Systems, Inc. specializes in file sharing, virtualization, storage administration, and surveillance.
Network-attached storage (NAS) appliance manufacturer QNAP issued a warning on Monday about a newly reported Linux vulnerability that affects its products and that may be exploited to obtain administrative access and take control of vulnerable computers.
A local privilege escalation vulnerability, also known as “dirty pipe”, has been reported to affect the Linux kernel on QNAP NAS running QTS 5.0.x and QuTS hero h5.0.x. If exploited, this vulnerability allows an unprivileged user to gain administrator privileges and inject malicious code.
The following versions of QTS and QuTS hero are affected:
- QTS 5.0.x on all QNAP x86-based NAS and certain QNAP ARM-based NAS
- QuTS hero h5.0.x on all QNAP x86-based NAS and certain QNAP ARM-based NAS
For a full list of the affected models, please check “Kernel Version 5.10.60” in the following link: https://www.qnap.com/go/release-notes/kernel
QNAP NAS running QTS 4.x are not affected.
QNAP is thoroughly investigating the vulnerability. We will release security updates and provide further information as soon as possible.
Currently there is no mitigation available for this vulnerability. We recommend users to check back and install security updates as soon as they become available.
A spokesperson for the Taiwanese business said that the company is continuing to extensively evaluate its product line for the vulnerability and that there is no QNAP NAS running QTS 4.x that is immune to the Dirty Pipe bug.
The vulnerability, identified as CVE-2022-0847 (CVSS score: 7.8), exists in the Linux kernel and allows an attacker to overwrite arbitrary data into any read-only files on a susceptible computer, resulting in a total takeover of the machine.
In the CM4all hosting environment, all web servers (running our custom open source HTTP server) send UDP multicast datagrams with metadata about each HTTP request. These are received by the log servers running Pond, our custom open source in-memory database. A nightly job splits all access logs of the previous day into one per hosted web site, each compressed with zlib.
Via HTTP, all access logs of a month can be downloaded as a single .gz file. Using a trick (which involves Z_SYNC_FLUSH), we can just concatenate all gzipped daily log files without having to decompress and recompress them, which means this HTTP request consumes nearly no CPU. Memory bandwidth is saved by employing the splice() system call to feed data directly from the hard disk into the HTTP connection, without passing the kernel/userspace boundary (“zero-copy”).
Windows users can’t handle .gz files, but everybody can extract ZIP files. A ZIP file is just a container for .gz files, so we could use the same method to generate ZIP files on-the-fly; all we needed to do was send a ZIP header first, then concatenate all .gz file contents as usual, followed by the central directory (another kind of header).
As The Hackernews reports, the issue has been fixed in Linux versions 5.16.11, 5.15.25, and 5.10.102 as of February 23, 2022.