Heap-based buffer overflow in Sudo

All you need to know about sudo and frankly most other pieces of the Linux userspace is that it is undertested. The commit that added this flaw to sudo claims to fix a parser bug but includes no tests. There is no reason for the author, the reviewer (if there even was such a person), or anyone else to believe that the bug existed or was fixed by this change. The pull request that supposedly fixes this CVE also includes no tests. There is <i>no</i> reason anyone should believe this fix is effective or complete, or that it does not introduce new defects. This is the result of people who stubbornly refuse to practice even the most basic good engineering practices, like testing and code review, while at the same time using the industry&#x27;s most dangerous high-level language. As long as this type of thing continues, our tools will remain at a very low level of safety, reliability, and correctness.

Just ten days ago on Hacker News, we had a C programmer claiming that “buffer over-runs are a rare class of bugs, and a class of bugs that are (at least on the heap, and often on the stack) trivial to find and fix” [1].<p>As a bonus, the person who wrote that turned out to have published C code containing multiple exploitable buffer overflows.<p>[1]: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25806533" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=25806533</a>

Every now and then we all get a glimpse, for a flash of a moment, that the house of cards has already collapsed. Too invested in our current systems to face this truth, we just update and forget about it until the next time.

Yet another vindication for one of my long-standing practices. I try to avoid installing sudo at all cost on my systems because all it does is increase the attack surface.<p>Despite this, the wisdom of the crowd is that you should never su to root, for ... reasons? Fat fingering is a thing, but if you can accidentally be in a root terminal without realizing it you have done something horribly wrong.<p>Heck, from a certain point of view if you have someone in the habit of repeatedly typing sudo over and over again then all sudo has really done is open up every single terminal to be a gateway to the nether realm of super user privs. And in this case, more attack surface.

Here is a non .txt format with a great video explanation as well: <a href="https:&#x2F;&#x2F;blog.qualys.com&#x2F;vulnerabilities-research&#x2F;2021&#x2F;01&#x2F;26&#x2F;cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit" rel="nofollow">https:&#x2F;&#x2F;blog.qualys.com&#x2F;vulnerabilities-research&#x2F;2021&#x2F;01&#x2F;26&#x2F;...</a>

Memory safety strikes again, it seems (overflow in a C string due to complex parameter parsing rules).

I&#x27;m curious, is this one implementation of sudo really used everywhere?<p>I was under the impression that different Linux userspaces sometimes implement these common commands differently. Like &quot;ls&quot; sometimes actually being aliased to a bash script, or maybe BSD having one implementation and Ubuntu another. Is that not the case? Is &quot;sudo&quot; not maintained by an entity like gnu, bsd, etc?<p>edit - in other words, I always assumed &quot;sudo&quot; was a highly-dependent system-level tool, not just some useful helper binary that is maintained by one independent person.

&gt; introduced in July 2011 (commit 8255ed69), and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.<p>It looks like this is pretty far reaching. All of my boxes were vulnerable to this before updating today.

How does this story not have a billion upvotes? HN should introduce sticky posts just for this bug and keep it at the top of the homepage for weeks.<p>&gt; exploitable by any local user [...] without authentication<p>&gt; introduced in July 2011 [...] in their default configuration<p>&gt; full root privileges

Developers: your moment has come at last to humble your local system administrator for wearing those &quot;I read your emails&quot; t-shirts. This is as day zero as day zero gets. Red Hat and Debian published their security announcements just two hours ago at the exact same moment this was posted on Hacker News. It would have been more responsible to keep something this bad under wraps a bit longer. Because all the people who still use things like cpanel virtual hosting are at risk.

&gt; introduced in July 2011 (commit 8255ed69), and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.<p>It looks like this is pretty far reaching. All of my boxes were vulnerable to this before updating today.

Is it normal for a security issue of this magnitude to have a 12 day notification period for everyone? That seems... short.

At this point, can somebody recommend linux security best practices on desktop? I already have two user accounts one for important stuff and other for unimportant stuff. I prefer to use sandboxed apps, but flatpaks don&#x27;t look well maintained compared to official repositories, and often unofficial. Firejail seems quite controversial due to use of UserNS? What do veterans in security recommend for sandboxing of user apps?

