FWIW,
on a freshly installed and fully updated default Debian 12 VM (from the
current netinst iso), the first two exploits yield different results.
> PoC and writeup are here:
> https://github.com/YuriiCrimson/ExploitGSM/tree/main
This, let's call it "Yurii's version", works as advertised:
$ ./ExploitGSM debian
kallsyms restricted, begin retvial kallsyms table
detected kernel path-> /boot/vmlinuz-6.1.0-18-amd64
detected compressed format -> xz
Uncompressed kernel size -> 65902908
successfully taken kernel!
begin try leak startup_xen!
startup_xen leaked address -> ffffffff8c86f1c0
text leaked address -> ffffffff8a800000
lockdep_map_size -> 32
spinlock_t_size -> 4
mutex_size -> 32
gsm_mux_event_offset -> 56
Let go thread
We get root, spawn shell
root@debianexploitgsm:/root# id
uid=0(root) gid=0(root) groups=0(root)
> PoC:
> https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit/tree/main
This one, however, segfaults. I recompiled it with debugging symbols and
ran it through a quick gdb:
Reading symbols from ./ExploitGSM...
(gdb) run debian
Starting program:
/home/absynth/GSM_Linux_Kernel_LPE_Nday_Exploit/ExploitGSM debian
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Program received signal SIGSEGV, Segmentation fault.
0x00000000004324f7 in __strcmp_avx2 ()
(gdb) bt
#0 0x00000000004324f7 in __strcmp_avx2 ()
#1 0x0000000000401b5e in main (argc=2, argv=0x7fffffffe3f8) at
/home/absynth/GSM_Linux_Kernel_LPE_Nday_Exploit/main.c:552
(gdb)
Line 552 is the kernel release check, so a fairly straightforward piece
of code:
if (strcmp(iter_kernel->os_name, argv[1]) ||
strcmp(iter_kernel->kernel, kernel_info.release))
I'm not a C developer, so I'm not too sure what goes wrong here, but I
guess it's a simple fix.
With regards to Yurii's PoC, I'd say that this can indeed be classified
as a working 0day LPE in the default configuration.
We don't have a CVE for this yet, do we?
Regards,
--cku
On Thu, Apr 11, 2024 at 10:32:59AM +0200, Dr. Christopher Kunz wrote:
> on a freshly installed and fully updated default Debian 12 VM (from the
> current netinst iso), the first two exploits yield different results.
>
> >PoC and writeup are here:
> >https://github.com/YuriiCrimson/ExploitGSM/tree/main
>
> This, let's call it "Yurii's version", works as advertised:
>
> $ ./ExploitGSM debian
> kallsyms restricted, begin retvial kallsyms table
> detected kernel path-> /boot/vmlinuz-6.1.0-18-amd64
> detected compressed format -> xz
> Uncompressed kernel size -> 65902908
> successfully taken kernel!
> begin try leak startup_xen!
> startup_xen leaked address? -> ffffffff8c86f1c0
> text leaked address???????? -> ffffffff8a800000
> lockdep_map_size???? -> 32
> spinlock_t_size????? -> 4
> mutex_size?????????? -> 32
> gsm_mux_event_offset -> 56
> Let go thread
> We get root, spawn shell
> root@debianexploitgsm:/root# id
> uid=0(root) gid=0(root) groups=0(root)
There are two exploits in Yurii's repo above, according to Yurii for two
different bugs. The above is one of them. Perhaps also try the other?
> With regards to Yurii's PoC, I'd say that this can indeed be classified
> as a working 0day LPE in the default configuration.
>
> We don't have a CVE for this yet, do we?
I don't know, and apparently it'd need to be two CVEs for two bugs that
Yurii exploits.
Besides the already mentioned CVE-2023-6546, there is:
CVE-2023-52564: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
https://lists.openwall.net/linux-cve-announce/2024/03/02/54
The fixes for both CVE-2023-6546 and CVE-2023-52564 are in
gsm_cleanup_mux(), but they seem to be different changes in there.
Maybe CVE-2023-52564 is one of the bugs Yurii exploits, or maybe not.
I didn't look into this closely enough to tell.
Alexander
Hi,
> There are two exploits in Yurii's repo above, according to Yurii for two
> different bugs. The above is one of them. Perhaps also try the other?
The two exploit versions are for different kernels. The 6.5 exploit
doesn't compile on the Debian 12 6.1 kernel, and no Debian version
currently distributes a 6.5 kernel, AFAICT. I used
ExploitGSM_5_15_to_6_1/ExploitGSM and it worked.
> I don't know, and apparently it'd need to be two CVEs for two bugs that
> Yurii exploits.
Possibly. I'm definitely out of my depth trying to analyze which bugs
are being exploited.
> CVE-2023-52564: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
> https://lists.openwall.net/linux-cve-announce/2024/03/02/54
>
> Maybe CVE-2023-52564 is one of the bugs Yurii exploits, or maybe not.
> I didn't look into this closely enough to tell.
Apparently not. Debian 12 "Bookworm" currently runs this kernel:
Linux debianexploitgsm 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.76-1 (2024-02-01) x86_64 GNU/Linux
According to the changelog, this kernel has the fix for CVE-2023-52564
included:
- Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
(from
https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.76+1_changelog)
Still, the exploit works, so it must exploit a different issue.
Just my two cents,
--cku
Hi there,
I just did some preliminary analysis on this.
There are in fact three exploits involved in this.
CVE-2023-6546: https://github.com/Nassim-Asrir/ZDI-24-020/
jmpe4x's GSM exploit:
https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit
YuriiCrimson's GSM exploit: https://github.com/YuriiCrimson/ExploitGSM
I tested all of them. All of them targeted the same subsystem (GSM),
used the same KASLR leak method ("/sys/kernel/notes"). But there are
two vulnerabilities involved here.
In short. jmpe4x's and YuriiCrimson's exploits are the same, but the
vulnerability is not CVE-2023-6546.
!!!!!!!!!!!!
It is a 0day that is not patched in the main tree yet.
Not a patch gap.
!!!!!!!!!!!!
My analysis is performed on the latest commit of Linus's tree:
```
commit e8c39d0f57f358950356a8e44ee5159f57f86ec5 (HEAD -> master,
origin/master, origin/HEAD)
Merge: 03a55b63919 325f3fb551f
Author: Linus Torvalds <[email protected]>
Date: Wed Apr 10 19:48:05 2024 -0700
```
And jmpe4x's and YuriiCrimson's are exactly the same. The difference
is mostly spaces. The diff is attached to this email.
Thanks,
Kyle Zeng
On Thu, Apr 11, 2024 at 8:07 AM Dr. Christopher Kunz
<[email protected]> wrote:
>
> Hi,
>
> > There are two exploits in Yurii's repo above, according to Yurii for two
> > different bugs. The above is one of them. Perhaps also try the other?
> The two exploit versions are for different kernels. The 6.5 exploit
> doesn't compile on the Debian 12 6.1 kernel, and no Debian version
> currently distributes a 6.5 kernel, AFAICT. I used
> ExploitGSM_5_15_to_6_1/ExploitGSM and it worked.
> > I don't know, and apparently it'd need to be two CVEs for two bugs that
> > Yurii exploits.
> Possibly. I'm definitely out of my depth trying to analyze which bugs
> are being exploited.
> > CVE-2023-52564: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
> > https://lists.openwall.net/linux-cve-announce/2024/03/02/54
> >
> > Maybe CVE-2023-52564 is one of the bugs Yurii exploits, or maybe not.
> > I didn't look into this closely enough to tell.
>
> Apparently not. Debian 12 "Bookworm" currently runs this kernel:
>
> Linux debianexploitgsm 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
>
> According to the changelog, this kernel has the fix for CVE-2023-52564
> included:
> - Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
> (from
> https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.76+1_changelog)
>
> Still, the exploit works, so it must exploit a different issue.
>
> Just my two cents,
>
> --cku
>
Notice that my previous analysis on YuriiCrimson's exploits is their
ExploitGSM_6_5 version.
I cannot make the ExploitGSM_5_15_to_6_1 version work in the latest
kernel in my test environment. However, this does not rule out the
possibility that it still works.
And the splash of the ExploitGSM_6_5 exploit is attached to the email.
Thanks,
Kyle Zeng
On Thu, Apr 11, 2024 at 12:25 PM Kyle Zeng <[email protected]> wrote:
>
> Hi there,
>
> I just did some preliminary analysis on this.
> There are in fact three exploits involved in this.
> CVE-2023-6546: https://github.com/Nassim-Asrir/ZDI-24-020/
> jmpe4x's GSM exploit:
> https://github.com/jmpe4x/GSM_Linux_Kernel_LPE_Nday_Exploit
> YuriiCrimson's GSM exploit: https://github.com/YuriiCrimson/ExploitGSM
>
> I tested all of them. All of them targeted the same subsystem (GSM),
> used the same KASLR leak method ("/sys/kernel/notes"). But there are
> two vulnerabilities involved here.
> In short. jmpe4x's and YuriiCrimson's exploits are the same, but the
> vulnerability is not CVE-2023-6546.
> !!!!!!!!!!!!
> It is a 0day that is not patched in the main tree yet.
> Not a patch gap.
> !!!!!!!!!!!!
>
> My analysis is performed on the latest commit of Linus's tree:
> ```
> commit e8c39d0f57f358950356a8e44ee5159f57f86ec5 (HEAD -> master,
> origin/master, origin/HEAD)
> Merge: 03a55b63919 325f3fb551f
> Author: Linus Torvalds <[email protected]>
> Date: Wed Apr 10 19:48:05 2024 -0700
> ```
>
> And jmpe4x's and YuriiCrimson's are exactly the same. The difference
> is mostly spaces. The diff is attached to this email.
>
> Thanks,
> Kyle Zeng
>
>
> On Thu, Apr 11, 2024 at 8:07 AM Dr. Christopher Kunz
> <[email protected]> wrote:
> >
> > Hi,
> >
> > > There are two exploits in Yurii's repo above, according to Yurii for two
> > > different bugs. The above is one of them. Perhaps also try the other?
> > The two exploit versions are for different kernels. The 6.5 exploit
> > doesn't compile on the Debian 12 6.1 kernel, and no Debian version
> > currently distributes a 6.5 kernel, AFAICT. I used
> > ExploitGSM_5_15_to_6_1/ExploitGSM and it worked.
> > > I don't know, and apparently it'd need to be two CVEs for two bugs that
> > > Yurii exploits.
> > Possibly. I'm definitely out of my depth trying to analyze which bugs
> > are being exploited.
> > > CVE-2023-52564: Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
> > > https://lists.openwall.net/linux-cve-announce/2024/03/02/54
> > >
> > > Maybe CVE-2023-52564 is one of the bugs Yurii exploits, or maybe not.
> > > I didn't look into this closely enough to tell.
> >
> > Apparently not. Debian 12 "Bookworm" currently runs this kernel:
> >
> > Linux debianexploitgsm 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian
> > 6.1.76-1 (2024-02-01) x86_64 GNU/Linux
> >
> > According to the changelog, this kernel has the fix for CVE-2023-52564
> > included:
> > - Revert "tty: n_gsm: fix UAF in gsm_cleanup_mux"
> > (from
> > https://metadata.ftp-master.debian.org/changelogs//main/l/linux-signed-amd64/linux-signed-amd64_6.1.76+1_changelog)
> >
> > Still, the exploit works, so it must exploit a different issue.
> >
> > Just my two cents,
> >
> > --cku
> >