Finding LogoFAIL: The Dangers of Image Parsing During System Boot

Binarly REsearch team investigates vulnerable image parsing components across the entire UEFI firmware ecosystem and finds all major device manufacturers are impacted on both x86 and ARM-based devices.
Binarly REsearch 团队调查了整个 UEFI 固件生态系统中易受攻击的图像解析组件，发现所有主要设备制造商都对基于 x86 和 ARM 的设备产生了影响。

[ See previous blog post “The Far-Reaching Consequences of LogoFAIL” preview of Black Hat EU presentation ]
[ 参见之前的博客文章“LogoFAIL的深远影响”，黑帽欧盟演示预览 ]

As discussed in our previous blog, security defects in image parsers expose significant attack surfaces across the entire UEFI firmware ecosystem. Our LogoFAIL research, presented at Black Hat EU today, discusses a set of security vulnerabilities affecting all major device manufacturers on both x86 and ARM-based devices.
正如我们在之前的博客中所讨论的，图像分析器中的安全缺陷暴露了整个 UEFI 固件生态系统中的重大攻击面。我们今天在Black Hat EU上发表的LogoFAIL研究讨论了一组安全漏洞，这些漏洞影响了x86和基于ARM的设备上的所有主要设备制造商。

In this post, we discuss the motivation for the research, how we used fuzz-testing to discover this set of vulnerabilities, how we built a proof-of-concept to show the path to arbitrary code execution.
在这篇文章中，我们讨论了研究的动机，我们如何使用模糊测试来发现这组漏洞，我们如何构建概念验证来显示任意代码执行的路径。

Most image parsers exist to make it possible to display logos during boot or in BIOS setup. However, vendors introduce features, like customization of a device’s boot logo, that allow users to specify data input for these parsers. This feature creates an additional and very serious threat to the security of modern devices.
大多数映像解析器的存在使得在启动期间或在 BIOS 设置中显示徽标成为可能。但是，供应商引入了一些功能，例如自定义设备的启动徽标，允许用户为这些解析器指定数据输入。此功能对现代设备的安全性造成了额外的非常严重的威胁。

Some raw realities: 一些原始的现实：

• Every IBV (Independent BIOS Vendor) provides different format image parsers for modern systems with UEFI firmware, significantly increasing attack surface across the firmware supply chain;
  每个 IBV（独立 BIOS 供应商）都为具有 UEFI 固件的现代系统提供不同格式的映像解析器，从而显著增加了整个固件供应链的攻击面;
• In many cases, the end-user is allowed to specify the input for them via various features of logo customization, which obviously provides access to the attack surface for less privileged entities;
  在许多情况下，最终用户可以通过徽标自定义的各种功能为他们指定输入，这显然为特权较低的实体提供了对攻击面的访问;
• Processing is performed during boot, meaning DXE phase (kernel mode), where code is written in pure C language, and in many cases it is a 3rd party code without any mitigations (or almost no for ARM) applied against exploitation of binary vulnerabilities.
  处理是在启动期间执行的，这意味着 DXE 阶段（内核模式），其中代码是用纯 C 语言编写的，在许多情况下，它是没有任何缓解措施（或者几乎没有针对 ARM 应用）的第三方代码，以防止利用二进制漏洞。

Keeping in mind classical firmware supply chain complexity and its asynchronous nature, we asked ourselves: what if the graphic image parsers embedded into system firmware do not update frequently and use not only outdated but also customized versions of the common image parsing libraries?
考虑到经典固件供应链的复杂性及其异步性质，我们问自己：如果嵌入到系统固件中的图形图像解析器不经常更新，并且不仅使用过时的通用图像解析库，而且还使用自定义版本的通用图像解析库，该怎么办？

While researching image parsers, our REsearch team realized that the impact of these sightings on the entire UEFI firmware industry is significant, so we decided to reference the exposed attack surfaces as LogoFAIL.
在研究图像解析器时，我们的 REsearch 团队意识到这些发现对整个 UEFI 固件行业的影响是巨大的，因此我们决定将暴露的攻击面称为 LogoFAIL。

Identifying the attack surface of LogoFAIL
识别 LogoFAIL 的攻击面

