GOSSIP-summerschool-2019-day5

Posted on | In |

Let’s GOSSIP软件安全暑期学校笔记

DAY 5: 7.24

今日演讲主题：

  1. Introduction to Secure Processors 硬件为王——安全处理器的发展与机遇 夏虞斌
  2. 攻陷macOS！”非主流”逻辑提权漏洞研究 周智

Introduction to Secure Processors 硬件为王——安全处理器的发展与机遇 夏虞斌

在很多时候，可以认为硬件比软件更安全。

形式化验证对于小型系统比较简单，大的系统如Android比较难。

软件开发、更新比较简单，打patch更简单；硬件比较难。

硬件攻击面比软件攻击面小

Background

OS/Hypervisor has too much code as TCB

第三方驱动为linux内核带来了许多漏洞。

Moreover, cloud vendors may not be trusted by very security sensitive clients
Thus we have enclave
  • Technology to provide secure execution environment (aka enclave)
  • Only hava small TCB
  • Use TCB to provide confidentiality, integrity and freshness guarantees for application executing in enclave environment

验证云端确实有硬件安全的基础，才信任

需要考虑

  • OS/hypervisor被控制的情况下，保证数据的安全
  • 同一台机器上的恶意软件的侧信道攻击
  • 物理攻击 被云运营商
    • Memory bus snooping： 数据读写 在总线上广播、内存中数据加密比较难
    • Cold boot attack / NVM： 用液氮将内存冷冻起来，装到恶意系统中，将密钥偷出来
    • Etc

image-20190724112150962

学术界

介绍了两个学术界的enclave：XOM、AEGIS

eXecute-Only Memory (XOM)

ASPLOS 2000

CPU对内存区域，不可读、仅可执行。使得操作CPU也无法读取数据，黑盒。

Threat model

OS不可信 and external memory （内存中存放密文，key在CPU里面，明文在cache中，防止Cold boot attack，使得攻击成本极高，所以认为CPU内部、SOC内部比较安全）

Propose execute-only code

Abstract XOM Machine

XOMOS

XOM保证master secret key的安全

软件进行配置，硬件进行细节的执行

Modification required：论文

  • 进程创建进行修改 每个进程key不同，函数调用、返回值加密

Counter-Mode Encryption

每块内存对应一个seed

image-20190724093842665

使得加解密开销由一个页面大小转变为Block Cipher的大小（Cache line 大小16Byte）

Problems

Seed with global Counter

Memory Integrity Verification

CPU取内存时计算hash进行校验

  • Replay attacks for simply computing MAC
  • Merkle tree verification
Merkle trees

一层一层的hash，得到root hash，从而一层层的保证数据完整性

优化：Bonsai Merkle trees

image-20190724094732044

AISE & BMT

overhead 5%，cache hit 90%+

image-20190724094846747

AEGIS

设计目的大部分与XOM相同

Small TCB

数据完整性

​ 与XOM相似。将 root hash放在cpu内部

Data Confidential
Context Switch & Interrupt

​ OS可以控制enclave

​ 将上下文保存在cpu中的一块区域

Memory Sharing

​ 通过一个bit进行标记是否共享，一个bit进行加密

Conclusion

  • 上下文机制
  • 隔离enclaves
  • 对内存划分比较简单

限制

  • 侧信道
  • performance overhead较高

RISC-V

Overview

权限划分：用户态、OS Supervisor、Hypervisor、Machine Mode

Machine Mode: 类似微码编程

Theart model:

  • 恶意的操作系统
  • 测信道
  • 无物理攻击的防御

Architecture

software

image-20190724101757186

Hardware Property: Memory Region

Secure Monitor 管理内存区域的归属那个enclave

CPU需要记录process id和memory region id并在每一次访存中检查

没有共享内存的机制，可以一定程度上的缓解side channel

memory region数量受限、同时跑的enclave受限

Hardware Property: Dual page table

双页表

当属于某个enclave时，加入enclave页表。

与系统无保护的页表分开，防止页表的side channel

image-20190724102355238

Conclusion

内存隔离机制

安全性差

秘密性、完整性无保护

内存限制较多

同时运行enclave数量有限

KEYSTONE

Overview

纯软件的方案，大部分代码都是现在Machine mode中

Basic Architecture

image-20190724102931219

image-20190724102940524

Hardware Property: PMP(Physical Memory Protection)

有八个寄存器标记连续内存区域的权限

和页表不同的地方：PMP寄存器只有八个，针对物理地址。

PMP寄存器取并集为权限：

OS运行时：只能访问OS memory

image-20190724103128932

Hardware Property: Cache Partition

Sifive

避免Cache 共享

