CVE-2021-22600 PoC — Double Free in net/packet/af_packet.c leading to priviledge escalation

Source

Associated Vulnerability

Description

Proof-Of-Concept to check privileges of af_packet.c for validating the privileges acquired by any hacker upon successful exploitation of CVE-2021-22600

Readme

# af_packet.c
Proof-Of-Concept to check privileges of af_packet.c for validating the privileges acquired by any hacker upon successful exploitation of CVE-2021-22600
***


It is just a sample proof of concept generated by LLM and does not cover all cases.
The basic idea behind this proof of concept is to check what kind of privileges does the target code run with (whether in userspace or kernelspace, as example) to understand the implications of its exploitation with any exploit built around the CVE-2021-22600.
This code, by no means, is an exploit of the aforementioned CVE. I tried this on Ubuntu inside a VM. Your mileage may vary based in environment.


***


Steps to compile code and run it:
```
gcc program.c -o runme
chmod +x runme
./runme
sudo ./runme
```
***


Sample output for running as normal user:
```
<..SNIP..>
=== AF_PACKET privilege probe ===
UID=1000  EUID=1000

WARNING: couldn't read CapEff from /proc/self/status. Continuing anyway.
Stage 1: try AF_PACKET + SOCK_DGRAM (no CAP_NET_RAW required by kernel check)
socket(AF_PACKET, SOCK_DGRAM, ETH_P_ALL) => FAILED: Operation not permitted (errno=1)

Stage 2: try AF_PACKET + SOCK_RAW (kernel checks CAP_NET_RAW for SOCK_RAW)
socket(AF_PACKET, SOCK_RAW, ETH_P_ALL) => FAILED: Operation not permitted (errno=1)
RAW socket creation failed: you cannot reach packet_set_ring() from user-land without CAP_NET_RAW.
Common results:
 - errno=EPERM (Operation not permitted) : you lack CAP_NET_RAW
 - errno=EACCES : sometimes indicates policy or network namespace restrictions

Notes:
 - The kernel enforces CAP_NET_RAW at socket creation: look for a check like
     if (sock->type == SOCK_RAW && !capable(CAP_NET_RAW)) return -EPERM;
   in net/packet/af_packet.c (this is why PACKET_RX_RING is unreachable without that socket).
 - If you run this program as root or with CAP_NET_RAW, the RAW socket will succeed and
   setsockopt(PACKET_RX_RING) will attempt to configure the ring (it may still fail with EINVAL
   if your parameters are invalid, but you will have invoked packet_set_ring()).

=== Done ===
<..SNIP..>
```
***
&NewLine;
Sample output for running as sudo / root user:
```
<..SNIP..>
=== AF_PACKET privilege probe ===
UID=0  EUID=0

CapEff (hex) = 0x000001ffffffffff
 -> CAP_NET_RAW (bit 12) = YES

Stage 1: try AF_PACKET + SOCK_DGRAM (no CAP_NET_RAW required by kernel check)
socket(AF_PACKET, SOCK_DGRAM, ETH_P_ALL) => OK (fd=3)

Stage 2: try AF_PACKET + SOCK_RAW (kernel checks CAP_NET_RAW for SOCK_RAW)
socket(AF_PACKET, SOCK_RAW, ETH_P_ALL) => OK (fd=3)
Since RAW socket creation succeeded, we likely have CAP_NET_RAW (or are root).

Stage 3: try setsockopt PACKET_RX_RING (this invokes packet_set_ring in kernel)
setsockopt(PACKET_RX_RING) => OK

Notes:
 - The kernel enforces CAP_NET_RAW at socket creation: look for a check like
     if (sock->type == SOCK_RAW && !capable(CAP_NET_RAW)) return -EPERM;
   in net/packet/af_packet.c (this is why PACKET_RX_RING is unreachable without that socket).
 - If you run this program as root or with CAP_NET_RAW, the RAW socket will succeed and
   setsockopt(PACKET_RX_RING) will attempt to configure the ring (it may still fail with EINVAL
   if your parameters are invalid, but you will have invoked packet_set_ring()).

=== Done ===
<..SNIP..>
```
***
&NewLine;

File Snapshot

 [4.0K]  /data/pocs/9ce7b51703acef38d0c5220ad86a8bc678cc8f33
├── [1.0K]  LICENSE
├── [4.6K]  program.c
└── [3.3K]  README.md

0 directories, 3 files

Remarks