The command “sudo” is an essential part of Vax, Unix, and Linux operating systems. It’s so intrinsic to how SysAdmins work, many consider “sudo” to be a built-in command and are shocked when they encounter a system where it’s missing. Since its introduction in 1980, it’s been used millions of times a day, on millions of systems, by millions of users around the world. And yet, despite this constant use across a vast range of computers, a security vulnerability was discovered just this year (2021). This was no small bug either—the exploit allowed any user to gain root (administrator) access without a password. What’s more, the vulnerability had been, in the words of one researcher, “hiding in plain sight for nearly 10 years”
1.
I point this out NOT to glory in someone else’s discomfort; nor to tech-shame the maintainers of sudo for somehow missing something obvious or essential; nor to engage in a bit of the
“tu quoque” logical fallacy. I bring it up to underscore my next point:
The only perfect code is the code not yet written.
THAT code—which exists only in the mind of the developer who conceived it—runs immaculately, free from the slings and arrows of outrageous fortune and unpredictable users. Once the code tumbles out of the developer’s brain, through their fingers, and into their IDE, however, the only certain thing about it is there will be flaws—whether they’re noticed immediately or not.
Heavy use will not necessarily expose a program’s inherent flaws or weaknesses (sudo is proof enough of that). Unit tests, QA, bug bounties, and the rest all serve a purpose, but they still aren’t going to catch everything. This is the unavoidable truth of tech. To be fair, it’s the unavoidable truth of every man-made object I can think of, from hair dryers to coffee cups to chests of drawers.
It’s instructive to look at the timeline of CVE-2021-3156, (the sudo vulnerability). According to Qualsys, who first discovered the issue
2:
- 2021-01-13: Advisory sent to Todd.Miller@sudo
- 2021-01-19: Advisory and patches sent to distros@openwall
- 2021-01-26: Coordinated Release Date (6:00 PM UTC)
You’ll notice there’s no mention of when the bug was found. This is not only normal, it’s part of “responsible vulnerability disclosure” – the common practice among IT security researchers. After validating a potential exploit, it’s standard to follow these steps:
- First and foremost, inform the owner of the code, whether they’re a vendor, individual contributor, or group.
- Part of this notification includes allowing time for the owner to verify the exploit on their own systems.
- Next, work with the owner to develop a fix for the vulnerability, whether it’s a patch, hotfix, or a new full version.
- During the time the patch is being developed, the owner of the code may also choose to notify end users.
- But just as legitimately, the owner may choose to keep the information under wraps, so as not to risk leaking the news to the public and thereby exposing users to additional risk before a solution can be implemented.
- Once the solution is developed, it’s shared in the security community.
- And finally, both the vulnerability and the fix is announced to the user community at large.
That’s how it
usually goes. That’s how it’s
supposed to go. That’s how it went with sudo. The public only found out about the vulnerability on January 26, 2021, as part of the announcement that they should immediately upgrade their systems to the latest version of sudo, which addressed the issue and removed the risk.
As I said earlier, no software is perfect. Even decades-old code used by millions can still have flaws, bugs, and vulnerabilities. In this day and age, when Microsoft’s “Patch Tuesday” is just another part of the IT landscape, nobody should be shocked when an app they’re using—whether on a mobile phone, laptop, corporate server, or cloud-based SaaS—has a bug.
When IT professionals consider the solutions used in their orbit (personally, by the team or department, or in the enterprise) the correct response to the announcement of an issue isn’t to go looking to switch to another toolset. If we did that, we wouldn’t be using the same software for more than three months at a time. No, the correct response is first to understand how quickly and comprehensively the vendor addressed the issue; and second to see how the vendor uses the experience to adapt, grow, and improve.
(1)
https://www.beyondtrust.com/blog/entry/understanding-sudo-vulnerability-cve-2021-3156-and-how-privilege-management-for-unix-linux-can-protect-your-enterprise
(2)
https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit 