Conclusion

通过PMP来实现隔离

局限：动态加载内存不行、enclave寄存器数量有限（仅支持n-1个enclave）

优点：开源、软件实现

工业界

Intel SGX

能防御物理攻击

threat model

隐私性完整性

side channel没有

Design of SGX: Memory Protection

image-20190724103744906

Design of SGX: Memory Protection

只有一个页表、由OS控制

ELRANGE对应到EPC，VA映射PA由OS控制，Processor记录ELRANGE和EPC的内存范围。

CPU中有hash tree，overhead比较高

EPC比较小128M，由于hash tree限制。

image-20190724103822005

Design of SGX: Permission Check

更多权限上的检查

Design of SGX: Context Switch & Interrupt

Design of SGX: Confidentiality & Integrity

MEE: 加解密模块

image-20190724104338858

Software Interface

可以将.so/.dll加载到进程空间

EENTER：单一入口 enclave

Conclusion

  • 隔离软件和enclave

  • 隔离enclave之间

  • 物理攻击

    • 加密
    • hash

  • 缺点：

    • side channel
    • 第一代不支持动态内存增加
    • 128M PRM限制

AMD VEX

Overview

保证隐私性不保证完整性

对内存大小无限制

threat model

直接用VM做隔离，保证VM的安全，云端

side channel没考虑太多

Design of SEV: Secure Encryption

每个VM一个key

通过Address Space ID来决定VM的key，可以以此控制share

image-20190724105032791

Design of SEV: Hardware Architecture

硬件与软件的界限越来越模糊

CPU打patch：修改micro code对应的ROM，每条指令的操作就变了。

image-20190724105447998

Conclusion

  • enclave之间：
    • 通过ASID保护
    • 加密
  • enclave与软件之间
    • 通过ASID保护
    • 加密
  • 物理攻击：
    • 加密
缺点

side channel

ASID有限

ARM TRUSTZOME

Overview

把CPU一分为二，时分复用。很底层的设计，做切换

image-20190724105731781

TEE REE

应用：

指纹、三星用TEE防root，华为类似、数字版权保护（DRM）

Different levels of Trust 安全级别：

image-20190724110300443

TEE在成本、安全性比较好、折衷的方案

可以把指纹、虹膜放在TEE；很深的隔离

比较

image-20190724110627288

image-20190724110636472

Enhancement

Internal isolation

Enclave 往往更加复杂。介绍了一种内部隔离的方法

TEE:

Stage1: (before-2012) 检查启动

Stage2: (2012-2017) 预装应用程序、扩展的信任

Stage3: (2017-now) 很多程序可以动态装入enclave中

需要在TEE中做更细致的隔离的原因

三个原因

image-20190724112531021

Goals of vTEE

  • TEE虚拟化
  • 最小化TEE
  • …

image-20190724112840510

要求：

image-20190724112931992

TEE-visor

解决：

虚拟化MMU

image-20190724113028271

对不同的TEE看到的MMU不同

image-20190724113315731

Gate

image-20190724113331985

Interaction

image-20190724113344413

举例：

image-20190724113555092

Cross-boundary optimization

上述TEE之间的切换overhead很大，在隔离的情况下实现Cross-boundary interaction。

在微内核中常见：

IPC

比function call 消耗大16倍，有切换的过程。

Domain switch 500cycles

Message copy 4000cycles(4 KB数据)

XPC

跨进程调用

实现了xcall、xret指令

  • Direct domain switch
  • Relay segment

image-20190724114027152

Domain switch的时间开销

image-20190724114231883

优化

image-20190724114443167

image-20190724114456985

Check 转为硬件实现：

image-20190724132931063

image-20190724132902916

image-20190724133008717

Copying Message is Slow

image-20190724133057241

image-20190724133125305

image-20190724133140817

普通数据通过Page Table 访问，message通过寄存器进行翻译，等价于TLB

将寄存器relay-segment传递给callee，使得caller失去对message的访问

可实现快速的接力，同时只能有一个

image-20190724133210590

image-20190724133236701

XPC程序示例

image-20190724133334812

side channel

核心在于共享。

Controlled channel attack (via page table)

Transaction
失败时abort
保证xbegin到xend是原子的

image-20190724133411176

image-20190724133438555

Branch side channel

哪些地址是take or not take，来推断if中的值

TLB side channel

conclusion

image-20190724133523402

总结

传统的隔离是单向的

enclave

image-20190724133610235

跨级反向隔离 & 同级细粒度隔离

image-20190724133650277

软硬件协同的离散隔离模型

image-20190724133716238

Other

如何使用SGX：