Earlier this year, our research team looked at some of the vulnerabilities discovered by the Binarly Transparency Platform and found that the number of image parsers have significantly increased over the years.
今年早些时候，我们的研究团队研究了Binarly透明平台发现的一些漏洞，发现图像解析器的数量多年来显着增加。

• Insyde-based firmware usually but not always contains parsers for BMP, GIF, JPEG, PCX, PNG, and TGA. Those are stored in separate modules called, e.g., BmpDecoderDxe:
  基于系微的固件通常（但并非总是）包含 BMP、GIF、JPEG、PCX、PNG 和 TGA 的解析器。它们存储在称为 BmpDecoderDxe 的单独模块中：
  
• AMI-based firmware contains image parsers in a DXE module called AMITSE. Every firmware we analyzed contained between a single BMP parser (e.g., Dell firmware) to a set of parsers for BMP, PNG, JPEG, and GIF (e.g., Lenovo).
  基于 AMI 的固件在名为 AMITSE 的 DXE 模块中包含图像解析器。我们分析的每个固件都包含单个BMP解析器（例如戴尔固件）到一组BMP、PNG、JPEG和GIF解析器（例如Lenovo）。
  
• Phoenix-based firmware stores its parsers in a module called SystemImageDecoderDxe, and it can usually parse BMP, GIF, and JPEG.
  基于 Phoenix 的固件将其解析器存储在名为 SystemImageDecoderDxe 的模块中，它通常可以解析 BMP、GIF 和 JPEG。
  

To identify how image data can reach the code in each parser, we used a bottom-up approach: starting from the image parsing function, we then just look “backwards” to find the sources of image data.
为了确定图像数据如何到达每个解析器中的代码，我们使用了一种自下而上的方法：从图像解析函数开始，然后我们只需“向后看”即可找到图像数据的来源。

For example, in the previous screenshot, the ParseImage() function receives the output of the GetImage() function exported by EfiOemBadgingProtocol. By further analyzing GetImage(), we can understand how the ImageData variable is created and thus where the logo image is read from.
例如，在前面的屏幕截图中，该 ParseImage() 函数接收 EfiOemBadgingProtocol 导出的 GetImage() 函数的输出。通过进一步分析 GetImage() ，我们可以了解 ImageData 变量是如何创建的，从而了解从哪里读取徽标图像。

Normally, the logo is read directly from a firmware volume. Since the volumes are often signed and protected by a hardware-based Verified Boot technology (e.g., Intel Boot Guard), an attacker cannot store a custom logo there — that’s it, as long as the OEM private keys used to sign these sections are not leaked affecting the entire industry. But in this case, an attacker wouldn’t care about the logo at all, because it allows them to inject any custom modules instead.
通常，徽标是直接从固件卷中读取的。由于这些卷通常由基于硬件的启动验证技术（例如英特尔 Boot Guard）进行签名和保护，因此攻击者无法将自定义徽标存储在那里 — 仅此而已，只要用于签署这些部分的 OEM 私钥不会泄露，从而影响整个行业。但在这种情况下，攻击者根本不关心徽标，因为它允许他们注入任何自定义模块。

In other cases, OEM-specific customizations allow users to supply their own logo, so attackers can do that too. Most of these OEMs-specific customization read the logo from the EFI System Partition (ESP), a disk partition that is used by system firmware to load additional software such as boot loaders.
在其他情况下，特定于 OEM 的自定义允许用户提供自己的徽标，因此攻击者也可以这样做。这些特定于 OEM 的自定义项中的大多数都从 EFI 系统分区 （ESP） 读取徽标，ESP 是系统固件用来加载其他软件（如启动加载程序）的磁盘分区。

Given its role in the UEFI boot process, the ESP has been targeted by modern UEFI bootkits (such as ESPecter and FinSpy) by replacing OS bootloaders and achieving persistency.
鉴于 ESP 在 UEFI 启动过程中的作用，ESP 已成为现代 UEFI 启动工具包（如 ESPecter 和 FinSpy）的目标，它取代了操作系统引导加载程序并实现了持久性。