Never knew sudo had a site (<a href="https:&#x2F;&#x2F;sudo.ws" rel="nofollow">https:&#x2F;&#x2F;sudo.ws</a>).<p>Never knew it had a mascot, if you could call it so... I will never unsee it. Nightmare fuel at it&#x27;s finest.

Qualys is great! Love their vulnerability reports.<p>Just want to echo other praise here for doas. It&#x27;s fantastic, most likely does everything you need it to do, and is secure. Install it and see for yourself!

sudo built with ASLR doesn&#x27;t make a difference?<p>NM:<p>- we can defeat ASLR by partially overwriting the function pointer getenv_fn (which points to the function sudoers_hook_getenv() in the shared library sudoers.so); and luckily, the beginning of sudoers.so contains a call to execve() (or execv()):

&quot;rewrite sudo in Rust&quot; in 3,2...

From 2017, there are at least 5 discovered security issues in sudo[1]. It seems a bit too untested for something running in root and interacting with all users.<p>[1]: <a href="https:&#x2F;&#x2F;www.sudo.ws&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.sudo.ws&#x2F;</a>

I was trying to find results for PAM in CVEDB so I could go <i>&quot;Everybody&#x27;s freaking out about sudo but PAM ain&#x27;t no saint neither (<a href="https:&#x2F;&#x2F;cve.mitre.org&#x2F;cgi-bin&#x2F;cvekey.cgi?keyword=PAM" rel="nofollow">https:&#x2F;&#x2F;cve.mitre.org&#x2F;cgi-bin&#x2F;cvekey.cgi?keyword=PAM</a>)&quot;</i>, but sudo&#x27;s vulns seemed to really stack up last year: <a href="https:&#x2F;&#x2F;cve.mitre.org&#x2F;cgi-bin&#x2F;cvekey.cgi?keyword=sudo" rel="nofollow">https:&#x2F;&#x2F;cve.mitre.org&#x2F;cgi-bin&#x2F;cvekey.cgi?keyword=sudo</a>

Wow, this looks bad. Many VPS and shared hosting providers would be directly shellable with this. Even exploits that got you onto a web server with a limited web shell = full root. Alternatively, sites that already have shells from previous script kiddies can be escalated to root too. Not that I would advocate any of this ^_^ But there are many places where local access is required and you rely on permissions to work properly. A program as important as sudo (or wide spread) is not the kind of place you want to see a vuln this severe

Please let this be a reference to Count Zero and the loa of the matrix :(

I don&#x27;t find bug reports for this in either Debian or Ubuntu bug tracking systems. When do these get entered?

Shouldn&#x27;t this affect macOS?

One of those programs that you should not install unless you really need them.

What variant of `doas` do people run as an alternative? I see Duncaen&#x2F;OpenDoas, slicer69&#x2F;doas, multiplexd&#x2F;doas on GitHub. None seem super widely used as judged by watches&#x2F;stars&#x2F;forks.

Any idea why did they referenced Baron Samedi? <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Baron_Samedi" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Baron_Samedi</a>

In case no one gets the pun: <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Baron_Samedi" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Baron_Samedi</a>

Are e.g. AWS, GCP, and Digital Ocean releasing emergency patches? I can&#x27;t find info.

Any list somewhere which provides a list of affected OSs or at least how to check?

There&#x27;s a reason my boxen have no sudo installed.

If little sudo has buffer overflows, what can we expect in the huge codebases of DBus and systemd?

Is there a project to rewrite all of these Linux system utilities in forbid(unsafe) Rust?

‹insert &quot;oh shit&quot; here›

this doesnt surprise me<p>a few years ago I found a flaw in sshd. because it was impacting a Linux PAM login&#x2F;auth module I was writing in C. my module <i>should</i> have worked. but it wasnt. because of sshd. it blew me away, given how important that server is. luckily, others must have complained too, and it ended up being fixed in a newer sshd release. but the fact that it made it into a release in the first place, impacting PAM, was scary<p>on a not-totally-unrelated note, that was also the last C project I wrote, and since then I fell in love with Go and Rust. for systems code, for me, theres no going back. C is scary given the modern threat ecosystem and whats at stake