iOS 27 沙箱逃逸可破坏 MDM 监管？手机租赁行业的风险与 MDM 防护方案深度解析
引言：这一次，问题已经不仅仅是“某个 App 逃出了沙箱”
近几年，Apple 持续强化 iOS 的系统完整性、代码签名、App Sandbox、监督模式、Automated Device Enrollment、Activation Lock 和 MDM 管理能力。
对于普通用户而言，iPhone 一直被认为是安全边界相对较强的消费电子设备。
但对于手机租赁行业来说，安全问题从来不能只按照普通消费者的威胁模型来考虑。
因为租赁设备有一个非常特殊的特点：
设备的所有权属于租赁商家，但设备的长期物理控制权在用户手中。
这意味着极少数恶意用户不仅拥有设备，而且有充足时间研究系统版本、漏洞、第三方工具以及各种解除监管的方法。
近期公开出现的 FilzaSlop 再次把这一问题推到了行业面前。
FilzaSlop 的公开项目说明显示，它可以利用特定漏洞在部分 iOS 18、iOS 26 以及 iOS 27 Beta 1–4 环境获得超出普通 App Sandbox 的文件访问能力，并访问部分 App Container 和系统相关 Container。
而经过 MDM.Plus 安全团队在隔离测试环境中的实际验证，风险比简单的“访问更多文件”更加值得租赁行业警惕：
在特定受影响版本和测试条件下，FilzaSlop 获得沙箱外访问能力后，可以进一步破坏设备上的 MDM 管理注册状态，使一台原本已经受到监督和 MDM 管理的设备失去正常 MDM 管理关系。
需要特别说明的是：
“利用 FilzaSlop 破坏 MDM 管理状态”是 MDM.Plus 安全团队的内部实机测试结论，不是 FilzaSlop 项目官方对外声明的功能。
本文也不会公开具体删除路径、操作步骤或利用方法。
我们更希望讨论一个比漏洞本身更重要的问题：
当操作系统自身的安全边界可以被突破时，手机租赁行业应该如何重新设计 MDM 安全体系？
一、首先明确：FilzaSlop 到底是什么？
Apple 的 App Sandbox 是 iOS 最基础的安全机制之一。
正常情况下，每一个第三方应用只能访问被系统授权的数据和自己的应用容器，不能随意读取其他应用数据，更不能任意修改系统区域。Apple 对 Sandbox 的设计目标描述得非常明确：限制第三方 App 收集或修改其他 App 的信息，并阻止 App 对设备进行未经授权的修改。
可以把它简单理解为：
每个 App 都被关在一个独立的房间里。
正常 App 只能操作自己的文件。
而所谓 Sandbox Escape——沙箱逃逸，就是应用通过系统漏洞突破这堵墙，获得原本不应该拥有的访问能力。
FilzaSlop 的公开 GitHub 项目明确标注：
支持针对 iOS 18、iOS 26 以及 iOS 27 Beta 1–4 的 Sandbox Escape，并提供 App Container Access。
它的公开版本甚至已经以 unsigned IPA 形式发布。
也就是说：
这已经不是只有专业安全研究机构内部才能接触到的 PoC。
而是一类正在公开传播的工具。
二、为什么这次风险与传统所谓的“MDM Bypass”完全不同？
过去网络上经常有人讨论：
MDM Bypass。
但其中很多所谓“Bypass”，严格来说并没有真正破坏已经完成注册的 MDM 安全边界。
例如某些历史方案可能只是：
绕过 Setup Assistant 中的 Remote Management 页面；
阻断设备访问 MDM Server；
通过网络方式让注册流程暂时无法完成；
让用户暂时看不到部分管理界面；
或者在设备尚未完成 Enrollment 时绕过部分流程。
这些问题当然也需要处理。
但它们和：
一台已经完成 Supervision + Enrollment + MDM Management 的设备，在正常运行过程中，被本地应用直接破坏其 MDM 管理状态
不是同一个等级的问题。
经过 MDM.Plus 安全团队测试，我们关注到的正是后者。
设备原本已经：
完成监督模式；
成功注册 MDM；
与 MDM Server 建立管理关系；
关键监管策略已经生效。
但是在存在系统漏洞的情况下，攻击 App 突破 Sandbox 后，能够进一步影响设备本地的 MDM 管理状态。
这意味着传统租赁 MDM 中一个非常重要的安全假设需要重新审视：
“不可由普通用户删除的 MDM 描述文件”，并不意味着在操作系统存在高权限漏洞的情况下仍然绝对不可破坏。
Apple 官方仍然将 Supervision 定义为组织拥有设备获得额外配置和限制能力的重要基础。
但是 Supervision 和不可移除管理解决的是：
正常系统安全边界内，用户是否有权限解除管理。
它并不能代表：
操作系统出现漏洞以后，本地安全状态仍然绝对无法被修改。
这两者必须区分。
三、为什么对手机租赁行业而言，这接近“资产级”风险？
如果发生在普通企业办公设备上，Sandbox Escape 首先是一个企业信息安全问题。
但发生在租赁设备上，它很容易进一步变成：
资产安全问题。
因为企业 MDM 与租赁 MDM 的威胁模型完全不同。
企业员工通常没有明确的经济动力去攻击自己的办公设备。
但对于租赁设备而言：
一台价值数千元甚至上万元的 iPhone，长期掌握在承租人手中。
如果恶意用户能够通过一个公开工具解除 MDM 管理，那么他可能直接获得经济利益。
因此攻击者的动机完全不同。
传统企业设备安全模型可能是：
设备所有者 ≈ 设备使用者 ≈ 信任主体。
而租赁行业实际上是：
设备所有者 ≠ 设备使用者。
这意味着租赁设备必须按照一种更加接近：
Adversarial Device Environment——潜在对抗性设备环境
来设计安全体系。
系统不能只考虑：
“正常用户会怎么使用手机？”
还必须考虑：
“如果有人主动研究怎么破坏监管，他能够做到什么？”
四、为什么 iOS 27 的问题容易扩大成“设备池风险”？
这里需要避免一个容易产生误解的说法：
不能说所有 iPhone 当前都存在同一个 iOS 27 漏洞。
截至目前公开资料，FilzaSlop 项目明确标注的 iOS 27 支持范围是 Beta 1–4。
另一个公开的 iOS 27 研究项目开发者则表示，相关 Sandbox Escape 在 Beta 5 中已经被修补。需要强调，这是安全研究社区的公开判断，并非 Apple 针对 FilzaSlop 发布的官方漏洞公告。
但对于租赁行业来说，真正的问题并不是：
“正式版 iOS 27 是否永久存在某一个具体漏洞？”
而是：
一旦某个可被利用的系统版本覆盖大量主流租赁机型，恶意用户就可能主动寻找进入这个版本窗口的方法。
手机租赁行业的库存通常不是只有最新一代 iPhone。
而是同时存在多代设备。
一个覆盖多代硬件的系统漏洞，其风险不会只影响“某一个型号”。
它影响的是：
整个兼容设备池的潜在攻击面。
所以 MDM 平台以后不能只关注：
设备是否在线；
设备是否受管；
Activation Lock 是否打开。
还必须增加一个非常重要的维度：
OS Risk State——系统版本风险状态。
五、最危险的不是 Sandbox Escape，而是完整攻击链被缩短了
从攻击链角度分析，真正值得关注的是：
一个普通用户距离“破坏监管”到底还有多少步骤？
正常情况下：
普通 App
↓
受到 Sandbox 限制
↓
不能访问 MDM 敏感状态
↓
攻击终止
但是在受影响系统版本中，攻击链可能变成：
攻击 App 进入设备
↓
用户启动攻击 App
↓
触发 Sandbox Escape
↓
获得异常文件访问能力
↓
影响 MDM 本地管理状态
↓
MDM 管理链路失效
这里最关键的变化不是：
漏洞技术有多复杂。
而是：
攻击工具开始趋向普通用户可获取。
对于租赁安全来说，攻击工具从私人研究 PoC 变成公开 App，风险等级会发生明显变化。
因为攻击门槛降低以后，攻击者数量可能迅速增加。
六、MDM 被破坏以后，Activation Lock 为什么没有立即解决问题？
很多租赁商家看到这里可能会想到：
“我们不是还有苹果激活锁吗？”
这是一个非常重要的问题。
答案是：
Activation Lock 仍然非常重要，而且它可能是这类攻击场景下最后一道独立资产保护边界。
特别是 Organization-linked Activation Lock——组织关联激活锁。
Apple 官方说明，组织关联 Activation Lock 依赖 Apple Business 或 Apple School Manager，由设备管理服务直接和 Apple Server 交互控制开启与关闭。
这个过程完全发生在服务端，不依赖用户当前操作，也不依赖设备当前状态。
所以：
删除本地 MDM 管理状态 ≠ 删除 Apple Server 上的 Activation Lock。
这是非常关键的安全隔离。
但是问题也恰恰出现在这里。
Activation Lock 主要解决的是：
设备重新激活时，是否允许其他人继续使用设备。
而如果恶意用户已经破坏 MDM 管理，但：
没有恢复出厂设置；
没有擦除设备；
没有进入重新激活流程；
那么 Activation Lock 并不会自动让正在运行中的设备重新进入 MDM 管理状态。
于是可能出现一个非常尴尬的风险状态：
Activation Lock 还在。
但是：
MDM 已经失效。
设备当前仍然保持在一个可以继续使用的系统环境里。
这意味着商家原本依赖 MDM 的：
远程策略；
状态查询；
后续限制；
应用管理；
部分远程处置能力；
都有可能失去作用。
而只要用户不主动擦除设备，Activation Lock 的最终保护价值暂时无法转化为当前设备控制能力。
所以对于租赁行业来说：
Activation Lock 是资产底线，但不能代替运行期 MDM 安全。
七、这次事件真正改变了什么？
过去很多租赁行业 MDM 的安全模型可以概括成：
只要监管描述文件不能删除，设备就是安全的。
这次实际测试说明：
这个模型已经不够。
新的安全模型应该变成：
即使操作系统出现漏洞，即使设备长期掌握在潜在攻击者手中，也要尽量让攻击代码无法进入完整攻击链。
换句话说：
不能只保护：
MDM Profile。
还必须保护：
能够攻击 MDM Profile 的执行环境。
于是问题从：
“怎么让 MDM 删除不了？”
转变成：
“怎么让攻击 MDM 的代码根本没有机会运行？”
这也是 MDM.Plus 针对此次风险设计两代防护方案的核心出发点。
八、第一版方案：直接关闭 App Store，切断攻击 App 的安装入口
面对系统级漏洞，MDM Server 自己无法修复 iOS Sandbox。
这是 Apple 操作系统自身的安全问题。
但我们可以做另外一件事情：
截断 Exploit Chain。
攻击链最前面是什么？
不是 Sandbox Escape。
而是：
攻击 App 必须先进入设备。
所以 MDM.Plus 第一版方案采用了非常直接的策略：
禁止用户自行安装 App。
Apple 官方提供的 MDM Restriction 支持在受监督设备上禁止使用 App Store 安装应用。
启用后：
App Store 对用户不可用；
用户无法自行安装或更新应用；
但 MDM 仍然可以继续使用应用安装命令向设备分发 App。
于是第一版方案变成：
系统 App Store
→ 限制用户安装。
可信 App
→ 由 MDM 统一下发。
未知 App
→ 无法通过正常用户安装流程进入设备。
我们随后建立了一套类似：
安全版 App Store
的应用分发入口。
用户需要：
微信；
支付宝；
抖音；
地图；
办公软件；
常用工具；
或者其他已经经过平台确认的应用，
可以通过平台应用中心获取。
最终仍然由 MDM 完成 App 安装。
九、第一版方案为什么有效？
它并没有修复 iOS 27 的 Sandbox Escape。
但是它直接破坏了攻击链成立的前提。
原来的攻击链是：
安装攻击 App
↓
启动攻击 App
↓
触发 Sandbox Escape
↓
获得越权访问
↓
攻击 MDM 状态
而第一版方案把它截断在：
第一步。
攻击 App 无法正常进入设备，
后面的 Sandbox Escape 自然也就没有机会执行。
在安全工程中，这类措施通常可以理解为：
Compensating Control——补偿性安全控制。
当底层漏洞无法由业务方自行修复时，
通过限制攻击面降低漏洞真正被利用的概率。
这也是企业安全体系中非常常见的一种设计思想。
十、但第一版方案的问题同样明显：安全和体验发生了严重冲突
如果这是一台：
仓库 PDA；
餐厅点餐机；
企业专用终端；
或者学校课堂设备，
关闭 App Store 并没有太大问题。
但是：
租赁出去的 iPhone，本质上仍然是一台个人消费设备。
用户可能会安装数十甚至上百个不同应用。
而不同用户需要的应用完全无法提前穷举。
更重要的是：
App Store 并不仅仅承担“下载安装 App”这么简单的功能。
它还与：
个人 Apple Account；
应用历史记录；
App 自动更新；
已购项目；
订阅；
付费 App；
StoreKit 相关业务；
完整的 Apple App 生态，
深度绑定。
如果完全取消原生 App Store 使用能力，即使平台自己建设一个安全应用中心，仍然会明显改变消费者使用习惯。
最终可能带来：
客服量增加；
应用缺失投诉；
更新不及时；
应用适配成本；
运营团队维护应用库；
以及一些购买和订阅场景体验发生变化。
所以第一版方案解决的是：
“能不能挡住攻击？”
答案是：
可以。
但第二个问题马上出现：
“挡住以后，这台手机还像一台正常的 iPhone 吗？”
如果答案是否定的，
方案就还不够成熟。
十一、第二版方案：把安全控制点从“安装”移动到“运行”
于是我们重新审视整个攻击过程。
攻击 App 真正产生风险的关键点到底是什么？
并不是：
它出现在手机里面。
真正危险的是：
它能够启动。
只有 App 获得执行机会以后：
漏洞代码才能执行；
Sandbox Escape 才能触发；
后面的攻击链才有可能继续。
于是第二版方案不再阻断：
App Installation。
而是重点控制：
App Execution。
也就是：
应用运行白名单。
十二、Apple 本身就提供了 Approved App List 能力
这并不是通过非标准方式实现应用控制。
Apple 官方的 Device Management Restriction 中，本身就提供：
Restrict app usage
能力。
在受监督的 iPhone 和 iPad 上，可以将应用放入：
Approved List
或者：
Unapproved List。
Apple 明确说明，除 Settings 和 iPhone 上的 Phone 等必要应用外，其他 App 可以按照允许列表或禁止列表进行管理。
到了 Apple 最新的应用管理体系中，这种思想仍然在继续强化。
Apple 当前的管理文档已经明确使用：
AllowedApps
和：
DeniedApps
来描述应用执行策略。
在 AllowedApps 模式中：
只有列表中的应用可以启动，没有进入列表的应用不能启动。
这正是第二版防护体系的基础逻辑。
十三、第二版方案：App Store 正常保留，但只有可信 App 可以运行
于是第二版架构变成：
原生 App Store
保留。
用户仍然可以正常：
搜索 App；
下载安装 App；
更新 App；
使用自己的 Apple Account；
使用原来的 App Store 生态。
MDM 安全策略
维护一套：
Trusted Application Allowlist。
例如平台已经确认的：
微信；
支付宝；
淘宝；
京东；
抖音；
银行；
地图；
办公软件；
主流游戏；
正常工具；
以及大量常用 App，
进入可信白名单。
这些 App：
可以正常运行。
而没有进入白名单的未知 App：
即使用户成功下载安装到设备上，
也不能正常启动。
于是 App Store 的职责仍然是：
Application Distribution。
而 MDM 开始负责：
Application Trust。
十四、这个变化非常关键：安装权和执行权被拆开了
第一版方案实际上把两个问题绑在一起：
因为不允许攻击 App 运行，所以干脆不允许用户自行安装任何 App。
安全性很强，
但是颗粒度非常粗。
第二版则变成：
用户可以正常安装 App，但设备只执行已经被认为可信的 App。
这相当于把：
安装权限
和：
执行权限
拆开。
从安全模型来看：
第一版
Default Deny Installation
第二版
Default Deny Execution
这两种模型最终都可以阻止攻击 App。
但第二版对正常用户影响明显更小。
十五、为什么我们选择“白名单”，而不是维护 FilzaSlop 黑名单？
这也是整个方案中非常重要的设计决定。
最简单的思路似乎是：
发现 FilzaSlop。
拿到 Bundle ID。
加入黑名单。
问题解决。
但真正做安全系统以后就会发现：
黑名单永远追不上攻击工具。
一个攻击 App 可以：
换名字；
换图标；
换 Bundle ID；
换签名；
重新封装；
Fork 一个新版本；
重新编译；
甚至只是修改几个字段，就可能形成一个新的应用身份。
于是防御流程会变成：
出现 FilzaSlop A。
↓
加入黑名单。
↓
出现 FilzaSlop B。
↓
继续加入黑名单。
↓
出现其他工具 C。
↓
继续追。
这种模型本质上属于：
Known Bad。
也就是说：
“我必须提前知道你是坏的，才能阻止你。”
而白名单完全相反。
白名单是：
Known Good。
平台只回答一个问题：
我是否确认这个 App 是可以在租赁设备上运行的正常应用？
如果答案是：
Yes。
允许运行。
如果答案是：
未知。
默认不运行。
这是一种更加接近：
Zero Trust Application Model
的设计。
十六、攻击链因此被重新改写
在第二版方案下：
攻击者下载 FilzaSlop 或类似工具。
↓
App 成功出现在设备上。
↓
用户点击运行。
↓
MDM 应用执行策略检查。
↓
应用不在可信列表。
↓
启动被阻止。
于是后面的：
Sandbox Escape；
越权文件访问；
MDM 状态破坏；
都失去了触发条件。
这也说明一个很重要的安全原则：
我们未必需要在每一层都击败攻击者，只需要让完整攻击链无法闭环。
十七、第二版最大的优势：安全策略开始对正常用户“无感”
对于租赁设备来说，最理想的风控并不是：
用户每天都感觉：
“这是一台被监管的手机。”
真正好的风控应该是：
正常履约用户几乎没有明显感知。
只有当设备进入风险状态或者发生高风险行为时，安全策略才真正出现。
第二版 App Allowlist 的价值就在这里。
正常用户仍然看到：
原来的 App Store；
原来的 Apple Account；
原来的搜索；
原来的下载安装流程；
原来的 App 更新；
原来的消费者使用习惯。
而设备后台实际上始终存在一套：
Application Trust Boundary。
绝大部分正常用户不会感觉到它的存在。
只有当未知或者风险应用试图运行时：
安全策略才进行阻断。
相比第一版：
安全能力保留了，但用户摩擦显著下降。
这才更符合真正的消费级租赁设备场景。
十八、真正困难的并不是做一个白名单，而是建立可信应用体系
“App 白名单”听起来非常简单。
但如果设备量达到一定规模，真正困难的事情才刚刚开始。
1. 应用数量巨大
用户可能安装非常小众的地区应用、企业应用、银行应用或者刚刚发布的新 App。
因此白名单不能只有：
100 个 App。
也不能只有：
1000 个 App。
平台必须持续积累应用身份数据库。
2. 不能依赖 App 名称
攻击者可以轻易把一个 App 改名成：
微信；
支付宝；
Calculator；
甚至系统工具。
所以安全策略必须基于更加稳定的应用身份，例如 Bundle Identifier 等管理属性。
3. 必须处理系统应用
Phone、Settings、Safari、App Store、Shortcuts 和部分系统组件存在特殊管理逻辑。
错误的白名单策略可能直接影响：
拨号；
系统设置；
网页；
快捷指令；
甚至部分系统调用。
Apple 自己也特别提醒，某些 Shortcuts Action 需要将相关系统 Bundle ID 纳入允许范围。
4. 新 App 需要快速放行机制
正常客户安装一个刚刚上线的新应用。
系统发现：
不在白名单。
如果只能联系客服，体验会非常差。
所以完整的平台应该逐渐具备：
未知 App 识别
↓
风险分类
↓
自动/人工审核
↓
快速加入可信库
↓
策略同步
这样的工作流。
5. 已经可信的 App 也不是永久可信
App 本身可能：
更换开发者；
改变 Bundle；
发生供应链攻击；
被确认存在严重风险；
或者某个版本出现特殊漏洞。
因此可信 App 库本质上不是一个：
静态 Excel 表。
它应该逐渐演化为：
Application Trust Database。
十九、仅仅做 App 白名单仍然不够
虽然应用白名单可以显著降低这一次攻击链的成功概率，但如果因此认为：
“有白名单以后 MDM 就绝对安全了。”
又会形成新的错误安全假设。
安全领域最重要的思想之一就是：
Defense in Depth——纵深防御。
对于高价值租赁设备，我们认为至少应该建立以下几层防线。
第一层：系统版本安全
平台应该知道：
设备当前是什么 iOS 版本；
哪些版本属于已知高风险版本；
哪些设备需要升级；
哪些设备出现异常降级或特殊版本。
未来理想状态应该是：
OS Version 也参与 Risk Score。
而不是后台只显示：
27.0 Beta 3
然后什么都不做。
应该能够直接转化成：
系统风险：高。
第二层：限制未经授权的系统测试版本
此次公开研究至少说明：
Beta 系统对于高价值资产设备并不是一个可以完全忽略的变量。
租赁设备的首要目标不是：
体验 Apple 最新功能。
而是：
稳定与资产安全。
因此生产中的租赁设备原则上应尽量使用：
平台已经验证的稳定系统版本。
而不是让用户随意进入：
开发者 Beta；
公开测试 Beta；
或者平台尚未验证的系统环境。
第三层：控制应用进入渠道
除了 App Store，还应该根据业务所在地和系统能力考虑：
Web Distribution；
Alternative Marketplace；
企业应用；
其他允许的应用分发方式。
Apple 在受监督设备上已经提供多项限制能力，可以限制网站直接安装应用以及替代应用市场等渠道。
如果安全团队只盯着：
App Store，
却留下其他应用进入路径，
整个防护链仍然可能存在缺口。
第四层：应用执行可信
也就是本文重点讨论的：
Application Allowlist。
即使未知 App 进入设备：
也不能获得执行机会。
这是此次 MDM.Plus 第二版方案中的核心防线。
第五层：MDM 完整性监控
过去平台通常关注：
设备有没有回连 MDM。
未来可能需要进一步关注：
监督状态是否正常；
Enrollment 是否正常；
策略是否仍然存在；
设备是否长时间没有响应；
关键配置状态是否出现异常；
最后一次 MDM 活动时间；
设备是否突然进入异常状态。
因为如果：
MDM 自己已经成为攻击目标，
那么监控 MDM 完整性本身就变得非常重要。
第六层：Activation Lock
最后才是设备资产层面的底线。
尤其是组织关联 Activation Lock。
Apple 明确说明，这种 Activation Lock 是由设备管理服务直接和 Apple Server 通过服务端方式完成管理。
所以即使设备本地 MDM 状态发生异常：
只要 Apple 侧 Activation Lock 关系仍然存在，
攻击者如果最终：
擦除设备；
恢复出厂设置；
重新进入激活流程，
仍然必须面对 Activation Lock。
因此：
MDM + Activation Lock 不是重复能力。
它们实际上保护的是两个不同阶段。
MDM 保护：
运行期。
Activation Lock 保护：
重新激活期。
二者结合才更加完整。
二十、这次事件其实暴露了传统租赁 MDM 最大的认知误区
传统 MDM 行业非常喜欢讨论：
有多少条命令；
可以锁哪些功能；
能不能远程定位；
有没有丢失模式；
有没有激活锁；
有没有一键锁机。
这些当然重要。
但是对于今天的租赁设备来说：
真正决定安全能力的已经不只是：
“我能够控制设备什么？”
还包括：
“设备有没有能力破坏我的控制？”
这是两个完全不同的问题。
过去 MDM 是：
Security Controller。
现在我们必须开始考虑：
Who protects the controller?
谁来保护 MDM 自己？
答案不会是另外一个单独的功能。
而应该是一整个安全体系：
系统版本管理；
应用来源管理；
应用执行白名单；
MDM 完整性检测；
Activation Lock；
异常行为响应；
服务端安全；
共同组成设备安全边界。
二十一、为什么租赁行业未来会从 MDM 走向 Device Trust？
Mobile Device Management 这个名字诞生的时候：
它主要解决的是企业 IT 问题。
企业问：
这是谁的设备？
装了什么软件？
Wi-Fi 怎么配置？
员工可以使用哪些功能？
但是今天租赁行业真正问的问题已经发生变化：
这是不是我们的设备？
设备现在是否仍然受管？
当前系统是否安全？
有没有运行未知程序？
关键安全策略是否仍然存在？
设备有没有出现异常状态？
Activation Lock 是否仍然有效？
设备还能不能被可靠追回？
所以未来租赁行业真正需要的平台可能不再只是：
Mobile Device Management。
而会逐渐变成：
Device Trust Management。
核心不只是：
“管理设备”。
而是持续回答：
这台设备现在是否可信？
二十二、从第一版到第二版，MDM.Plus 真正升级的不是一个功能
第一版方案：
禁止 App Store + MDM 安全应用中心。
核心目标是：
先把攻击面迅速关闭。
它解决的问题是：
能不能防？
答案是：
能。
但是代价是正常用户体验下降。
所以第二版开始转向：
保留原生 App Store + 应用执行白名单。
核心目标变成：
攻击 App 无法运行；
正常 App 正常使用；
原有 App Store 生态尽量不受影响。
它解决的问题变成：
如何在防住风险的同时，让正常用户几乎感觉不到安全策略？
我们认为这才是租赁设备风控更加合理的发展方向。
因为安全系统的最终目标从来不是：
限制越多越安全。
真正成熟的安全体系应该追求：
在最低业务摩擦下，获得足够强的资产保护能力。
二十三、我们对这次漏洞的最终判断
截至 2026 年 8 月，公开 FilzaSlop 项目确认其沙箱逃逸支持范围包含 iOS 27 Beta 1–4，并能够获得部分 App Container 和系统相关 Container 访问能力。
安全研究社区则表示，对应的一条 iOS 27 Sandbox Escape 路径在后续 Beta 中已经被修补。
所以我们并不认为应该宣传：
“所有 iOS 27 永久存在一个无法修复的 MDM 漏洞。”
这种表述既不准确，也没有必要。
真正应该被行业重视的是另外一件事情：
公开攻击工具已经证明，Apple MDM 的安全性最终仍然建立在操作系统安全边界之上。
而 MDM.Plus 安全团队的实机测试进一步表明：
在特定受影响系统环境中，
当这层边界被突破以后，
风险有可能从：
App Sandbox Security
扩散到：
MDM Management Integrity。
对于普通消费者：
这是一项系统安全风险。
对于手机租赁行业：
它可能直接演变为：
设备资产风险。
这就是两者最大的区别。
结语：真正可靠的 MDM，不应该假设 iOS 永远不会出现漏洞
如果整个设备风控体系建立在一个前提上：
“苹果系统永远不会出现可以影响 MDM 的漏洞。”
那么这套体系从第一天开始就是脆弱的。
更加现实的安全假设应该是：
未来仍然会出现新的系统漏洞。
未来仍然可能出现新的 Sandbox Escape。
未来还会出现新的攻击 App。
恶意用户仍然会研究监管绕过。
在这种情况下，
真正可靠的 MDM 平台应该具备的是：
发现风险版本的能力；
快速调整系统策略的能力；
控制应用来源的能力；
阻止未知应用执行的能力；
监控 MDM 自身完整性的能力；
保留独立 Activation Lock 资产保护边界的能力；
以及在新漏洞出现以后快速响应的能力。
所以这一次 FilzaSlop 给租赁行业带来的最大价值，可能并不是告诉我们：
“iOS 27 出现了一个漏洞。”
而是提醒整个行业：
MDM 自己也需要被保护。
从禁止 App 安装，
到可信 App 执行白名单；
从管理设备，
到管理设备的可信状态；
MDM.Plus 的两版应对方案，本质上代表的是同一个方向：
租赁 MDM 正在从“远程控制工具”，逐渐演进成“设备资产安全基础设施”。
而在系统漏洞不断出现的时代，
这种演进可能已经不是可选项，
而是手机租赁行业必须面对的下一阶段。
扫一扫
192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
