Coordinated Disclosure: 1-Click RCE on GNOME (CVE-2023-43641)

Today, in coordination with Ilya Lipnitskiy (the maintainer of libcue) and the distros mailing list, the GitHub Security Lab is disclosing CVE-2023-43641, a memory corruption vulnerability in libcue. We have also sent a text-only version of this blog post to the oss-security list.
今天，在与 Ilya Lipnitskiy（libcue 的维护者）和发行版邮件列表的协调下，GitHub 安全实验室披露了 CVE-2023-43641，这是 libcue 中的一个内存损坏漏洞。我们还将此博客文章的纯文本版本发送到 oss 安全列表。

It’s quite likely that you have never heard of libcue before, and are wondering why it’s important. This situation is neatly illustrated by xkcd 2347:
很可能您以前从未听说过libcue，并且想知道为什么它很重要。xkcd 2347 清楚地说明了这种情况：

libcue is a library used for parsing cue sheets—a metadata format for describing the layout of the tracks on a CD. Cue sheets are often used in combination with the FLAC audio file format, which means that libcue is a dependency of some audio players, such as Audacious. But the reason why I decided to audit libcue for security vulnerabilities is that it’s used by tracker-miners: an application that’s included with GNOME—the default graphical desktop environment of many open source operating systems.¹ The purpose of tracker-miners is to index the files in your home directory to make them easily searchable. For example, the index is used by this search bar:
libcue 是一个用于解析提示表的库，提示表是一种用于描述 CD 上曲目布局的元数据格式。提示表通常与 FLAC 音频文件格式结合使用，这意味着 libcue 是某些音频播放器（例如 Audacious）的依赖项。但我决定审核 libcue 的安全漏洞的原因是它被跟踪矿工使用：GNOME 中包含的应用程序——许多开源操作系统的默认图形桌面环境。 ¹ 跟踪器矿工的目的是索引主目录中的文件，使其易于搜索。例如，索引由以下搜索栏使用：

The index is automatically updated when you add or modify a file in certain subdirectories of your home directory, in particular including ~/Downloads. To make a long story short, that means that inadvertently clicking a malicious link is all it takes for an attacker to exploit CVE-2023-43641 and get code execution on your computer:
当您在主目录的某些子目录中添加或修改文件时，索引会自动更新，特别是包括 ~/Downloads 。长话短说，这意味着攻击者只需无意中单击恶意链接即可利用 CVE-2023-43641 并在您的计算机上执行代码：

The video shows me clicking a link in a webpage², which causes a cue sheet to be downloaded. Because the file is saved to ~/Downloads, it is then automatically scanned by tracker-miners. And because it has a .cue filename extension, tracker-miners uses libcue to parse the file. The file exploits the vulnerability in libcue to gain code execution and pop a calculator. Cue sheets are just one of many file formats supported by tracker-miners. For example, it also includes scanners for HTML, JPEG, and PDF.
该视频显示我单击网页中的链接 ² ，这会导致下载提示表。因为文件被保存到 ~/Downloads ，所以它会被跟踪矿工自动扫描。由于它具有文件扩展名，因此跟踪矿工使用libcue来解析 .cue 文件。该文件利用 libcue 中的漏洞来获取代码执行并弹出计算器。提示表只是跟踪矿工支持的众多文件格式之一。例如，它还包括用于 HTML、JPEG 和 PDF 的扫描仪。

I am delaying publication of the proof of concept (PoC) used in the video, to give users time to install the patch. But if you’d like to test if your system is vulnerable, try downloading this file, which contains a much simpler version of the PoC that merely causes a (benign) crash.
我正在延迟发布视频中使用的概念验证 （PoC），以便让用户有时间安装补丁。但是，如果您想测试您的系统是否容易受到攻击，请尝试下载此文件，其中包含一个更简单的 PoC 版本，仅导致（良性）崩溃。

