GOSSIP-summerschool-2019-day5

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. 不需要跑赢仍何条件竞争
    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上去)