Someone was silly enough to upload a working spectre (CVE-2017-5753) exploit for Linux (there is also a Windows one with symbols that I didn't look at.) on VirusTotal last month, so here is my quick Sunday afternoon lazy analysis.

The binary has its -h option stripped, likely behind a #define to avoid detection, but some of its parameters are obvious, like specifying what file to leak, or the kernel base address. The authors didn't check (or care) that the logging function hasn't been entirely optimized out, leaving a bunch of strings helping in the reversing process.

The exploit works in four stages:

1. Find the superblock,
2. Find the inode of the file to dump
3. Find the corresponding page address
4. Dumps the content of the file.

In the case of /etc/shadow, the default option, the content of the file is shoved in memory by running the following command in the background: return system("echo \"whatever\n\" | su - 2> /dev/null"). In my lab, on a vulnerable Fedora, the exploit is successfully dumping /etc/shadow in a couple of minutes. Interestingly, there are checks to detect SMAP and abort if it's present. I didn't manage to understand why the exploit was failing in its presence.

The crux of the exploit is at 0x4092f0, using cpuid as a serializing instruction, rdtsc for timing, and mfence/lfence as barrier, as documented in the paper. It's also using some tricks to minimize the amount of readings, like type-specific functions, for example a kernel address has a specific format. Thanks to spender for confirming that the gadget used is likely get_user() in the FIOASYNC ioctl, which was fixed in 2018

KASLR is bypassed when present either by looking at /proc/kallsyms when available to unprivileged users like it used to be the case on Fedora until ~recently, or by using the generic bypass from the prefetch side-channel by Gruss and al. originating from a library called libkaslr. Amusingly, this method is still working on an up to date Linux, proving again that KASLR is useless at best. For systems that don't have the /proc/kallsym file accessible, the exploit relies on hardcoded offsets, and while only Fedora, ArchLinux and Ubuntu are currently supported, there are functions to check for Debian and CentOS. It's a bit surprising to see hardcoded offsets in an exploit with arbitrary read in 2021.

Unsurprisingly, it had a 0 detection rate before I published this blogpost.

Attribution is trivial and left as an exercise to the reader.