Linux privilege escalation exploiting waitid
syscall. The exploit is brought
to you by @XeR_0x2A and @chaign_c from HexpressoTeam for
educational purposes only.
The bug was introduced the 2017-05-21 and fixed 2017-10-09, 4.14.0-rc4+ is
known vulnerable.
If you have a beginner/intermediate exploit writer level, we encourage you to
exploit it yourself before reading our implementation. It is a very good
exercise with an easy exploit primitive (arbitrary write to writable kernel
memory).
We also challenge @LiveOverflow to give it a try.
Here is the description:
oss-security:
Hi,Chris Salls discovered that when the waitid() syscall in Linux kernel
v4.13 was refactored, it accidentally stopped checking that the
incoming argument was pointing to userspace. This allowed local
attackers to write directly to kernel memory, which could lead to
privilege escalation.Introduced by this commit:
https://git.kernel.org/linus/4c48abe91be03d191d0c20cc755877da2cb35622Fixed with this commit to mainline tree:
https://git.kernel.org/linus/96ca579a1ecc943b75beba58bebb0356f6cc4b51This should be fixed in the -stable free (in the future v4.13.7) soon:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/?h=linux-4.13.yThanks,
waitid:
waitid -- wait for a child process to change state.
int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);
The kernel doesn't check whether infop
is a kernelland or an userland
pointer, so we can overwrite memory of any kernel memory page with write
permissions. The fun part is that we only control partially what is written.
There are more than a thousand ways to exploit this. We decided to turn this
write primitive into a null pointer dereference. We overwrote the
have_canfork_callback
variable in the .BSS section of the kernel. Setting
this variable to anything else than 0 (true) will cause an unset
callback (null) to be "called on a new task before the process is exposed".
Thanks to Chris Salls and @kees_cook for sharing the CVE.
First "real world" linux kernel exploit of @XeR_0x2A and @chaign_c from HexpressoTeam.
chaignc+cve-2017-5123@hexpresso.team
xer+cve-2017-5123@hexpresso.team
2017-10-22