Vulnerabilities

New Sudo flaw used to root on any standard Linux installation

April 28, 2021 by Pedro Tavares

A recent vulnerability tracked as CVE-2021-3156 in Sudo, a powerful utility used on any standard Linux installation, could allow unprivileged local users to gain root privileges on a vulnerable host. This flaw needs no authentication and is based on a heap buffer overflow in Sudo legacy versions 1.8.2 to 1.8.31p2 and all stable versions (1.9.0 to 1.9.5p1).

The vulnerability is also known as “Baron Samedit.” It was discovered in January 2021 by security auditing firm Qualys and fixed at the end of that month with the release v1.9.5p2.

The researchers developed three exploits for the vulnerability and were able to obtain full root privileges on Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27) and Fedora 33 (Sudo 1.9.2). Other operating systems are likely exploitable, the researchers said.

Digging into the details

Through a simple explanation provided by the Sudo team, the Baron Samedit flaw can be exploited by an attacker who has gained access to a low-privileged account to obtain root privileges, even if the account is not listed in the Sudoers group.

Is a local user required to exploit the vulnerability? Yes, however, this user does not need to be a privileged user or be a part of the Sudoers list. For example, even the “nobody” account can exploit the issue.

Figure 1: Snippet of code about the vulnerability.

As a proof of concept of the vulnerability, the Qualys team provided a video demonstrating the exploitation of the vulnerability through a user with low privileges in the system and without being listed in the Sudoers group.

CVE-2021-3156: Heap-Based Buffer Overflow in Sudo (Baron Samedit) from Qualys, Inc. on Vimeo.

Although two other Sudo security holes have been reported in the past two years, the vulnerability disclosed is now considered the most dangerous of the three.

The two previous bugs, CVE-2019-14287 (known as the -1 UID bug) and CVE-2019-18634 (known as the pwfeedback bug), were hard to exploit because they required complex and nonstandard Sudo setups.

This new vulnerability is extremely critical, as it affects all devices on which Sudo is installed where the “/etc/sudoers” file is present (most standard Linux installations).

Figure 2: Successful exploitation of Baron Samedit flaw.

This flaw was introduced in commit 8255ed69 by Sudo in July 2011, effectively affecting all versions of Sudo released in the last 10 years.

Figure 3: commit 8255ed69 where CVE-2021-3156 was introduced with a new commit.

Fixing the flaw

Sudo developers patched the vulnerability in Sudo version 1.9.5p2 at the same time that Qualys made its findings publicly available.

To test if your system is vulnerable, you have to log in as a non-root user and run the “sudoedit -s /” command. Vulnerable systems will throw an error starting with “sudoedit:”. Patched ones will display an error starting with “usage:”.

The flaw was not mitigated on several cloud services, such as Amazon EC2 Linux instances, CentOS and RHEL releases.

System admins who use Sudo to delegate root privileges to their users should immediately upgrade to Sudo 1.9.5p2 or later as soon as possible.

CVE overview and bug confirmation

Some steps can be used to verify if the flaw exists:

  • Start Sudo as sudoedit and add the “-s” option. The out-of-bounds characters copied to the heap-based buffer “user_args” when the command line ends with a backslash will be sized. Because it is not included, it causes a heap-based buffer overflow.
normal_user@localhost:~$ sudoedit -s ‘\’ `perl -e ‘print “A” x 65536’`

malloc(): corrupted top size

Aborted

———–

Check if the vulnerability is supported

According to Qualys, run “sudoedit -s /”:

  • If there is a vulnerability (for Debian bullseye), you will get an error starting with “sudo edit:” as shown below.
normal_user@testing:~$ sudoedit -s /

sudoedit: /: not a regular file

  • If there is no vulnerability (for Debian sid), an error starting with “usage:” will appear as shown below.
normal_user@sid:~$ sudoedit -s /

usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-D directory] [-g group] [-h host] [-p prompt] [-R di

 

If the vulnerability exists, it can be exploited using a PoC available on GitHub to escalate privileges from a normal user to root by abusing a heap buffer overflow condition.

Figure 4: Public exploit available on GitHub.

A present threat

At the moment, several servers available on the internet are still vulnerable to this flaw. This constitutes a critical scenario as a normal user without high privileges on the machine could abuse it to get root and control over the machine and potentially use that machine to pivot into the internal network.

During the last weeks, many exploits were published for several variants of Ubuntu (20.04 – Sudo 1.8.31), Debian 10 (Sudo 1.8.27) and Fedora 33 (Sudo 1.9.2). Other operating systems and distributions are also likely to be exploitable and present an open door from the attacker. Baron Samedit is one of the rare Sudo flaws that can be weaponized to perform impacting attacks, in comparison to the previous two bugs disclosed.

In this way, updating Sudo to the latest version is a mandatory step to prevent scenarios of this type that could be exploited in the wild.

 

Sources

CVE-2021-3156, Qualys

Buffer overflow in command line unescaping, Sudo

Sudo, GitHub

Posted: April 28, 2021
Articles Author
Pedro Tavares
View Profile

Pedro Tavares is a professional in the field of information security working as an Ethical Hacker, Malware Analyst and a Security Evangelist. He is also Editor-in-Chief of the security computer blog seguranca-informatica.pt.

In recent years, he has invested in the field of information security, exploring and analyzing a wide range of topics, such as malware, reverse engineering, pentesting (Kali Linux), hacking/red teaming, mobile, cryptography, IoT, and security in computer networks. He is also a Freelance Writer.


Notice: Undefined index: visitor_id12882 in /www/resourcesinfosecinstitute_601/public/wp-content/plugins/infosec-user-info/infosec-user-info.php on line 117