oss-sec mailing list archives
Re: New Linux LPE via GSMIOC_SETCONF_DLCI?
From: Solar Designer <solar () openwall com>
Date: Tue, 16 Apr 2024 22:16:02 +0200
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/mainAccording 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
Current thread:
- New Linux LPE via GSMIOC_SETCONF_DLCI? Dr. Christopher Kunz (Apr 10)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 10)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 16)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Greg KH (Apr 16)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Dr. Christopher Kunz (Apr 17)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 16)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Donald Buczek (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Dr. Christopher Kunz (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Dr. Christopher Kunz (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Kyle Zeng (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Kyle Zeng (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 11)
- Re: New Linux LPE via GSMIOC_SETCONF_DLCI? Solar Designer (Apr 10)