Our advisories BRLY-2023-006 and BRLY-2023-018 contain a complete overview of the OEM-specific customizations we found, but in general we observed the following behaviors:
我们的公告 BRLY-2023-006 和 BRLY-2023-018 包含我们发现的特定于 OEM 的自定义的完整概述，但总的来说，我们观察到以下行为：

1. The logo is read from a fixed location on the ESP, such as from “\EFI\OEM\Logo.jpg”;
   徽标是从 ESP 上的固定位置读取的，例如 from “\EFI\OEM\Logo.jpg” ;
2. The OEM/IBV provides vendor-specific integrator tooling that can install a custom logo in a firmware capsule and flash the capsule from the OS;
   OEM/IBV 提供特定于供应商的集成商工具，可以在固件封装中安装自定义徽标，并从操作系统刷新封装;
3. An NVRAM variable contains an ESP path where the logo is read from;
   NVRAM 变量包含从中读取徽标的 ESP 路径;
4. The logo itself is stored inside an NVRAM variable in a compressed form.
   徽标本身以压缩形式存储在 NVRAM 变量中。

These customization features represent a new attack surface because they allow attackers to modify the logo parsed during system boot and mount data-only attacks.
这些自定义功能代表了一种新的攻击面，因为它们允许攻击者修改在系统启动期间分析的徽标并装载仅数据攻击。

Keep in mind that even when none of the above customization methods are available, a device can still be exploited with a physical attack if the firmware region containing the logo is not covered by Boot Guard. In this case, the attack can be performed using an SPI flash programmer to inject the logo.
请记住，即使上述自定义方法都不可用，如果包含徽标的固件区域未被 Boot Guard 覆盖，设备仍可能被物理攻击利用。在这种情况下，可以使用SPI闪存编程器来注入徽标来执行攻击。

Certainly, this attack vector is worth being thoroughly researched to help the industry protect from such threats. However, the amount of code to be analyzed is huge, and for this reason, we decided to expand Binarly’s internal program analysis framework, which empowers our products and supports instrumentation with emulation, to help manage this task. We were able to find all the documented vulnerabilities via fuzz-testing.
当然，这种攻击媒介值得深入研究，以帮助行业抵御此类威胁。但是，要分析的代码量非常大，因此，我们决定扩展 Binarly 的内部程序分析框架，该框架为我们的产品提供支持，并通过仿真支持检测，以帮助管理此任务。我们能够通过模糊测试找到所有记录在案的漏洞。

The sheer volume and severity of security problems we found during this research is further proof of the endemic security problems that affect the firmware supply chain ecosystem:

PS: This table does not cover all vendors in the device manufacturing industry. Our main priority was to research major UEFI IBVs, since the vulnerable parsers are in the codebase maintained by them as shown in the picture below.

We are constantly expanding our firmware dataset to improve coverage and detection capabilities of the Binarly Transparency Platform. It allowed us to determine that image parsers are common in device’s firmware. They are used to process not only most popular image formats like BMP, PNG and JPEG, but also more esoteric and less-known formats such as PCX and TGA. And all of them contain multiple high-impact security vulnerabilities.

Finding Bugs in Image Parsers

Allowing users, and thus potentially attackers, to customize their boot logo would be a totally acceptable behavior if the image libraries used to parse the logo did not contain any security flaws. To prove this point, we decided to run a fuzzer against these parsers, as fuzz-testing is very suited for finding bugs in parsing code. Our fuzzer is based on emulation capabilities that we developed for this research, which were specifically designed to be easily integrated with the modern fuzzing environment LibAFL.

After this, we prepared a fuzzing harness for every parser we discovered. The harness is a crucial component for fuzzing, since it initializes the environment and allows the fuzzer to interact with the program under test. In our case, the harness receives an image generated by the fuzzer, invokes the parsing function by setting the correct arguments and then checks for any crashes.

