zanezhub/cve-2022-1015-1016Traducción al español de los CVE-2022-1015 y 1016 descubiertos y documentados por David.
This README.md is a translation of David's blog. David found CVEs 1015 and 1016 in the Linux kernel. You can visit his website to read the original document.
Here are his social media links:
Published on April 2, 2022.
These issues should be exploitable in the default configurations of the newest versions of Ubuntu and RHEL. I wrote my proof of concept (PoC) for CVE-2022-1015 targeting kernel version 5.16-rc3 on Arch Linux.
This document is aimed at people who have a basic understanding of the Linux kernel in terms of functionality and security. I tried to make this document friendly to those lacking knowledge of the networking stack to make it accessible to everyone.
Here is a reading guide:
In mid-February, Google's security program announced that they would continue their kCTF bounty program, offering bounties ranging from $31,337 to $91,337 for a Linux kernel exploit that can escalate privileges to root from unprivileged processes in an nsjail sandbox.
Being a poor student, this obviously caught my attention. This was my first time looking for a "real world" vulnerability, but in my adventures playing CTF with my team, I have become familiar with the Linux kernel in terms of security. After hours and hours with very little close to nothing progress (but with greater knowledge about Linux) I managed to find some vulnerabilities in the nf_tables module.
Sadly, at the end of the day, I realized that this module was not included in Google's kCTF rules (so I did not get any bounty for these two vulnerabilities). But obviously, I still reported them and wrote an LPE (Local Privilege Escalation) exploit for CVE-2022-1015.
Alright, so you have decided that you are going to find some vulnerabilities in Linux. Now what? Linux is a gigantic project, and it is quite easy to not see the forest for the trees (you focus so much on details that you lose sight of what is really important, you don't have an overview of the situation). To make matters worse, many parts are undocumented and you need to read a lot of code to understand what is going on.
I started by trying to get a detailed perspective of the Linux security model. Finding a bug is one thing; but finding a good bug is another. After all, not all bugs are created equal:
FS_USERNS_MOUNT, in which case you can mount them in a user namespace.CAP_SYS_ADMIN or CAP_NET_ADMIN.
/proc/config.gz. Modules can be built-in (=y) or compiled separately and loaded at runtime (=m)./proc/modules and /proc/kallsyms, but they are not always reliable, as modules can be dynamically loaded into the kernel (e.g. request_module).These restrictions help us to know the limits of the filesystems in which we can look for vulnerabilities. I think it is a good idea to take your time trying to plan your attack on your desired target.
I have already learned my lesson about the previous point. As I mentioned, the nf_tables module was not loaded on the instance presented by kCTF. I could have realized this from the start and saved myself the disappointment :p. On the other hand, you probably wouldn't be reading this blog right now if I had realized earlier, I guess things turned out okay after all.
An explanation why COS, Google's container-optimized Linux fork, did not have nf_tables can be found here and here.
After evaluating the above points, I decided that my best path to start was probably to look at the networking source code. Many of the interesting features there require CAP_NET_ADMIN, but as I mentioned, this is not really a problem. On the contrary, I suspect that components requiring special capabilities are generally less secure, as kernel developers may have a false sense of security.
I also made an effort to choose the filesystem I wanted to learn more about; this way, even if you don't find any bugs you will still learn a lot of interesting things.
I investigated many networking filesystems, but didn't find anything significant. After navigating the net/ subdirectory, I came across the nf_tables module. It seemed a bit complex, so I decided to take some time to learn about it.
Netfilter (net/netfilter) is a fairly large networking subsystem in the kernel. In summary, netfilter places hooks across the networking modules that other modules can register handlers with. When a hook is reached, control is delegated to those handlers, and they can operate on their respective network packet structure. Handlers can accept, drop, and modify packets.