学习完王铁磊大佬在华为的分享视频，记录总结一些有用的内容。还会根据分享的内容再额外补充一些其他相关内容。
操作系统的演化与安全发展
从计算机整体的发展演化方向来看，可以将其安全分为四个阶段：
- 1970~1980：基础理论模型阶段
- 1980~2000：服务器安全阶段
- 2000~2010：个人电脑安全阶段
- 2010~2020：移动设备安全阶段
计算机系统业务的变迁引起威胁模型的变迁，进而引起系统安全研究重点的变迁。
1970~1980 系统安全理论模型大发展
从一开始的单片机里的单用户、资源独占，发展到巨型机的分时、资源共享、多用户模式。
问题：如何管理用户权限、防止越权访问、篡改机密信息？
经过学术界讨论之后形成了基本共识 安全三要素CIA：
- 机密性
- 完整性
- 可用性
在此之后，James P.Anderson在Computer Security Technology Planning Study中提出了Reference Monitor的概念，用户的访问需要通过Reference Monitor裁决判断，这种控制模型逐渐演变成了后来的可信理论基础。（类似于法官的存在）
数据访问控制基本模型：
D.Bell和L.LaPadula提出BLP模型（数据机密性基本原则）
- 在BLP模型下，如果一个系统的初试状态是安全的，那么经过一系列符合规则的状态转换后，该系统还是安全的
- 形式化证明了计算机系统可以通过对层级机密信息访问控制约束，确保计算机系统中数据的机密性（人话：如果约束条件足够安全，则访问即为安全）
Biba模型（数据完整性基本原则）
BLP和Biba模型奠定了Reference Monitor Policy的理论基础。（类似于法律条文）
操作系统安全设计基本原则（The Protection of Information in Computer System, 1975）
- Open design 开放设计
- Separation of privilege 权限分离
- Least privilege 最小权限
- Economy of mechanism 经济原则
- Fail-safe defaults 默认失败
- Complete mediation 完全鉴权
- Least common mechanism 最小公共机制
- Psychological acceptability 界面简单易用
1980~2000 操作系统/服务器快速发展
服务器市场兴起，通用操作系统快速发展，系统安全在不断探索中形成了基本框架：
- 内核与用户态隔离
- 用户态进程内存隔离
- 实现了以用户用户/群组为主体，文件等资源为客体，读写执行等为粒度的访问控制体系
两类访问控制
- DAC自主访问控制
- 客体的拥有者（Owner）可以自定义客体访问策略
- MAC强制访问控制
- 全局预定义访问策略，拥有者（Owner）也无权修改
整体层级分成 User -> Kernel -> Hardware 三层结构
1 | User Space |
产生安全威胁的核心原因：共享！
基本对策：隔离和控制
- 修墙——隔离
- 门禁——控制
安全的副作用：
- 效率降低
- 易用性下降
系统安全逐渐成为业务发展的绊脚石
补充：从这一阶段起，漏洞利用开始登上舞台
世界上第一个蠕虫 1988年 Morris蠕虫 利用栈溢出传播自己
phrack杂志（从1985年存活至今）1996年发布第一篇完整的栈溢出攻击指南 http://phrack.org/issues/49/14.html
2000~2010 个人电脑/互联网大发展
以Windows/Linux为代表的操作系统快速普及
- 基本以自主访问控制为主
- 2003年由NSA主导的SELinux才被纳入Linux
个人计算机系统迎来了安全问题的集中爆发
- 混乱的程序分发渠道（xxx软件家园）、毫无安全约束的执行环境（root+无沙箱+无杀毒的裸奔）
- 恶意代码三驾马车——病毒、木马、蠕虫
可信计算组织（TCG）由AMD、惠普、IBM、intel和微软等硬件、软件、服务供应商组成。他们提出了TPM，想打造产业链上的软件硬件的可信环境，思路是在硬件层面提供可信根，用途：可信启动、完整性度量、磁盘加密、密钥管理，但由于商业上的种种利益牵扯，最后草草收场。
补充：那些年的传奇事件
2004年 18岁德国少年编写震荡破蠕虫
2006年 25岁李俊编写的熊猫烧香病毒（他也是武汉男生病毒和QQ尾巴病毒的作者）
2010年 首个网络武器级别的病毒被发现 震网病毒 目标伊朗核电站 里面包含4个0day
2010~2020 移动互联网/智能手机大爆发
目睹了桌面操作系统的乱象后，Apple在iOS系统中开始创新与变革。
问题：如何根治PC时代的毒瘤？
iOS初期安全建设三驾马车
- 可信启动 -> 确保内核启动完整性，且不可降级
- App Store + 强制代码签名 -> 垄断App分发渠道（通过技术手段巩固地位）
- 应用沙盒 -> 限制App能力
结果：恶意代码基本消失，软件开发者的权益得到一定保障，生态逐渐繁荣
系统安全建设成为Apple生态的基石
新安全需求不断涌现：移动设备承载了大量个人数据，遗失问题成为用户痛点，如何保障遗失手机的数据安全？（隐私问题开始出现）
iOS4的数据层级保护，分成A、B、C、D四类密钥管理，实现数据的严格保护。
| Class | Description |
|---|---|
| A（256bit AES） | 只有解锁状态才能使用 |
| B（Curve 25519） | 公钥一直可用，私钥只能解锁状态使用 |
| C（256bit AES） | 启动后用户至少解锁手机一次才可使用 |
| D（256bit AES） | 一直可用 |
1 | +-------------------+ +----------------------+ |
在创建文件时会随机生成File Key，File Key保护文件内容。
上面四类Class Key保护文件的File Key。
Class Key被硬件Key和一个Passcode Key同时保护。
File System Key保护File Metadata（文件头以及加密后的File key）。
File System Key没有受到保护，但它存在的意义是什么？苹果比较取巧的通过File System Key来标记文件是否存在，消除数据时直接删key就行。
小结
| 时间 | 阶段 | 典型安全需求 | 典型研究成果/实践 |
|---|---|---|---|
| 1970-1980 | OS基础理论模型大发展 | 计算机能否在军事领域应用 | CIA三元组、Reference Monitor概念、BLP和Biba模型 |
| 1980-2000 | 服务器时代 | 多用户隔离 | 用户态内核态层级隔离、强制/自主访问控制 |
| 2000-2010 | 个人电脑时代 | 恶意代码 | 虚拟机、可信计算 |
| 2010-2020 | 移动设备时代 | 隐私与数据保护 | 应用沙盒、数据层级保护 |
从苹果的例子中能够发现，好的安全架构是能够带动业务增长。
阴云不散的幽灵——漏洞
以为漏洞只是打个patch而已，但没想到成为整个行业的痛点。漏洞指信息系统在设计、实现、部署、管理等环节中的缺陷，被攻击利用后可导致信息系统违背原有安全策略。
利用网络服务组件中的漏洞，攻击者可以轻易远程获取计算机设备的控制权。墙上的小洞，让攻击者具备穿墙术，隔离+控制的基本安全框架受到严峻挑战。
漏洞成因广泛，形态复杂，利用手段多样。
软件：
- 内存安全漏洞 70%
- 逻辑类型及其他 30%
硬件：
- Rowhammer
- Meltdown
思考：SoC是硬件漏洞？软件漏洞？如果定位为软件漏洞，但它是固化在芯片中，无法通过升级解决问题
内存安全漏洞：uaf、类型混淆、溢出写、越界读、未初始化等。构造操作原语：
- 非法读
- 非法写
- 非法执行
这三者还能互相转换，最后构造出破坏安全策略的恶意利用。
现在大部分还存在多层隔离，最小化信任边界、拉长漏洞攻击链。
比如现在要完成一个RCE漏洞利用：某程序内部RCE+沙箱逃逸+权限提升+信息泄露。
利用漏洞突破iOS防护成为新威胁：
- BootRom漏洞加载定制化的内核，直接打破iOS硬件可信链
- 越狱直接威胁App Store垄断地位
- 逃过沙盒窃取用户隐私
整个行业在焦虑漏洞治理方面的问题：
- 如何在新软件开发过程中消除漏洞？运用新的语言机制例如苹果Swift和安卓Kotlin
- 如何在现有软件代码中发现漏洞？动态fuzz，静态代码分析，人工审计
- 如何在代码编译阶段增强代码安全性？最经典的canary，以及llvm模块
- 如何在软件运行阶段阻断漏洞利用？更好的内存管理方案，使得漏洞被触发也难以利用
- 如何降低软件被攻击后给整个系统带来的破坏？有效的隔离方案
iOS安全架构演化过程
早期阶段
防御机制
- 可信启动
- 代码签名
- 数据层级保护
- ASLR和KASLR
- SEP（用于密钥管理的专用芯片处理器，自带SEPROM）
- KPP（保证内核运行时完整性）
- ……
苹果在早期的防御基础上做了更进一步的安全加固
参考blackhat https://i.blackhat.com/USA-19/Thursday/us-19-Krstic-Behind-The-Scenes-Of-IOS-And-Mas-Security.pdf
参考 苹果安全白皮书
更安全的可信启动
安全启动属于从源头上防守。在原有可信启动的基础上进一步加强。
减少攻击面：在第一次解锁之前禁止使用usb
开机第一次解锁之前，USB接口停用（不允许任何USB交互，包括充电）
影响：虽然降低了用户体验，但封杀了一个很大的攻击面（GreyShift 解锁11.3之前系统的漏洞）
启动过程中安全编译选项拉满，保证启动程序不出内存问题
BootROM作为根基依次验证下一环节的签名，大概的启动流程分为两个层次：
（1）AP（32位系统）
从SecureROM开始为根基，去验证LLB/iBoot，LLB/iBoot验证iOS内核，iOS内核再去验证用户态程序。
（2）SEP（64位系统）
SEP处理器拥有独立的安全启动链
自从iOS14开始，苹果在A13芯片（iPhone11）之后的机型上，使用增强编译组件，确保iBoot中没有内存漏洞。代价则是启动的性能。
- SEPOS基于L4微内核
- 独立的AES和随机数引擎
- 独立I2C Bus
- 实时内存加密
完全不信任AP侧的数据，因此设计出了Memory Protection Engine，功能十分强大。写入AP侧共享内存中的数据会被加密，并且有完整性校验，只有SEP侧可以解密。AP侧如果修改了这段内存中的数据，导致之后的完整性检验失败，内核会直接panic。
补充：
盘古大佬 blackhat上研究苹果的可信启动 https://raw.githubusercontent.com/windknown/presentations/master/Attack_Secure_Boot_of_SEP.pdf
在上面的blackhat链接中介绍了苹果新一代的T2安全芯片，以及最新的安全启动流程。看样子是mac电脑的安全启动，不知道手机会不会借鉴这个流程。
KTRR和APRR
KTRR和ATRR属于自底向上的防守，为了解决KPP的缺点。
KPP（Kernel Patch Protection）
一种纯软件实现的安全机制，主要目标用于检查内核运行时的完整性，代码实现运行在EL3层，用户态代码在EL0层，内核在EL1层。为了增加效率，仅在浮点数计算时调用KPP进行内核完整性检查。FPU（协处理器，用来处理浮点数）
- 启动时，将内核代码段与只读内存段进行hash，并禁用FPU执行浮点运算。
- EL0/EL1使用FPU后触发异常，EL1尝试启用FPU，随后进入EL3，在EL3中检查内核代码段和只读段hash是否变化
- IRQ异常时再次进入EL3，禁用FPU
KPP存在的设计缺陷
并不阻止篡改内核本身，而是找了一个不太影响性能的入口点去检测完整性（调用FPU指令时），因此造成了两个攻击点。
攻击点1：
- 攻击者可修改内核后立即恢复，大概率不会触发KPP检查（参考盘古越狱iOS 9.3.3）
- KPP依然存在价值，使得攻击变得不那么稳定
攻击点2：
- TOCTTOU攻击（Time-of-check to time-of-use）：内核中存在单一KPP检查入口，在入口点前恢复内核，KPP检查完后再次patch内核。
- 完美绕过KPP（Luca Todesco iOS 10.1.2越狱）
思考：如果将KPP检查点放在IRQ异常而不是调用FPU异常，是否效果会更好？
有没有办法在篡改发生时就阻止，而不是主动/定时检测？苹果的答案就是KTRR
KTRR（Kernel Text Readonly Region）
希望能从硬件层面阻止篡改内核代码段和只读段的一切尝试，KPP被彻底放弃。
硬件实现（作用于MMU和IOMMU）
- 设计了三个系统寄存器
- ROR Base：只读可执行物理地址起始
- ROR End：只读可执行物理地址结束
- ROR Lock：KTRR启用
- 需要修改内核物理内存布局，将只读可执行的内容放在一起，不能和读写内存交替
效果：几乎不可绕过（曾经出现过两次公开绕过案例，苹果快速修补）内核只读段在运行时无法被修改，内核shellcode无法实现，ROP成为内核代码执行的唯一攻击路径。
对抗：攻击者使用Patch读写数据段来代替Patch内核，达到相同或者类似的效果
苹果的应对：将更多读写段数据移到只读段，但是存在巨大困难点。1）很多数据在系统启动后还是有需求去改写，即便没有需求，也无法在系统启动的前期完成初始化；2）非ARM标准，后期维护困难。
KTRR的缺陷：
- 对于只读数据的保护，只能覆盖到系统早期启动（MMU初始化前）时能确定下来的内容
- 一些后期有需求修改，又是十分重要的数据，无法保护，无法处理Data only attack
为了解决KTRR的问题，苹果提出了APRR，一个新的硬件特性。
APRR（Access Permission Restriction Register）
APRR保护
- 页表
- cdhash（代码签名白名单）
- Code Directory Blob（进程Entitlement权限相关属性）
APRR实现原理
- 将关键数据所在的页表项做了特殊标记，这些数据只有特定的代码段才有权限进行读写等操作
- 这些代码段所在地址形成一个bitmap，存在一个苹果自定义的寄存器中
- 设置bitmap的gadget仅存在于PPLTRAMP段的第一个页中
效果：
- 关键数据仅有PPLTRAMP段的第一个页作为入口去访问，并且gadget很有限 -> 缓解Data only attack
- 修改关键数据必须先获得CPU执行权限 -> ROP成为唯一的攻击方法
PAC
PAC（Pointer Authentication Code）：ARM v8.3的新特性。PAC属于自底向上+封锁关键路径的思路。实现原理：
- 利用arm64 64位指针高位冗余特性，对内存中的关键指针加上认证信息
- 在指针被解引用或者当做控制流跳转目的地址前校验指针的完整性
PAC的执行流程：
1 | +-----------+----------------------------------+ |
一共有五个硬件Key，只能使用无法读取；modifier为一个用户可控的输入内容，最后得到的检验值放在指针前面。
基于硬件支持实现对指针的完整性保护，Apple芯片遥遥领先业界，从iPhone XS开始，商业化应用PAC。
iOS12：基于PAC的控制流完整性
iOS14：基于PAC的控制流完整性+部分数据指针完整性（重点防护攻击者常用）
整个安全机制涉及：编译器 + 内核开发 + 攻击手段学习（研究攻击者喜欢的数据指针）
实现的效果：正向（vptr、vtbl完整性、callback完整性）+ 反向（栈返回地址）的CFI + 部分数据指针保护
- 彻底消除了直接控制流劫持的漏洞利用
- 极大限制了攻击者内存破坏能力
现在要攻击iOS，必须要先通过漏洞构造有限地址读写，之后才有机会构造代码执行，并不能直接通过漏洞进行控制流劫持。
攻击面的变化
苹果的下一步
针对用户隐私
- iOS 14.5 启用App Tracking Transparency，强制App公示收集使用的用户信息
- iOS 15将推出“应用隐私报告”和更细粒度的“限制追踪用户”功能
ARM v8.5
- Memory Tagging
- 性能损耗 vs 安全收益
一些思考
为什么Apple持续在安全投入？
- 系统安全是iOS生态的基石
- 系统安全是iOS业务特性的一部分
- 系统安全是Apple商业模型的护城河
总结
系统安全经过理论探索到原型实践，总结出“隔离+访问控制”的基本架构，但是在个人电脑时代问题频出。
iOS以可信计算为基础，打造全新的iOS生态，安全成为iOS生态和业务模式的护城河
随着安全机制不断改进，内存安全迎来拐点
安全的博弈属性和木桶效应注定对抗不会止步（各类逻辑漏洞开始爆发）
漏洞防御过程中四大难题
- 攻击面多样性
- 漏洞多样性
- 漏洞利用方法的多样性
- 能达到攻击目标的路径的多样性
三种策略
- 从源头上防御：减少漏洞的产生，减少攻击面，增加攻击环节
- 封锁关键路径：封锁漏洞触发->漏洞利用的中间环节
- 自底向上：依赖硬件安全特性支撑软件安全
其他有用资料
google p0 ios内核漏洞近况 https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html