Re: New Linux LPE via GSMIOC_SETCONF_DLCI?

[Solar Designer <solar () openwall com>]

On Wed, Apr 10, 2024 at 11:14:57PM +0200, Solar Designer wrote:
> On Wed, Apr 10, 2024 at 09:56:33PM +0200, Dr. Christopher Kunz wrote:
> > 1. YuriiCrimson's version (April 6-ish)
> >
> > It seems to use GSMIOC_SETCONF_DLCI, PoC supposedly works on current Ubuntu 
> > and Debians, but is stopped by LKRG.
> >
> > PoC and writeup are here: 
> > https://github.com/YuriiCrimson/ExploitGSM/tree/main
>
> According to YuriiCrimson:
>
> https://twitter.com/YuriiCrimson/status/1778163455075217443
>
> "Exploit 6.4 - 6.5 using race condition in gsm_dlci_config.
> Exploit for 5.15 - 6.5. using race condition in
> gsm_dlci_open->gsm_modem_update->gsm_modem_upd_via_msc->gsm_control_wait.
> We just waiting on gsm_cobtrol_wait and restart config for make free
> dlci)). So it two zero days."
>
> > 3. ZDI-24-020 / CVE-2023-6546 (January)
> >
> > This also exploits a race condition resulting UAF in the gsm_dlci struct. 
> > It's a little older.
> >
> > Writeup and PoC: https://github.com/Nassim-Asrir/ZDI-24-020/
> >
> > What do you make of this?
>
> So it sounds like there are 3 different bugs recently found in this same
> subsystem.  Perhaps someone can follow up with links to relevant commits.

I'm puzzled by the lack of follow-ups on this, but anyway @FFFVR_
tweeted they also found (more) vulnerabilities in the n_gsm driver:

https://twitter.com/FFFVR_/status/1778244738833080571

> It seems there has been an interesting incident related to the n_gsm
> vector of the Linux kernel.
>
> While it's still unclear who is right and who is wrong, one thing can be
> asserted: my bug will soon be patched, and I need more caffeine.
>
> The person who first posted about this bug, jmpeax, claims to have run
> syzkaller on n_gsm. I also used syzkaller to fuzz the same vector and
> found several other vulnerabilities, not just the one in question.
>
> I've reported the vulnerabilities that have been analyzed, and I plan to
> report the remaining ones shortly. It's likely that I will soon make a
> brief post about how I analyzed n_gsm, including the fuzzing process.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=218708

> Bug 218708 - Off-by-one vulnerability when reading data from the n_gsm module
>
> j51569436 2024-04-11 01:56:38 UTC
> An off-by-one vulnerability occurs in gsm0_receive and gsm1_receive.
> I'll focus on gsm0_receive for our discussion.
>
> [1] : Write the value to gsm->buf, then increment gsm->count by 1.
> [2] : If gsm->count == gsm->len is reached, stop reading.
>
> Writing a value to a buffer and then checking its length is typical of
> off-by-one vulnerabilities.

Finally someone willing to report these bugs upstream, and there's now a
lengthy thread of comments in the above Bugzilla entry.

Also relevant is this mainline commit from August 2023:

tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=67c37756898a

which is now being backported to stable/longterm kernels:

Subject: Backport of 67c37756898a ("tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc") to older stable 
series? (at least 6.1.y)
https://lore.kernel.org/stable/ZhbiWp9DexB_gJh_ () eldamar lan/

Since there are multiple known unfixed bugs in this driver and since it
poses unjustified risk on most systems anyway, here are some mitigations
we can apply:

1. At kernel build time, don't enable CONFIG_N_GSM.

2. Unload and disallow auto-loading of the module:

rmmod n_gsm
echo blacklist n_gsm >> /etc/modprobe.d/blacklist.conf

3. Disallow auto-loading of tty line discipline modules in general:

sysctl dev.tty.ldisc_autoload = 0

4. Disallow (unprivileged) user or/and network namespaces, however this
is not expected to help on kernels without the commit referenced above!
We recently discussed other related aspects in this thread:

https://www.openwall.com/lists/oss-security/2024/04/14/1

Any one of these mitigations should be sufficient where it works, but
mitigations 2 and 3 assume the driver is built as a module (not built
into the kernel) and mitigation 4 assumes a (very) recent kernel.

Alexander