The offsets in the full PoC need to be tuned for different distributions. I have only done this for Ubuntu 23.04 and Fedora 38, the most recent releases of Ubuntu and Fedora at this time. In my testing, I have found that the PoC works very reliably when run on the correct distribution (and will trigger a SIGSEGV when run on the wrong distribution). I have not created PoCs for any other distributions, but I believe that all distributions that run GNOME are potentially exploitable.
完整 PoC 中的偏移量需要针对不同的分布进行调整。我只在 Ubuntu 23.04 和 Fedora 38 上这样做过，这是目前 Ubuntu 和 Fedora 的最新版本。在我的测试中，我发现 PoC 在正确的发行版上运行时非常可靠（并且在错误的发行版上运行时会触发 SIGSEGV）。我没有为任何其他发行版创建 PoC，但我相信所有运行 GNOME 的发行版都有可能被利用。

The bug in libcue
libcue 中的错误

libcue is quite a small project. It’s primarily a bison grammar for cue sheets, with a few data structures for storing the parsed data. A simple example of a cue sheet looks like this:
libcue是一个相当小的项目。它主要是提示表的野牛语法，有一些数据结构用于存储解析的数据。提示表的简单示例如下所示：

REM GENRE "Pop, dance pop"
REM DATE 1987
PERFORMER "Rick Astley"
TITLE "Whenever You Need Somebody"
FILE "Whenever You Need Somebody.mp3" MP3
  TRACK 01 AUDIO
    TITLE "Never Gonna Give You Up"
    PERFORMER "Rick Astley"
    SONGWRITER "Mike Stock, Matt Aitken, Pete Waterman"
    INDEX 01 00:00:00
  TRACK 02 AUDIO
    TITLE "Whenever You Need Somebody"
    PERFORMER "Rick Astley"
    SONGWRITER "Mike Stock, Matt Aitken, Pete Waterman"
    INDEX 01 03:35:00

The vulnerability is in the handling of the INDEX syntax. Replacing one of those INDEX statements with this will trigger the bug:
该漏洞存在于 INDEX 语法的处理中。用这个替换其中一个 INDEX 语句将触发错误：

INDEX 4294567296 0

There are two parts to the problem. The first is that the scanner (cue_scanner.l, line 132) uses atoi to scan the integers:
这个问题有两个部分。第一个是扫描仪（cue_scanner.l，第 132 行）用于 atoi 扫描整数：

[[:digit:]]+    { yylval.ival = atoi(yytext); return NUMBER; }

atoi does not check for integer overflow, so it is easy to construct a negative index. For example, 4294567296 is converted to -400000 by atoi.
atoi 不检查整数溢出，因此很容易构造负索引。例如，4294567296 通过 转换为 atoi -400000。

The second part of the problem (and this is the actual vulnerability) is that track_set_index does not check that i ≥ 0:
问题的第二部分（这是实际的漏洞）是不 track_set_index 检查： i ≥ 0

void track_set_index(Track *track, int i, long ind)
{
    if (i > MAXINDEX) {
        fprintf(stderr, "too many indexes\n");
                return;
    }

    track->index[i] = ind;
}

If i is negative, then this code can write to an address outside the bounds of the array. Since the value of ind is also attacker-controlled, this is a very powerful vulnerability.
如果为负数，则 i 此代码可以写入数组边界之外的地址。由于 的值 ind 也是由攻击者控制的，因此这是一个非常强大的漏洞。

The bug is simple to fix by adding an extra condition to the if-statement in track_set_index. This is the proposed patch:
通过在 中的 track_set_index if 语句中添加一个额外的条件来修复该错误。这是建议的补丁：

