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/[email protected]/
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
On Tue, Apr 16, 2024 at 10:16:02PM +0200, Solar Designer wrote:
> 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
There has been lots of bugs in this driver once people started running
fuzzing on the code, which is why we applied the following patch last
year as you mention:
> 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:
It's now in the following released kernels:
4.19.312 5.4.274 5.10.215 5.15.155 6.1.86 6.6
If people are curious in helping out, here's a good summary of the
issues involved from the current maintainer of the driver:
https://lore.kernel.org/r/DB9PR10MB5881D2170678C169FB42A423E0082@DB9PR10MB5881.EURPRD10.PROD.OUTLOOK.COM
> 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/[email protected]/
>
> 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.
I recommend this one, almost no one has this hardware, it is very
specialized, so unless you have hardware that requires it, don't use it.
thanks,
greg k-h
Am 16.04.24 um 22:16 schrieb Solar Designer:
> 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:
>
FWIW, YuriiCrimson's bug for 5.15 - 6.1 seems to be patched on current
Debian:
debianexploitgsm:/tmp/ExploitGSM/ExploitGSM_5_15_to_6_1$ ./ExploitGSM debian
kallsyms restricted, begin retvial kallsyms table
detected kernel path-> /boot/vmlinuz-6.1.0-20-amd64
detected compressed format -> xz
Uncompressed kernel size -> 65900116
successfully taken kernel!
begin try leak startup_xen!
startup_xen leaked address -> ffffffff8546f1c0
text leaked address -> ffffffff83400000
lockdep_map_size -> 32
spinlock_t_size -> 4
mutex_size -> 32
gsm_mux_event_offset -> 56
Error set line discipline N_GSM, Operation not permitted
--cku