遗憾的是，我没有为这个漏洞取一个时髦又巧妙的名字。这个 bug 利用起来相当简单。我实际上把它搁置了相当长一段时间，直到我意识到它可能影响的设备比我最初想到的要多。
此漏洞影响启动 Android 启动映像的 Nvidia Tegra t114-t210 SoC，但有一个重要的区别需要说明：
基于 t114 的设备受影响严重得多，因为其统一引导加载程序同时加载 TOS（TLK - Nvidia 的安全监视器），这意味着引导加载程序已经在安全上下文中运行……
在 t124+ 设备上，Nvidia 现在使用 nvtboot 作为早期引导加载程序，在易受攻击的引导加载程序执行之前加载 TOS，而后者负责加载并执行内核。这意味着我们运行在非安全上下文中。
我们来看一下 Android 启动映像头（v1 - Android 9 之前）：
struct boot_img_hdr
{
uint8_t magic[BOOT_MAGIC_SIZE];
uint32_t kernel_size; /* size in bytes */
uint32_t kernel_addr; /* physical load addr */
uint32_t ramdisk_size; /* size in bytes */
uint32_t ramdisk_addr; /* physical load addr */
uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */
uint32_t tags_addr; /* physical addr for kernel tags */
uint32_t page_size; /* flash page size we assume */
uint32_t unused;
uint32_t os_version;
uint8_t name[BOOT_NAME_SIZE]; /* asciiz product name */
uint8_t cmdline[BOOT_ARGS_SIZE];
uint32_t id[8]; /* timestamp / checksum / sha1 / etc */
uint8_t extra_cmdline[BOOT_EXTRA_ARGS_SIZE];
};
我们看到了某些熟悉映像的字段：内核（kernel）、ramdisk：
uint32_t kernel_size; /* size in bytes */
uint32_t kernel_addr; /* physical load addr */
uint32_t ramdisk_size; /* size in bytes */
uint32_t ramdisk_addr; /* physical load addr */
有时还有 tags（通常用于设备树或 ATAGS）
uint32_t tags_addr; /* physical addr for kernel tags */
uint32_t page_size; /* flash page size we assume */
那么 'second' 字段呢？
uint32_t second_size; /* size in bytes */
uint32_t second_addr; /* physical load addr */
虽然我个人从未在生产设备上看到过它被使用，但根据我的理解，'second' 映像可以用作第二阶段引导加载程序或需要加载的附加映像。根据我的研究经验，大多数其他 OEM 的引导加载程序会忽略此字段——因为它未被使用——或者会对大小和地址进行合理性检查。
Nvidia 的引导加载程序确实会对内核、ramdisk 和 dtb 进行合理性检查——所有这些都有硬编码的加载地址，这意味着头中的加载地址会被忽略。然而，Nvidia 似乎忘记了这种几乎被遗忘的映像……在加载它对地址或大小没有任何合理性检查。没错——你可以将任何映像、任意大小加载到任何可访问的内存地址（t114 上是一切，t124+ 上是非安全内存）。
这意味着我们可以随意修补内存中的引导加载程序，以满足我们的需求。无论是想跳过签名验证（签名验证紧跟在加载所有映像之后），还是想在 t114 上劫持 TOS 的加载以获得安全上下文代码执行，或者只是加载一些 shellcode 来转储敏感信息。
利用起来非常简单：创建一个启动映像，将次要映像（'second' 映像）作为你的 payload/shellcode，并将 addr/len 字段适当设置为你的 payload 的大小以及你想让它加载到的位置。该映像最小可以只有 4 字节。
在 t124+ 设备上，我们没有安全上下文，因为 nvtboot 在启动的更早阶段已经加载了 TOS，随后将执行移交给后期引导加载程序（EBT），但我们仍然可以在内存中自由写入这个后期引导加载程序。易受攻击的引导加载程序是加载内核的那个，因此如果你想执行任意未签名代码，它仍然相当有价值。
不仅加载地址未经验证，大小也同样未被验证，这为 CVE-2019-5699 打开了大门，因为我们可以通过精心构造恶意的 secondary_size 字段来溢出各种变量/指针。不过我不能将此归功于自己，因为我只是在最初的安全公告发布之后才事后意识到这一点。而且这看起来工作量也要大得多……
t114:
IROM->BCT->EBT->TOS->KERNEL
t124+（对于更新的 64 位 SoC 可能略有不同）：
IROM->BCT->NVTBOOT->TOS->EBT->KERNEL
此问题最初于 2019 年 7 月 29 日报告给 Nvidia 的 PSIRT（产品安全事件响应团队）。他们礼貌地要求我延迟披露，直到所有相关客户都收到通知并且修复程序已推出——我很乐意地配合了。他们在整个过程中保持了沟通，并且合作起来很愉快。今天（2019 年 12 月 5 日），Nvidia 终于完成了受影响代码修复程序的发布，并发布了两份反映此问题的不同安全公告，同时还给我开了绿灯允许披露。
https://nvidia.custhelp.com/app/answers/detail/a_id/4875
https://nvidia.custhelp.com/app/answers/detail/a_id/4910
balika011
beaups
npjohnson
djrbliss/Dan Rosenberg 促使我仔细检查引导加载程序如何解析启动映像头