We then started a fuzzing campaign and fuzzed each parser for a variable period of time depending on the parser’s complexity. When the campaign finished, we were overwhelmed by the amount of crashes we found, so much that triaging them manually was going to be challenging. For this reason, we decided to expand Binarly’s internal program analysis framework, which empowers our products and supports instrumentation with emulation, to support us in this task.
然后，我们开始了模糊测试活动，并根据解析器的复杂性对每个解析器进行可变时间段的模糊测试。活动结束后，我们发现的崩溃数量太多了，以至于手动对它们进行分类将具有挑战性。出于这个原因，我们决定扩展Binarly的内部程序分析框架，该框架为我们的产品提供支持，并通过仿真支持仪器，以支持我们完成这项任务。

The table above breaks down the triaged crashes per vendor and image parser. In total, we found 29 unique crashes, out of which we consider 15 to be exploitable with arbitrary code execution as a likely outcome.

These results also show the scope and the impact of LogoFAIL, since each IBV has at least one exploitable bug inside their parsers, and every parser contains bugs. The only exception is Insyde’s PNG parser that is based on an open-source project, and was likely already well-tested by the community. As we can see from the CWE column, we found a lot of different bug classes, from division-by-zero exceptions to NULL pointer dereference, from out-of-bounds reads to heap overflows.

Root Causes

This triaging process gave us a good understanding of the root causes behind these vulnerabilities. While they cover a wide range of software security problems, the underlying theme is a lack of validation on attacker-supplied data.

For example, the first screenshot shows a bug in the BMP parser of Insyde. This bug is present in the code supporting the RLE4/RLE8 compression, a feature we haven’t seen in any other BMP parsers. This vulnerability manifests itself when PixelHeight (which is under the control of the attacker) and the variable i is 0. In this case, the variable Blt will be initialized to the address of BltBuffer[PixelWidth * -1]. In other words, the attacker can arbitrarily set Blt to any address below BltBuffer, and thus corrupt this memory when Blt is used to write.

The second screenshot is taken from the PNG parser of AMI and contains two different security vulnerabilities. The first bug is a missing check on the return value of the “EfiLibAllocateZeroPool” function, which returns NULL on failure. The second bug is an integer overflow on the 32-bit integer representing the allocation size. When the attacker sets the variable “PngWidth” to a large value, the multiplication by two will make the result overflow around and become a small value (for example: 0x80000200 * 2 = 0x400). In this way, the attacker can force the allocation of a buffer that is too small to hold the decoded PNG data and thus overflow the buffer when it is used.

The results from our fuzzing and subsequent bug triaging unequivocally say that none of these image parsers were ever tested by IBVs or OEMs. We can confidently say this because we found crashes in almost every parser we tested. Moreover, the fuzzer was able to find the first crashes after running just for a few seconds and, even worse, certain parsers were crashing on valid images found on the Internet.

Developing a Proof-of-Concept

In the firmware ecosystem, any bug can have profound consequences on the entire platform security and must therefore be addressed and fixed promptly. We decided to prove the severity of our findings by turning one of the crashes found by the fuzzer into arbitrary code execution during the DXE phase. We decided to postpone the release of the nitty-gritty details behind our PoC to give more time to end-users and vendors to patch and mitigate LogoFAIL.

The crash we selected as a starting point for developing the exploit is the integer overflow in the PNG parser discussed in the previous section. This picture shows a high-level overview of how this PNG parser works. Starting from the PNG image, the parser first locates and extracts the PNG chunks of the image. In particular, it finds the IHDR chunk to retrieve some information regarding the image, such as the width and height, and it concatenates all the IDAT chunks, which contains the PNG image data, into a single buffer (called “Compressed IDAT chunks” in the previous figure). The parser then decompresses the compressed IDAT chunks and writes the results to the “OutputBuffer.”
我们选择作为开发漏洞利用的起点的崩溃是上一节中讨论的 PNG 解析器中的整数溢出。这张图片显示了此 PNG 解析器工作原理的高级概述。从 PNG 图像开始，解析器首先定位并提取图像的 PNG 块。具体而言，它查找 IHDR 块以检索有关图像的一些信息（如宽度和高度），并将所有包含 PNG 图像数据的 IDAT 块连接到单个缓冲区中（在上图中称为“压缩 IDAT 块”）。然后，解析器解压缩压缩的 IDAT 块，并将结果写入“OutputBuffer”。

