PID recycling enables an unprivileged user to generate and read a crash report for a privileged process
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Apport |
Fix Released
|
Critical
|
Unassigned | ||
apport (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
Dear Ubuntu Security Team,
I would like to report a vulnerability in Apport, which enables an unprivileged user to read important information about a privileged process.
From an attacker's point of view, the main value of the vulnerability is that it enables them to obtain the ASLR offsets for a privileged process, provided that they have the ability to deliberately crash the privileged process. This is very useful for an attacker if they have discovered a memory corruption vulnerability in a privileged service. It is often very difficult to obtain code execution from a memory corruption vulnerability unless you have access to the ASLR offsets. But it is usually very easy to trigger a crash by corrupting the memory with random data. The vulnerability in Apport enables the attacker to obtain the ASLR offsets for the service after it is has restarted due to an attacker-controlled crash.
I have attached an exploit proof of concept which demonstrates the vulnerability on the whoopsie process. As you know, whoopsie has a memory corruption vulnerability which is currently still unfixed: 1830865. The vulnerability in whoopsie is very difficult to exploit without knowing the ASLR offsets. But it is easy for an unprivileged user to cause whoopsie to crash. The PoC uses this to deliberately crash whoopsie and obtain ASLR offsets for the new whoopsie after it has been restarted automatically by systemd.
To run the PoC:
gunzip Apport_PoC.tar.gz
tar -xf Apport_PoC.tar
cd Apport_PoC/
make
./restart_whoopsie init 10
The PoC is slightly non-deterministic, so it might take several tries before it succeeds. (It will print messages to tell you what is going on while it is running.) When it succeeds, Apport will create a file named something like this:
/var/crash/
If you run apport-unpack on that crash report then you will see that it contains the ProcMaps file for the currently running whoopsie.
The source of the problem is here:
Apport determines which user the crashed process belongs to by reading the contents of /proc/[pid]. But pids can get recycled. The exploit works by pausing Apport while it is in the middle of generating a crash report and then sending a SIGKILL to the crashed process so that its pid gets recycled. When Apport resumes, it starts generating a crash report for a new process which has been assigned the same pid as the crashed process.
I am happy to help out if you would like to discuss what the best solution is for this vulnerability. I have some ideas, but they might be naive. This is a very tricky area of the code and I am sure that I am not yet aware of all the subtle reasons why it is currently written the way it is.
Please let me know when you have fixed the vulnerability, so that I can coordinate my disclosure with yours. For reference, here is a link to Semmle's vulnerability disclosure policy: https:/
Thank you,
Kevin Backhouse
Semmle Security Research Team
CVE References
summary: |
PID recycling enables an unprivileged user to generate and read a crash - report for a privileged process after it has crashed + report for a privileged process |
information type: | Private Security → Public Security |
tags: | added: id-5db7d98b9aa43003f76d70d0 |
Changed in apport: | |
status: | New → Fix Released |
importance: | Undecided → Critical |
milestone: | none → 2.21.0 |
Hello Kev, thanks for the report; we'll take a look at get back to you soon.
Thanks