Expert Reacted On ‘Dirty Pipe’ Linux Vulnerability

It has been reported that a cybersecurity researcher released the details of a Linux vulnerability that allows an attacker to overwrite data in arbitrary read-only files. The vulnerability — CVE-2022-0847 — was discovered by Max Kellermann in April 2021, but it took another few months for him to figure out what was actually happening. Kellermann explained that the vulnerability affects Linux Kernel 5.8 and later versions but was fixed in Linux 5.16.11, 5.15.25 and 5.10.102.

Experts Comments

March 09, 2022
Tim Mackey
Principal Security Strategist, Synopsys CyRC (Cybersecurity Research Center)
Synopsys

The Dirty Pipe vulnerability illustrates an inherent risk with all software development – code changes. In this case, identification of the core issue took several months. Not because there were delays in resolving the issue, but rather that for the impacted user, other issues held higher priority. Fixing a bug with intermittent occurrence would be treated in much the same manner within any development shop.

The root cause of the Dirty Pipe vulnerability results from a practice known as

.....Read More

The Dirty Pipe vulnerability illustrates an inherent risk with all software development – code changes. In this case, identification of the core issue took several months. Not because there were delays in resolving the issue, but rather that for the impacted user, other issues held higher priority. Fixing a bug with intermittent occurrence would be treated in much the same manner within any development shop.

The root cause of the Dirty Pipe vulnerability results from a practice known as “refactoring.” Refactoring in software development occurs quite often and represents how the software implementation should change to reflect new requirements. If the refactoring process doesn’t account for why the original code behaved the way it did, then it’s entirely possible that the new implementation will have a bug – potentially one that might be latent for years. Solving for this requires discipline during the design phase for all code wherein behavioural assumptions are fully documented and then consulted when the code changes. After all, it’s unreasonable to expect any developer to remember why they implement code a specific way years after having done so.

  Read Less
What do you think of the topic? Do you agree with expert(s) or share your expert opinion below.
Be part of our growing Information Security Expert Community (1000+), please register here.