Heap Overflow in Sudo: The Struggling Escape Artist (CVE-2021-3156)

January 27, 2021

Yesterday, the Qualys Research Team disclosed a heap overflow vulnerability in sudo, CVE-2021-3156, called “Baron Samedit” (in a show of delightful wordplay with the Haitian Vodou spirit). It allows a local user to become root and gain control over the target system.

Why it’s cool: Sudo, short for “superuser do”, is a default utility in most Linux distros — making the vulnerability footprint extensive. As its longer name suggests, sudo’s primary function is to let users execute commands as root (a superuser) or as another user (who might be super in spirit, but not in privilege level). So, this attack involves illegitimately escalating privileges leveraging the legitimate privilege escalation utility.

The vuln was present for about a decade (introduced in July 2011), which increases the likelihood that it was exploited in the wild at some point. Specifically, sudo versions 1.8.2 through 1.8.31p2 and 1.9.0 through 1.9.5p1 are affected.

Double trouble: There are two vulnerabilities that align to facilitate privilege escalation. One involves incorrectly handling escaped characters and the other incorrectly handling memory when parsing command line arguments. Both require use of the -s or -i flag, which passes the sudo command to a shell with root privileges for execution.

The great escape: If there are special characters in the command line argument, they need to be marked with a backslash — what’s known as “escaping” a character — so the computer knows to read them literally rather than as their representative meanings. 

For instance, an exclamation point is the logical symbol for “not” (used to exclude values), which means the computer will get pretty confused by the command sudo make me a sandwich!. However, escaping the exclamation point will tell the computer to interpret it literally instead: sudo make me a sandwich\!.

Digging deeper: The problem in CVE-2021-3156 is that if the command-line argument ends in \ (an unescaped backslash character) — such as sudo make me a sandwich \ — then the computer reads beyond that backslash (expecting another character after it) and copies that out-of-bounds character into the buffer. This allows the attacker to overwrite memory with whatever size buffer they desire.

In theory, the attacker shouldn’t be able to overwrite the heap with arbitrary data this way. Running Sudo with -i or -s automatically escapes special characters with a backslash — so it will escape the backslash with another backslash like \\. Then, sudoers — sudo’s security policy plugin that specifies which users can run which commands on the systems — unescapes any special characters before the sudoers policy is evaluated.

However, Sudoedit was a struggling escape artist, possessing the second vulnerability in which the -s or -i options resulted in a bypass of the automatic character escaping process. Its command line parsing code didn’t check whether a command was actually being run, which was a necessary trigger for character escaping. Thus, Sudoedit left a lonely single backslash ripe for exploitation by local attackers.

Yes, but: Attackers need to exploit another vulnerability or otherwise gain local access on the target system before they can exploit Baron Samedit. The presence of a sudoers policy — located in /etc/sudoers — is also required to exploit this vulnerability. Because the sudoers file enables finer-grained access policies, it is likely present by default in most distros. The security giveth, and the security taketh away.

And also: Containerization matters here. Except in cases of lift-and-shift, purpose-built containers are unlikely to have sudo available. Even if sudo is available and attackers gain root access in the container, they will need to break out of it in order to gain root access to the underlying host itself. User namespace separation — which admittedly can be a pain, and isn’t the default deployment mode for most orchestrators — makes this attack even less of a concern.

Patchy patchy: The newest version of sudo (1.9.5p2) includes a patch for the vuln. Ubuntu quickly released patched versions of its distros and Red Hat also fixed the issue in RHEL 6 – 8 along with a partial mitigation. As of this post’s publication time, Debian Buster (the latest stable version) is still vulnerable, although it’s test and unstable releases are fixed. Fedora has not yet released any guidance.

The bottom line: You may want to lightly tap the panic button if you know you have sudo enabled with sudoers policies on the distros in your prod infra. Normally, a local vuln isn’t a reason to panic, but the fact that this bug goes back a decade and is a default utility in most distros makes it a somewhat special case. 

We recommend upgrading sudo as soon as you can and applying patches as they become available. You can also disallow the use of -s and -i, which are required to exploit this vulnerability. Capsule8 customers can reach out to their rep to learn more about detecting this activity.