Received-SPF: pass (google.com: domain of oss-security-return-30033-linux.lists.archive=gmail.com@lists.openwall.com designates 193.110.157.125 as permitted sender) client-ip=193.110.157.125;
Mailing-List: contact oss-security-help@lists.openwall.com; run by ezmlm
Precedence: bulk
Reply-To: oss-security@lists.openwall.com
Date: Tue, 16 Apr 2024 22:16:02 +0200
From: Solar Designer <solar@openwall.com>
To: oss-security@lists.openwall.com
Message-ID: <20240416201602.GA21501@openwall.com>
References: <607d5716-128f-44c5-ab52-6dde4ca6e8a4@christopher-kunz.de> <20240410211457.GA20881@openwall.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240410211457.GA20881@openwall.com>
User-Agent: Mutt/1.4.2.3i
Subject: Re: [oss-security] 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