diff --git a/cd.c b/cd.c
index cf77a18..4bbea19 100644
--- a/cd.c
+++ b/cd.c
@@ -339,7 +339,7 @@ track_get_rem(const Track* track)

 void track_set_index(Track *track, int i, long ind)
 {
-       if (i > MAXINDEX) {
+       if (i < 0 || i > MAXINDEX) {
                fprintf(stderr, "too many indexes\n");
                return;
        }

More about tracker-miners
更多关于追踪矿工的信息

I want to be clear that this bug is not a vulnerability in tracker-miners. But I have focused on tracker-miners because it magnifies the impact of this bug due to the way that it automatically scans the files in your ~/Downloads directory.
我想明确一点，这个错误不是跟踪器矿工中的漏洞。但我专注于跟踪矿工，因为它自动扫描 ~/Downloads 目录中文件的方式放大了此错误的影响。

tracker-miners consists of two processes:
跟踪矿工由两个过程组成：

1. tracker-miner-fs 跟踪器-矿工-FS
2. tracker-extract 跟踪器提取

The first, tracker-miner-fs, is a background process which is always running, whereas the second, tracker-extract, is only started on demand to scan new files. tracker-miner-fs uses inotify to monitor specific directories, such as ~/Downloads, ~/Music, and ~/Videos. When a new file is created, it launches tracker-extract to scan the file. tracker-extract sends the results back to tracker-miner-fs (which maintains the index) and then usually shuts down again after a few seconds. The vulnerability only affects tracker-extract, because that’s where libcue is used. Both processes run as the current user, so this vulnerability would need to be chained with a separate privilege escalation vulnerability for an attacker to gain admin privileges.
第一个是跟踪器-矿工-fs，是一个始终运行的后台进程，而第二个是跟踪器-提取，只是按需启动以扫描新文件。Tracker-miner-fs 使用 inotify 来监视特定目录，例如 ~/Downloads 、 ~/Music 和 ~/Videos 。创建新文件时，它会启动跟踪器提取以扫描文件。Tracker-Extract将结果发送回Tracker-Miner-FS（维护索引），然后通常在几秒钟后再次关闭。该漏洞仅影响跟踪器提取，因为这是使用libcue的地方。这两个进程都以当前用户身份运行，因此此漏洞需要与单独的权限升级漏洞链接，以便攻击者获得管理员权限。

The vulnerability will not trigger if tracker-miners is not running. To check if it is, I use the command ps aux | grep track. It usually shows that tracker-miner-fs is running and that tracker-extract isn’t. If neither is running (which I think is rare), then using the search bar (press the “super” key and type something) should automatically restart tracker-miner-fs. As far as I know, tracker-miners is quite tightly integrated into GNOME, so there’s no easy way to switch it off. There’s certainly nothing like a simple checkbox in the settings dialog. There’s some discussion here about how to switch it off by modifying your systemd configuration.
如果跟踪器矿工未运行，则不会触发该漏洞。要检查它是否是，我使用命令 ps aux | grep track .它通常显示跟踪器-矿工-fs 正在运行，而跟踪器-提取没有。如果两者都没有运行（我认为这种情况很少见），那么使用搜索栏（按“超级”键并输入一些内容）应该会自动重新启动跟踪器-矿工-fs。据我所知，跟踪矿工与GNOME非常紧密地集成在一起，所以没有简单的方法可以关闭它。设置对话框中的简单复选框肯定没有什么比这更好的了。这里有一些关于如何通过修改 systemd 配置来关闭它的讨论。

The two-process architecture of tracker-miners is helpful for exploitation. Firstly, it’s much easier to predict the memory layout in a freshly started process than in one that’s already been running for hours, so the fact that tracker-extract is only started on-demand is very convenient. Even better, tracker-extract always creates a fresh thread to scan the downloaded file, and I’ve found that the heap layout in the thread’s malloc arena is very consistent: it varies between distributions, so, for example, Ubuntu 23.04 has a slightly different layout than Fedora 38, but on the same distribution the layout is identical every single time. Secondly, because tracker-extract is restarted on demand, an attacker could potentially crash it many times until their exploit succeeds. Due to the consistency of the heap layout, I’ve found that my exploit works very reliably without needing to use this, but I could imagine an attacker loading a zip file with thousands of copies of their exploit to increase their chance of success when the victim unzips the download.
跟踪器矿工的双进程架构有助于利用。首先，在新启动的进程中预测内存布局比在已经运行数小时的进程中要容易得多，因此跟踪器提取仅按需启动的事实非常方便。更好的是，跟踪器提取总是创建一个新的线程来扫描下载的文件，我发现线程的malloc arena中的堆布局非常一致：它因发行版而异，因此，例如，Ubuntu 23.04 的布局与 Fedora 38 略有不同，但在同一发行版上，布局每次都是相同的。其次，由于跟踪器提取是按需重新启动的，因此攻击者可能会使其多次崩溃，直到其漏洞利用成功。由于堆布局的一致性，我发现我的漏洞利用非常可靠地工作，不需要使用它，但我可以想象攻击者加载一个包含数千个漏洞利用副本的 zip 文件，以增加受害者解压缩下载时成功的机会。

tracker-miners seccomp sandbox escape
追踪者-矿工 安全库沙盒逃生

The difficult part of exploiting this vulnerability was finding a way to bypass ASLR. But what I didn’t realize when I started writing the PoC, is that tracker-extract also has a seccomp sandbox which is intended to prevent this kind of exploit from working. It was a nasty surprise when I thought I had all the pieces in place for a working PoC and it failed with the error message: Disallowed syscall "close_range" caught in sandbox. But I still failed to understand that I was attempting a sandbox escape here. I just thought I needed to take a different code path that didn’t use the close_range function. So I tried a different route, it worked, and I didn’t give it any more thought until the GNOME developers asked how I’d managed to escape the sandbox. It turned out that I’d discovered the escape entirely by accident: while I was working on the new route, I unwittingly made a change to the PoC that solved it. I have since discovered that I could have got the original PoC working with a one-line change. I’ll go into more detail on this in a follow-up blog post when I publish the PoC, but for now I’ll just mention that, in response to this, Carlos Garnacho has very quickly implemented some changes to strengthen the sandbox, which will prevent this exploitation path from working in the future.
利用此漏洞的困难部分是找到绕过 ASLR 的方法。但是当我开始编写PoC时，我没有意识到的是，跟踪器提取也有一个seccomp沙箱，旨在防止这种漏洞利用起作用。当我认为我已经为工作 PoC 准备好所有部分并且它失败并显示错误消息时，这是一个令人讨厌的惊喜： Disallowed syscall "close_range" caught in sandbox .但我仍然不明白我在这里试图逃脱沙盒。我只是认为我需要采用不使用该功能 close_range 的不同代码路径。所以我尝试了一条不同的路线，它奏效了，直到 GNOME 开发人员问我是如何设法逃脱沙箱的，我才多想。事实证明，我完全是偶然发现逃逸的：当我在新路线上工作时，我不知不觉地对解决了它的 PoC 进行了更改。从那以后，我发现我可以通过单行更改来获得原始 PoC。当我发布 PoC 时，我将在后续博客文章中更详细地介绍这一点，但现在我只想提到，作为对此的回应，Carlos Garnacho 已经非常迅速地实施了一些更改来加强沙盒，这将阻止这种利用路径在未来发挥作用。

Conclusion 结论

Sometimes a vulnerability in a seemingly innocuous library can have a large impact. Due to the way that it’s used by tracker-miners, this vulnerability in libcue became a 1-click RCE. If you use GNOME, please update today!
有时，看似无害的库中的漏洞可能会产生很大的影响。由于跟踪矿工使用它的方式，libcue 中的这个漏洞变成了一键式 RCE。如果您使用 GNOME，请立即更新！

I’m delaying the release of the full PoC to give users time to install the update, but planning to publish a follow-up blog post soon with details of how the full PoC works. Save an unpatched VM with Ubuntu 23.04 or Fedora 38 if you’d like to test the full PoC when I release it.
我正在推迟完整 PoC 的发布，以便让用户有时间安装更新，但计划很快发布一篇后续博客文章，详细介绍完整 PoC 的工作原理。使用 Ubuntu 23.04 或 Fedora 38 保存未修补的 VM，如果您想在我发布时测试完整的 PoC。

Notes 笔记

文始发于Kevin Backhouse ：Coordinated Disclosure: 1-Click RCE on GNOME (CVE-2023-43641)