The value affected by the integer overflow depends on the image width (so it’s attacker controlled) and it’s used as an allocation size for the OutputBuffer. The attacker is therefore able to allocate an OutputBuffer that is too small and that will be overflown with attacker-controlled data during the decompression phase. By using this bug, it’s straightforward to overflow an arbitrary amount of attacker-controlled data on the UEFI heap.
受整数溢出影响的值取决于图像宽度（因此它由攻击者控制），它用作 OutputBuffer 的分配大小。因此，攻击者能够分配一个太小的 OutputBuffer，并且在解压缩阶段，攻击者控制的数据会溢出该缓冲区。通过使用此 bug，可以直接在 UEFI 堆上溢出任意数量的攻击者控制的数据。

From heap overflow to arbitrary code execution, the road is still long and winding. For now, we just want to anticipate that it involves a new exploitation technique for preserving allocated chunks and the corruption of core UEFI objects (PROTOCOL_ENTRY) to hijack the control flow.
从堆溢出到任意代码执行，道路依然漫长曲折。现在，我们只想预测它涉及一种新的利用技术，用于保留分配的块和核心 UEFI 对象 （ PROTOCOL_ENTRY ） 的损坏以劫持控制流。

As a proof of all we said in this blog, and in particular in this last section, we release the following video showing how an exploitation chain for LogoFAIL looks on a real device. After logging in, we start a terminal with Admin privileges. We then check that Secure Boot and Intel Boot Guard (Verified Boot) are enabled, and run the proof of concept. The PoC prepares some of the aforementioned objects, saves the malicious PNG file inside an NVRAM variable, and finally restarts the device. During the boot, the system firmware will parse the injected PNG and so the LogoFAIL attack will take place. In the video we demonstrate arbitrary code execution during DXE phase by printing a message on the display and by showing that our final payload is able to create a file on the Windows file system.
为了证明我们在本博客中所说的一切，特别是在最后一节中，我们发布了以下视频，展示了 LogoFAIL 的漏洞利用链在真实设备上的外观。登录后，我们启动一个具有管理员权限的终端。然后，我们检查是否启用了安全启动和英特尔启动防护（已验证启动），并运行概念验证。PoC 准备上述一些对象，将恶意 PNG 文件保存在 NVRAM 变量中，最后重新启动设备。在启动过程中，系统固件将解析注入的 PNG，因此会发生 LogoFAIL 攻击。在视频中，我们演示了 DXE 阶段的任意代码执行，方法是在显示屏上打印一条消息，并显示我们的最终有效负载能够在 Windows 文件系统上创建文件。

How do LogoFAIL vulnerabilities work?
LogoFAIL漏洞如何工作？

Since the vulnerable parsers are developed and distributed by the IBVs – AMI, Insyde and Phoenix – a large percentage of devices UEFI firmware image out there contains a parser vulnerable to LogoFAIL. This is also confirmed by the data our platform constantly scans. Thanks to our triaging efforts, we were able to produce rules for fwhunt, our firmware vulnerability scanner, and confirm that every OEM is impacted by this supply chain problem. As we can see in the following table, we detected parsers vulnerable to LogoFAIL in hundreds of devices sold by Lenovo, Supermicro, MSI, HP, Acer, Dell, Fujitsu, Samsung and Intel.
由于易受攻击的解析器是由 IBV（AMI、Insyde 和 Phoenix）开发和分发的，因此很大一部分设备 UEFI 固件映像包含易受 LogoFAIL 攻击的解析器。我们的平台不断扫描的数据也证实了这一点。由于我们的分类工作，我们能够为我们的固件漏洞扫描程序 fwhunt 制定规则，并确认每个 OEM 都受到此供应链问题的影响。如下表所示，我们在联想、Supermicro、MSI、HP、宏碁、戴尔、富士通、三星和英特尔销售的数百台设备中检测到容易受到 LogoFAIL 攻击的解析器。

The exploitability of these vulnerabilities relies on whether the user is able to input data to a parser. When these parsers are used to display a logo during boot and when this logo can be replaced by an attacker, using any of the OEM customization techniques described in the Attack Surface section of this blogpost, then LogoFAIL becomes an exploitable threat. And there are multiple scenarios that could lead to it:

