深蓝洞察

在网络安全领域，漏洞披露一直被视为保护用户的重要环节，但在现实中，这一过程却充满了争议和矛盾。究竟什么才算得上"负责任的披露"？当厂商在信息公开和补丁发布上占据主导地位，而安全研究者则需要耗费大量精力进行沟通与博弈，这一模式是否还能真正实现保护用户安全的初衷？在技术快速演进、网络威胁不断升级的今天，传统的漏洞披露机制是否已跟不上时代的步伐？ 本报告将以近期引发广泛讨论的漏洞披露事件为切入点，探讨当前责任披露过程中存在的问题，试图寻找一种更为公平、高效且能平衡各方利益的解决路径。 以下为本期《深蓝洞察 | 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 https://x.com/evilsocket/status/1838169889330135132 https://www.akamai.com/blog/security-research/guidance-on-critical-cups-rce https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I https://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8 https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-p9rh-jxmq-gq47 https://project-zero.issues.chromium.org/issues/368695689 https://x.com/guhe120/status/1856844617846817004

在攻防对抗日益激烈的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） 安全防护软件为实现更好的防护效果深入操作系统底层，拥有系统权限。然而，这种高权限的安全软件一旦被攻破，攻击者即可利用其权限执行任意操作。 ...

近年来，漏洞攻防不断演进。从多年前仅需一个栈溢出就能攻破系统，到如今需要运用各种精妙的手法来突破系统的层层防御。“盾"与"矛"始终处于动态对抗：每当新的防御措施出现，新的攻击手段随之而来。防御机制的升级促使攻击者寻找新的突破口，而攻击方法的创新又推动着防御技术的进一步发展。 以下为本期《深蓝洞察 | 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系统版本。 大胆猜测，内存漏洞难以利用后，未来之"矛"或许就隐藏在各种逻辑漏洞、供应链攻击之下。 ...

看到了软件的源码，就意味着没有后门吗？ 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应该无法从密码爆破这个现象观察到有明显的时间差异。 ...

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年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锐评 微软对狂躁许可漏洞"几乎不可能利用"的傲慢断言，折射出安全行业长期存在的评估悖论：当漏洞评级体系脱离攻击者视角，便沦为自欺欺人的技术乌托邦。 防御者用静态指标丈量动态攻防，用理论模型否定实战可能，恰是安全防御最大的盲区。此次漏洞利用链突破多重内存防护的实践证明，安全评估不应是厂商的"免责声明"，而应成为攻防对抗的动态标尺。若不能正视攻击者"技术暴力"的突破能力，再完美的缓解措施都将沦为数字时代的马奇诺防线。

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 没有自己报告漏洞呢？ ...

基于浏览器漏洞的攻击，自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的安全或许无法做到"绝对防御"，但却可以通过这种系统化的策略，将威胁持续降低至可接受的范围，赢取用户的信任，让安全成为产品的核心竞争力。 ...

在《深蓝洞察 | 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)等存在较大攻击面的功能隔离于用户态，以牺牲较少量的性能换取了更高的安全性。 ...