CVE-2025-6018 + CVE-2025-6019 Exploit Chain

This exploit was developed to solve a HackTheBox challenge targeting openSUSE Leap 15.6.

Credits

This exploit is based on the original research by the Qualys Security Team:

• Advisory: https://cdn2.qualys.com/2025/06/17/suse15-pam-udisks-lpe.txt
• CVE-2025-6018: LPE from unprivileged to allow_active in openSUSE 15's PAM
• CVE-2025-6019: LPE from allow_active to root in libblockdev via udisks

Additional reference implementation:

• https://github.com/symphony2colour/CVE-2025-6019-udisks-lpe-no-image

Overview

This exploit chains two vulnerabilities to achieve local privilege escalation from an unprivileged user to root on openSUSE Leap 15.6:

1. CVE-2025-6018: Exploits PAM configuration to gain allow_active privileges
2. CVE-2025-6019: Exploits UDisks2/libblockdev to escalate from allow_active to root

Requirements

• Target system: openSUSE Leap 15.6
• XFS image file with SUID bash binary (see below)
• SSH or local shell access as unprivileged user

Creating the XFS Image

The exploit requires a pre-created XFS filesystem image containing a SUID bash binary. This must be created on a Linux machine where you have root privileges:

dd if=/dev/zero of=xfs.image bs=1M count=400
mkfs.xfs xfs.image
mkdir -p /tmp/mnt
mount xfs.image /tmp/mnt
cp /bin/bash /tmp/mnt/bash
chmod 04755 /tmp/mnt/bash
umount /tmp/mnt

Verify the image was created correctly:

file xfs.image
# Should output: "SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)"

How It Works

Step 1: CVE-2025-6018

• Creates ~/.pam_environment with XDG_SEAT and XDG_VTNR overrides
• Tricks pam_systemd into thinking you're a physical console user
• Grants "allow_active" polkit privileges

Step 2: CVE-2025-6019

• Sets up loop device with XFS image
• Triggers filesystem resize via UDisks2 D-Bus interface
• libblockdev mounts XFS to /tmp without nosuid/nodev flags
• Executes SUID bash from mounted filesystem to gain root

Troubleshooting

If the exploit fails:

• Verify the XFS image is correct: file xfs.image
• Ensure you disconnected and reconnected SSH after first run
• Try running the exploit multiple times (timing-sensitive)
• Check that udisks2 service is running: systemctl status udisks2

Disclaimer

This exploit is for educational purposes and authorized security testing only. Use responsibly and only on systems you have permission to test.