1. We found that certain vendors such as Lenovo, Intel and Acer allow users – and so attackers – to customize the logo shown during boot. It could be simply done via placing it into ESP (EFI System Partition) and adding or modifying certain variables in NVRAM, then rebooting the system. Administrator privileges are enough to perform this. In this case, hardware-based Verified Boot security features such as Intel Boot Guard or AMD Hardware-Validated Boot won’t protect against it since the logo is read outside the range covered by these.
   我们发现某些供应商（如联想、英特尔和宏碁）允许用户（以及攻击者）自定义启动期间显示的徽标。只需将其放入 ESP（EFI 系统分区）并在 NVRAM 中添加或修改某些变量，然后重新启动系统即可完成。管理员权限足以执行此操作。在这种情况下，基于硬件的验证启动安全功能（如 Intel Boot Guard 或 AMD 硬件验证启动）将无法防止它，因为徽标的读取范围超出了这些功能所涵盖的范围。

   This attack vector can give an attacker an advantage in bypassing most endpoint security solutions and delivering a stealth firmware bootkit that will persist in an ESP partition or firmware capsule with a modified logo image. Technically, from a high-level perspective, the attack can be simplified into three steps, shown in the picture below.
   此攻击媒介可使攻击者在绕过大多数端点安全解决方案并提供隐身固件启动套件方面具有优势，该启动套件将保留在 ESP 分区或固件胶囊中，并带有修改后的徽标图像。从技术上讲，从高层次的角度来看，攻击可以简化为三个步骤，如下图所示。

   

2. Another discovered way to customize the logo is the firmware update procedure, for example, using AMI tool: it allows patching firmware capsules in PFAT format and then flash firmware capsules in PFAT format. This is possible in case the logo is not a part of any signed block.
   自定义徽标的另一种发现方法是固件更新过程，例如，使用 AMI 工具：它允许修补 PFAT 格式的固件胶囊，然后以 PFAT 格式刷新固件胶囊。如果徽标不是任何签名块的一部分，这是可能的。
3. When there is no expected way to customize the logo, it is still possible via physical attack vector: just with an SPI flash programmer if a logo is not covered with any hardware-based Verified Boot technology like Intel Boot Guard or AMD Hardware-Validated Boot.
   当没有预期的方法来自定义徽标时，仍然可以通过物理攻击媒介进行自定义：如果徽标未覆盖任何基于硬件的验证启动技术（如英特尔 Boot Guard 或 AMD 硬件验证启动），则只需使用 SPI 闪存编程器。

The main restriction of latter cases are explained in the following pictures. Some vendors such as Dell are not directly exploitable for two reasons. First, as shown in the previous screenshots, Dell distributes firmware where the logo is covered by Intel Boot Guard and thus cannot be replaced by an attacker, even using a physical attack. Second, Dell doesn’t provide any logo customization and so it effectively secures the LogoFAIL attack surface. However, despite these devices not being at immediate risk, they still contain image parsers with high-severity vulnerabilities that need to be fixed, as they represent a hazard that could inadvertently turn into a security issue.
后一种情况的主要限制如下图所示。由于两个原因，某些供应商（如戴尔）无法直接利用。首先，如前面的屏幕截图所示，戴尔分发的固件的徽标被英特尔 Boot Guard 覆盖，因此即使使用物理攻击也无法被攻击者替换。其次，戴尔不提供任何徽标自定义，因此它有效地保护了 LogoFAIL 攻击面。然而，尽管这些设备没有立即面临风险，但它们仍然包含具有需要修复的高严重性漏洞的图像解析器，因为它们代表了可能无意中变成安全问题的危险。

What are the implications of LogoFAIL?
LogoFAIL的含义是什么？

Some important things to keep in mind:
要记住的一些重要事项：

1. These vulnerabilities can compromise the entire system’s security, rendering “below-the-OS” security measures like any shade of Secure Boot ineffective, including Intel Boot Guard. This level of compromise means attackers can gain deep control over the affected systems.
   这些漏洞可能会危及整个系统的安全性，使“操作系统下”的安全措施（如任何安全启动）无效，包括英特尔 Boot Guard。这种程度的入侵意味着攻击者可以深入控制受影响的系统。
