The CVE-2021-33909, named Sequoia, is a new privilege escalation vulnerability that affects Linux’s file system. It was disclosed in July, 2021, and it was introduced in 2014 on many Linux distros; among which we have Ubuntu (20.04, 20.10 and 21.04), Debian 11, Fedora 34 Workstation and some Red Hat products, too.
This vulnerability is caused by an out-of-bounds write found in the Linux kernel’s seq_file in the Filesystem layer.
Its severity level is high (CVSS 7.0) which means that, if exploited by low-level privileged attackers, they may escalate their permissions to root, and compromise the involved machine.
By having administrator permissions, the attackers can access all the data stored and processed by the compromised machine. This includes private customer data, or even credentials and secrets for services in your infrastructure that could be used to enable a bigger scale attack.
In this article we’ll cover why the Sequoia vulnerability can be used to perform privilege escalation, and how to mitigate it.
Preliminary
A file system is a collection of data and metadata stored on a physical device.
There are different types of file system implementations that behave very differently from one to another, like ext2, FAT, NFS, and so on.
In order to support all of these on different storage devices, Linux file system architecture provides a common set of API functions that, for example, allow users to read or write files independently from the real file system implementation.
For these reasons, the Linux file system interface is implemented in a three-layered architecture: there is the user interface layer, the file system implementation, and then storage device drivers.
The CVE-2021-33909 directly impacts what is the Linux kernel’s seq_file in the file system layer.
Let’s deep dive now into the technical aspects of this CVE.
The CVE-2021-33909 Sequoia issue
The vulnerability CVE-2021-33909, codenamed Sequoia, allows an unprivileged or a low-privileged local user to escalate to root privileges or to cause a system crash. This is done by taking advantage of a missing validation of size_t-to-int conversion (from 64 to 32 bits) that may leak internal kernel information.
As a matter of fact, the flaw related to Sequoia is an out-of-bounds write found in the Linux kernel’s seq_file interface in the file system layer. The cause is that:
- The
seq_fileinterface produces virtual files, each containing sequences of records. - Each record must fit into a seq_file buffer, whose size is a size_t (64-bit unsigned value). It may be enlarged, if needed, by doubling it, as you can see from the left-shift operation at the end of this piece of code:
/*grab buffer if we did not have one*/
if (!m->buf){
m->buf=kmalloc(m->size=PAGE_SIZE, GFP_KERNEL);
}
…
/* we need at least one record in the buffer */
while(1){
…
m->buf=kmalloc(m->size<<=1, GFP_KERNEL);
}
The real problem occurs when a long directory path is used in the show_mountinfo() function. As a matter of fact, show_mountinfo() calls seq_dentry() which respectively calls dentry_path().
char* dentry_path (struct dentry* dentry, char* buf, int buflen)
As you can see from its prototype, it expects buflen (buffer length) as an int (32-bit signed value) and no more a size_t one. So buflen causes a conversion problem, transforming the number to a negative value. This causes an out-of-bounds access vulnerability.
In order to leverage the CVE-2021-33909, a low-level privileged user should use an exploit that does the following operations:
- Creates a deep directory structure whose total path length exceeds 1GB. As you can see from this piece of code, it firstly creates a
bigdirdirectory, inside which is generated a deep directory structure with the “for” loop.
- Then it bind-mounts it in an unprivileged user namespace, and finally will delete it.
- Calls
open()andread()on/proc/self/mountinfo, in order to read the long path of the bind-mounted directory.
- Used in conjunction with a small eBPF program, in order to cause information disclosure, and a limited but controlled out-of-bounds write, with the purpose of reading and writing kernel memory.
At this point, an attacker can locate the modprobe_path[] buffer in kernel memory, on which he can perform an arbitrary write, replacing its content to obtain full privileges.
The impact of CVE-2021-33909
Due to the recent publication and the responsibility to disclose the related vulnerability, no public exploit for privilege escalation has been released yet. Instead, it was published a vulnerability proof of concept that causes the system crash.
According to CVSS system, this vulnerability scores 7.0, which roughly means high severity.
To learn more about how a vulnerability score is calculated, Are Vulnerability Scores Tricking You? Understanding the severity of CVSS and using them effectively
The reason this vulnerability is so severe, is that via privilege escalation, an attacker can gain root privileges. This means he can perform whatever type of unauthorized execution and action that can compromise the integrity of the entire system. He can have access to confidential data stored inside the target host, and he can also manipulate the OS and its configuration.
By the way, the attacker should already have low-level privileges inside the target machine, this is the reason why it is not marked as critical.
As we previously said, this vulnerability impacts many Linux distros since 2014, so you can sense that there are a lot of vulnerable machines which are affected by it.
Since the exploit would be out soon, we need to focus our attention on how to mitigate and detect this problem.
Mitigating CVE-2021-33909
If your environment is affected by this vulnerability, you should install the related patch as soon as possible.
Instead, if no patch has been released for your Linux distribution yet, or if you are not able to immediately install it, then you can mitigate this vulnerability via host scanning.
Host scanning allows you to analyze the contents of each host of your environment in order to mitigate security issues, vulnerabilities or bad practices.
Check out our image scanning best practices, to discover how this mechanism can help you block known vulnerabilities from being deployed in production. You may also be interested in these vulnerability assessment and management best practices, to learn how to handle those vulnerabilities.
The images below shows how the results of a scan, where the host selected for scanning is affected by the Sequoia vulnerability:
Host scanning results in Sysdig secure
Sysdig secure provides information about the vulnerabilities, and suggests remediation steps.
Post-exploitation detection of CVE-2021-33909
As previously mentioned, no public exploit for this vulnerability has been released. However, due to the high-level of severity, it may be quite important to detect any post-exploitation activity using Falco.
Falco is the CNCF open-source project, used to detect unexpected application behavior and to send alerts at runtime. You can use some of its predefined set of rules, but you can also customize them or create new ones that fit your needs as you want.
In order to detect post-exploitation activities, let’s see some default Falco rules to monitor high-level privileged executions within your hosts. For further more, check out Falco project in GitHub.
Rule: Write below binary dir
This rule allows you to detect suspicious write operations below /bin or /sbin folders, that contain respectively user executable files and binaries, such as bash shell, and essential system administration binaries, usually run by root user for system administration purposes.
- rule: Write below binary dir
desc: an attempt to write to any file below a set of binary directories
condition: >
bin_dir and evt.dir = < and open_write
and not package_mgmt_procs
and not exe_running_docker_save
and not python_running_get_pip
and not python_running_ms_oms
and not user_known_write_below_binary_dir_activities
output: >
File below a known binary directory opened for writing
(user=%user.name user_loginuid=%user.loginuid
command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline gparent=%proc.aname[2] container_id=%container.id image=%container.image.repository)
priority: ERROR
tags: [filesystem, mitre_persistence]
Rule: Write below /root
It allows you to monitor write operation within the /root home directory for the root user.
- rule: Write below root
desc: an attempt to write to any file directly below / or /root
condition: >
root_dir and evt.dir = < and open_write
and proc_name_exists
and not fd.name in (known_root_files)
and not fd.directory pmatch (known_root_directories)
and not exe_running_docker_save
and not gugent_writing_guestagent_log
and not dse_writing_tmp
and not zap_writing_state
and not airflow_writing_state
and not rpm_writing_root_rpmdb
and not maven_writing_groovy
and not chef_writing_conf
and not kubectl_writing_state
and not cassandra_writing_state
and not galley_writing_state
and not calico_writing_state
and not rancher_writing_root
and not runc_writing_exec_fifo
and not mysqlsh_writing_state
and not known_root_conditions
and not user_known_write_root_conditions
and not user_known_write_below_root_activities
output: "File below / or /root opened for writing (user=%user.name user_loginuid=%user.loginuid command=%proc.cmdline parent=%proc.pname file=%fd.name program=%proc.name container_id=%container.id image=%container.image.repository)"
priority: ERROR
tags: [filesystem, mitre_persistence]
Rule: Search private Keys or Passwords
Allows to detect if the attacker is trying to locate sensitive data or files.
- rule: Search Private Keys or Passwords
desc: >
Detect grep private keys or passwords activity.
condition: >
(spawned_process and
((grep_commands and private_key_or_password) or
(proc.name = "find" and (proc.args contains "id_rsa" or proc.args contains "id_dsa")))
)
output: >
Grep private keys or passwords activities found
(user=%user.name command=%proc.cmdline container_id=%container.id container_name=%container.name
image=%container.image.repository:%container.image.tag)
priority:
WARNING
tags: [process, mitre_credential_access]
Rule: Read ssh information:
This rule may detect any read attempt below ssh directories.
- rule: Read ssh information
desc: Any attempt to read files below ssh directories by non-ssh programs
condition: >
(consider_ssh_reads and
(open_read or open_directory) and
(user_ssh_directory or fd.name startswith /root/.ssh) and
(not proc.name in (ssh_binaries)))
output: >
ssh-related file/directory read by non-ssh program (user=%user.name
command=%proc.cmdline file=%fd.name parent=%proc.pname pcmdline=%proc.pcmdline)
priority: ERROR
tags: [filesystem, mitre_discovery]
Conclusion
The vulnerability CVE-2021-33909 allows attackers that already have local and low-privileged access to a host, to perform privilege escalation, running any command with root privileges via sophisticated exploits or to cause affected systems crash.
In case you want to mitigate the execution of such vulnerable hosts, you can use tools like host scanners. You may also choose to adopt Falco to detect suspicious post-exploitation behaviors inside your host, receiving some alerts when your custom or default rules are triggered.
By the way, if your hosts are already running and vulnerable, don’t hesitate to install the related patch that protects you from high-level privileged and malicious actions!
If you would like to find out more about Falco:
- Get started in Falco.org.
- Check out the Falco project in GitHub.
- Get involved with the Falco community.
- Meet the maintainers on the Falco Slack.
- Follow @falco_org on Twitter.
At Sysdig Secure, we extend Falco with out-of-the-box rules along with other open source projects, making them even easier to work with and manage Kubernetes security. Register for our Free 30-day trial and see for yourself!