将代码传到云平台，向其发出随机数challenge，云平台对其签名，在Intel官网使用公钥，验证其签名来自Intel认可的私钥。

保护代码：传上去代码的loader，将代码作为数据加密传上去。

Q&A

SGX可以实现全同态加密，在密文的基础上进行操作，加密搜索、加密操作…

能够保证完整性和隐私性

不信任Intel SGX，因为密钥存放在Intel。

SGX中恶意代码，攻击主机，TEE中也可以保护恶意代码。

总结

对硬件安全机制有了更深入的了解，软件安全依赖于硬件安全，一旦硬件出现安全问题，在其之上的软件势必会受到影响。现在，硬件与软件之间的界限愈发模糊，许多硬件问题能够通过升级软件来解决。

SGX作为Intel近年来发布的解决方案，之前爆出了大量漏洞，但之后利用难度也肯定会越来越大。

云安全和硬件安全值得关注。

攻陷macOS！”非主流”逻辑提权漏洞研究 周智

推荐书籍与工具：

《OS Internals》推荐

image-20190724135306164

image-20190724135439641

自带的工具

image-20190724135456482

image-20190724135827553

环境：

  • 反汇编/反编译
  • class-dump
  • 系统监控
    • Monitor.app By FireEye

逻辑漏洞

特点：

  • 简单粗暴：相对较少涉及底层细节
  • 难以fuzz：不会产生明显的奔溃现象
  • 利用稳定：不需要破坏数据结构
  • 脑洞大开：跨组件串联多个条件

滥用软件既有的特性

开发者对API的误用

MacOS 权限隔离

image-20190724140707765

IPC

  • Mach IPC
  • XPC：macOS/IOS最常用的IPC、用于用户态进程通信
  • NSXPCConnection
    • 基于libxpc
    • 基于@protocol和NSSecureCoding的远程过程调用
    • 面向对象

权限检查

沙箱逃逸：攻击沙箱外传进来的API

XPC服务允许不同特权级别进程互相通信。

  • 跨sandbox
  • 跨euid

通常使用代码签名限制（低权限）调用者

使用pid做检查很不安全，有很多软件这么做

###

Safari沙箱逃逸

  • 现代浏览器基于多进程架构
  • 渲染器进程处于沙箱中
    • 不可以创建进程
    • …

渲染器：主要攻击WebCore

IOS WebProcess

  • 当前MobileSafari基于多进程架构
  • 沙箱配置文件直接编译到sandbox.kext
  • 使用的searbelt-profiles指定，进程启动后自动初始化沙箱

MacOS WebProcess

  • 配置文件…

  • 在进程初始化中存在一个无沙箱状态的时间窗口

攻击面

image-20190724144136852

系统服务（用户态的攻击面）

image-20190724144438188

WindowServer在前几年是重点攻击的目标

攻击WebKit自带的IPC

分析沙箱配置

macOS WebProcess上的配置文件可以在文件系统中找到。

检查其中的配置

  • …
  • 用户态服务
  • 函数原型
  • flags
  • 其他IPC
    • 共享内存
    • …
  • 对缓存和临时目录具有读写权限

两个案例分析

  1. IOS应用后台续命
  2. 一行代码逃逸沙箱
    1. TOCTOU：time of check time of use
      1. Safari渲染器启动时没有沙箱的
      2. 初始化完毕后才会调用
    2. 一行代码POC
      1. 不需要跑赢仍何条件竞争
      2. …
    3. 添加恶意Widget至Dashboard

Root提权

MAC中即使root用户，仍然会收到SIP限制。

攻击对象：

  • 内核
  • 用户态root权限进程的IPC
  • 系统自带服务
  • 第三方软件服务

SIP（Rootless）

Rootpipe

writeconfig进程以root权限执行，并可通过进程间通信访问。

暴露后门API可用于向指定路径写入任意属性文件

TimeMachine提权

两处bug

  • 替换可执行文件
  • 命令注入

可以使用通配符减少payload长度

Feedback Assistant 条件竞争

pid的安全问题

  • 系统回收重用
  • 保留pid创建新进程

内核提权

结语

  • 操作系统安全性具有显著的木桶效应
  • 操作系统的复杂性决定其攻击方式充满多样性
  • 安全研究不要循规蹈矩

总结

着重介绍了几个MacOS中的几个漏洞，但是无奈没有MacOS安全基础，很多细节不太了解。

了解到了一些MacOS的安全机制、IPC机制。

正好换了mac，以后有时间可以尝试一下基础的MacOS/IOS编程、逆向，学习一下MacOS安全机制、复现一下漏洞。（想起来正好把之前复现的XNU内核ICMP漏洞 CVE-2018-4407的一些笔记传到github上去）