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_g...@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