2. We’ve previously seen attackers abusing ESP partitions multiple times to modify operating system-related bootloaders to deliver UEFI bootkits (including BlackLotus). The LogoFAIL case creates a different perspective on the ESP partition attack surface with data-only exploitation by modifying the logo image. The comparison of LogoFAIL to most known recent threats is summarized in the following table.
   我们之前曾看到攻击者多次滥用 ESP 分区来修改与操作系统相关的引导加载程序以提供 UEFI 引导套件（包括 BlackLotus）。LogoFAIL 案例通过修改徽标图像，通过仅数据利用，在 ESP 分区攻击面上创建了不同的视角。下表总结了 LogoFAIL 与最近已知威胁的比较。

   Attack Vector 攻击媒介	Vulnerability ID 漏洞 ID	Exploited 利用 In-The-Wild 野外	Impact 冲击	CVSS CVSS的 Score 得分	CWE
   LogoFAIL 徽标失败	VU#811862	N/A	Intel Boot Guard and Secure Boot Bypass 英特尔启动卫士和安全启动旁路	High 高 Medium 中等	CWE-122: Heap-based Buffer Overflow CWE-122：基于堆的缓冲区溢出 CWE-125:Out-of-bounds Read CWE-125：越界读取
   Baton Drop 接力棒掉落	CVE-2022-21894 CVE-2022-21894 漏洞 CVE-2023-24932 CVE-2023-24932 漏洞	BlackLotus 黑莲花	Secure Boot Bypass 安全启动绕过	6.7 Medium 中等	CWE-358: Improperly Implemented Security Check for Standard CWE-358：未正确实施标准安全检查
   3rd-party Bootloaders 第三方引导加载程序	VU#309662	N/A	Secure Boot Bypass 安全启动绕过	6.7 Medium 中等	CWE-358: Improperly Implemented Security Check for Standard CWE-358：未正确实施标准安全检查
   BootHole BootHole（靴子孔）	VU#174059	N/A	Secure Boot Bypass 安全启动绕过	8.2 High 高	CWE-120: Buffer Copy without Checking the Size of Input CWE-120：在不检查输入大小的情况下进行缓冲区复制

   As we can see, a LogoFAIL differs from BlackLotus or BootHole threats because it doesn’t break runtime integrity by modifying the bootloader or firmware component. In this case, we are dealing with continued exploitation with a modified boot logo image, triggering the payload delivery in runtime, where all the integrity and security measurements happen before the firmware components are loaded.
   正如我们所看到的，LogoFAIL 与 BlackLotus 或 BootHole 威胁不同，因为它不会通过修改引导加载程序或固件组件来破坏运行时的完整性。在本例中，我们正在处理使用修改后的启动徽标图像的持续漏洞，在运行时触发有效负载交付，其中所有完整性和安全性测量都发生在加载固件组件之前。

   

   We can see from the figure above that any compromised signed UEFI component can break and bypass secure boot integrity without being detected by platform integrity or Secure Boot related mitigations. Existing device security measurements can effectively detect other threats from the comparison table.
   从上图中可以看出，任何已泄露的签名 UEFI 组件都可能破坏和绕过安全启动完整性，而不会被平台完整性或与安全启动相关的缓解措施检测到。现有的设备安全度量可以有效地检测比较表中的其他威胁。

3. Since LogoFAIL targets UEFI specific code, this new threat is not confined to a single architecture, but it’s instead another example of cross-silicon exploitation that affects both x86 and ARM devices.
   由于 LogoFAIL 针对的是 UEFI 特定代码，因此这种新威胁并不局限于单一架构，而是影响 x86 和 ARM 设备的跨硅利用的另一个示例。

   The Binarly Transparency Platform uniquely detects LogoFAIL vulnerable components in system firmware, and all our customers are informed about the impact on their code bases or enterprise infrastructure.
   Binarly 透明平台可独特地检测系统固件中的 LogoFAIL 易受攻击的组件，并告知我们所有的客户对其代码库或企业基础设施的影响。

   

   

原文始发于Binarly：Finding LogoFAIL: The Dangers of Image Parsing During System Boot