UAFs in Linux Kernel Modules: CVE-2019-8912 & CVE-2019-8956

A researcher using syzkaller found a locally-exploitable bug in Linux’s crypto API, CVE-2019-8912, which allows for a use-after-free in sockfs_setattr. It’s received sudden buzz, probably because a bug in the kernel’s cryptography API sounds pretty scary! And, there’s a hot 2-for-1 special for Linux use-after-free bugs with the announcement of CVE-2019-8956, too.

What makes it bad: This affects the Linux kernel from the 2.6 kernel through 4.20.11, which is a lot of kernels — but distributions have not enabled it by default until fairly recently (for Ubuntu, it became enabled by default in the Bionic Beaver release). In combination with an information leak, it should be reasonably easy for attackers with local access to use this bug to escalate privileges. What’s more, the crypto API usually isn’t blacklisted within enterprise deployments and is available most of the time, even inside containers — for instance, it’s available inside a default Docker container.

Yes, but: Local access seems very likely required for successful exploitation (RedHat indeed believes it is local-only), so the attacker still needs a way to land on the system first. There isn’t a public proof of concept yet, so the skiddie threat is negligible for now — unmotivated attackers need not apply.

Digging deeper: The function af_alg_release() in the file crypto/af_alg.c forgets to set a null value for a certain socket structure member, which leads to a use-after-free in the sockfs_setattr function. One reason why af_alg exists is so that programs don’t have to store cryptographic keys or other sensitive parameters, because the kernel exposes its crypto API to userspace. So, af_alg is useful to ensure that if an application is compromised, the attacker can’t get the key material. Another is that af_alg can access hardware freely, whereas userland cryptographic libraries have to ask the kernel for permission to use hardware acceleration, for instance — which could slow things down.

But wait, there’s more: There’s another use-after-free, CVE-2019-8956, that just came out in sctp_sendmsg(). It has basically the same impact on vulnerable machines, but only affects Ubuntu Cosmic (Cosmic isn’t a long-term support (LTS) release and reasonably new, so not many enterprises use it). For those who do use Ubuntu Cosmic, unfortunately there’s currently no patch — but luckily the potentially vulnerable footprint is a lot smaller than CVE-2019-8912.

What should I do now? A workaround for both of these issues is to blacklist the kernel module responsible for the vulnerable functionality. Be sure to test these changes on a staging system to ensure this does not impact your services before you deploy this to your production hosts!

Instructions for how to disable kernel modules are available at Red Hat’s documentation site. The relevant modules to blacklist are af_alg for CVE-2019-8912 and sctp for CVE-2019-8956.

The bottom line: CVE-2019-8912, while a local bug, is bad enough and affecting enough distros that it’s worth disabling the module using the instructions above. A patch isn’t out yet in most distributions for CVE-2019-8912, so monitor the Debian and Ubuntu dashboards for their patch cycles for this issue and patch ASAP once it’s available.

If you’re one of the few using Ubuntu Cosmic, pay attention to that second bug we mentioned in sctp_sendmsg(), CVE-2019-8956, and follow our recommended advice to disable it — lest you experience a cosmic-level compromise.

The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.