CVE-2021-3156: Sudo privilege escalation vulnerability hiding under the hood for 10 years

By Bhabesh Raj Rai, Associate Security Analytics Engineer

On January 26, 2021, the Qualys Research Labs disclosed a heap-based buffer overflow vulnerability (CVE-2021-3156) in sudo, which on successful exploitation allows any local user to escalate privileges to root. Both sudoers, as well as non-sudoers, can exploit the vulnerability without authentication to achieve root privileges.

The vulnerability is due to improper parsing of command line parameters and an attacker can exploit it via “sudoedit -s” and a command-line argument that ends with a single backslash character. The flaw was introduced in July 2011 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.

The Qualys Research team was able to independently verify the vulnerability and develop multiple exploit variants for Ubuntu 20.04 (Sudo 1.8.31), Debian 10 (Sudo 1.8.27), and Fedora 33 (Sudo 1.9.2). However, other distributions may also be vulnerable because Sudo is available in almost all major Unix/Linux OS flavors.

Even though the vulnerability was fixed in a mere 13 days, many upstream builds haven’t applied the patch yet, which leaves a large number of systems vulnerable. To make matters worse, several PoCs are now available in Github, opening the gate for easy exploitation by unsophisticated threat actors.

The Sudo privilege escalation vulnerability also affected LogPoint products and on January 29, 2021, we released LogPoint v6.9.2 to fix the vulnerability. We recommend all LogPoint users upgrade to the latest product version.

You can easily detect the exploitation attempt of the Sudo flaw via auditd logs. Just like the case with Sysmon, auditd requires proper rules to generate artifacts of interests. Florian Roth‘s auditd configuration is sufficient for this purpose.

Since brute-forcing is required to trigger the vulnerability, auditd logs will be flooded with events relating to sudoedit.

You can create detections using any of the three event types generated by auditit – SYSCALL, EXECV, and ANOM_ABEND.

For detection based on EXECVE, we just need to look for a large influx of EXECVE logs for sudoedit with “\” and “-s” as command line parameters.

norm_id=Unix "process"=Audit event_type=EXECVE
argument_0="/usr/bin/sudoedit"
(argument_1="\" OR argument_2="\" OR argument_3="\" OR argument_4="\" OR argument_5="\")
(argument_1="-s" OR argument_2="-s" OR argument_3="-s" OR argument_4="-s" OR argument_5="-s")
| chart count() as cnt by host
| search cnt > 50

The detection based on SYSCALL is also simple because we just need to look for a large influx of SYSCALL logs for sudoedit command.

norm_id=Unix "process"=Audit
event_type=SYSCALL command=sudoedit path="/usr/bin/sudo"
| chart count() as cnt by host
| search cnt > 50

Sometimes, if the exploit fails, then abnormal process termination logs are generated, which may also indicate an exploitation attempt.
norm_id=Unix "process"=Audit
label=Abnormal label="Process" label=Terminate
command="sudoedit" path="/usr/bin/sudo"
| chart count() as cnt by host
| search cnt > 50

Finally, we can hunt for any invocations of sudoedit with an abnormally long command line, which may indicate the attempt to trigger the heap-based buffer overflow vulnerability. Admins can tune the threshold command line length to reduce any false positives.

norm_id=Unix "process"=Audit event_type=EXECVE
argument_0="/usr/bin/sudoedit"
| process eval("a1_len=len(argument_1)")
| process eval("a2_len=len(argument_2)")
| process eval("a3_len=len(argument_3)")
| process eval("a4_len=len(argument_4)")
| chart count() by host, a1_len, a2_len, a3_len, a4_len
| search (a1_len>100 OR a2_len > 100 OR a3_len>100 OR a4_len>100)

Since attackers can exploit this flaw even in the default configuration, system administrators are advised to patch their systems as soon as possible. If patching is not possible or the patch has not been released for the Linux/Unix distribution used, then we recommend that you deploy detections that monitor for any exploitation attempts.

Threat actors can use the sudo vulnerability in conjunction with other attack methods to fully compromise the system. We advise organizations to initiate incident response if any exploitation attempt is detected.