A vulnerability from more than 15 years ago in Netfilter allowed escalation of privileges

A few days ago the news was released that a vulnerability has been identified in Netfilter (a Linux kernel subsystem used to filter and modify network packets), which allows a local user to gain root privileges in a systemeven while in an insulated container.

The CVE-2021-22555 vulnerability it's a problem that has been around since kernel 2.6.19, launched 15 years ago and is caused by a bug in the drivers IPT_SO_SET_REPLACE and IP6T_SO_SET_REPLACE, which causes a buffer overflow when sending specially decorated parameters via the setsockopt call in compat mode.

Perhaps many at this point will wonder how it is possible that a flaw in the Linux Kernel could go unnoticed for so long and the answer to that is that even though the flaw that was present since Linux 2.6.19, the vulnerability was found through code audit, even though the C code was not reproducible, so it could not be exploited because the necessary resources to escalate the privileges were not found at that time.

For example support for unprivileged user namespaces is in kernel 3.8. Also some distributions have a patch that adds sysctl to disable unprivileged user namespaces.

Under normal circumstances, only the root user can call compat_setsockopt (), But the necessary permissions to perform an attack they can also be obtained by an unprivileged user on systems with user namespaces enabled.

CVE-2021-22555 is a 15 year old stack out of stack write vulnerability in Linux Netfilter that is powerful enough to bypass all modern security mitigations and achieve kernel code execution.

As such, it is described that a local user can create a container with a separate root user and exploit the vulnerability from thereí. For example, "user namespaces" are included by default in Ubuntu and Fedora, but not in Debian and RHEL.

This vulnerability can be exploited by partially overwriting the m_list->nextpointer msg_msgstructure and achieving a free after use. This is powerful enough to get your kernel code running bypassing KASLR, SMAP, and SMEP.

Also, problem arises in xt_compat_target_from_user () function due to incorrect memory size calculation when saving kernel structures after conversion from 32-bit to 64-bit representation.

As such, it is mentioned that the error allows writing four "zero" bytes to any position outside the buffer assigned, limited by offset 0x4C. Because of this, it is mentioned that this feature turned out to be enough to create an exploit which allows to get root rights: by deleting the m_list-> next pointer in the msg_msg structure, the conditions were created to access the data after freeing up memory (use-after-free), which was then used to obtain information about addresses and changes to other structures by manipulating the msgsnd () system call.

Regarding the error report, like any vulnerability detected, this involves a process and the report that was made to the kernel developers in April, with which afterwards it was corrected in a few days and the patch that is included in all supported distributions, so that information about the bug can be released later.

The Debian, Arch Linux, and Fedora projects have already generated package updates. Starting with Ubuntu, RHEL and SUSE updates are in the works. Because the error is serious, exploitable in practice and allows to escape from the container, Google estimated its discovery at $ 10,000 and doubled the reward to the researcher who identified the vulnerability and for identifying a method to avoid isolating Kubernetes containers on the kCTF cluster.

For testing, a working prototype of an exploit has been prepared that bypasses the KASLR, SMAP and SMEP protection mechanisms.

Finally if you are interested in knowing more about it, you can check the details In the following link.


Leave a Comment

Your email address will not be published. Required fields are marked with *

*

*

  1. Responsible for the data: AB Internet Networks 2008 SL
  2. Purpose of the data: Control SPAM, comment management.
  3. Legitimation: Your consent
  4. Communication of the data: The data will not be communicated to third parties except by legal obligation.
  5. Data storage: Database hosted by Occentus Networks (EU)
  6. Rights: At any time you can limit, recover and delete your information.