[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 Apr 2024 22:16:02 +0200
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Subject: Re: New Linux LPE via GSMIOC_SETCONF_DLCI?
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
