<!--X-Body-Begin-->
<!--X-User-Header-->
oss-sec
mailing list archives
<!--X-User-Header-End-->
<!--X-TopPNI-->
By Date
By Thread
</form>
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
Re: New Linux LPE via GSMIOC_SETCONF_DLCI?
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
From: Solar Designer <solar () openwall com>
Date: Tue, 16 Apr 2024 22:16:02 +0200
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
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
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
By Date
By Thread
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? 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)
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->