Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Who Allocated My Memory? Detecting Custom Memory Allocators in C Binaries

论文下载

这篇文章发表在2013 WCRE上,作者是Vrije Universiteit Amsterdam的Xi Chen。

  • 在识别数据结构的工作中,很重要的一步是识别内存分配函数,然后才能用污点分析等技巧来分析数据结构。库函数中的内存分配函数比较容易识别,可以直接通过函数导出表识别。但是,许多大型软件中,开发者会自己实现一套内部的内存分配器,这就给内存分配函数的识别带来了困难。
  • 这篇文章的目的是要在没有符号信息的二进制程序中,识别出这些开发者自己实现的内存分配函数。
  • 作者先总结了malloc,free,和realloc函数的一些特征用以识别相对应的函数,然后基于此,提出了一套叫Membrush的系统来识别内存分配函数。

内存分配函数特征分析

  • c_malloc:
    • (A1)c_malloc函数会返回一个指向堆的指针p;
    • (A2)程序会向返回的指针p,或根据p计算出的地址,进行内存写操作;
    • (A3)除非c_malloc函数在返回前初始化了内存块,程序应该先写再读这块内存;
    • (A4)c_malloc不能在调用c_free之前多次返回同一个对象;
    • (A5)c_malloc不仅要检查从一个内部函数返回的指针,还要进行一些运算来生成新的对象指针。
  • c_free:
    • (D1)内存分配器会记录内存中哪些是已经分配了的,哪些是未分配的;
    • (D2)除非有bug,c_free释放的内存不会再被访问;
    • (D3)c_free释放的内存可能会再被c_malloc使用;
    • (D4)c_free函数和c_malloc函数有共用的metadata。
  • c_realloc:
    • (R1)c_realloc返回一个指向堆的指针p;
    • (R2)c_realloc会访问c_malloc使用的metadata;
    • (R3)程序会用p,或通过p计算的地址访问内存,而且在读之前会先写这块内存;
    • (R4)一旦c_realloc改变了一个内存块的大小,之后相同的操作不会堆内存进行任何操作;
    • (R5)c_realloc会保留原来内存块里的数据;
    • (R6)c_realloc结合了c_malloc和c_free的特性。当释放一个内存块之后,程序不会再访问这块内存;
    • (R7)c_realloc释放了一个内存块之后,c_malloc可以再次分配这块内存。

Membrush Overview

Membrush用Pin做动态插桩,使用上述的特征来识别内存分配函数。Membrush的输入是没有符号表的二进制程序(1)以及这个程序的输入(2)。(3)通过函数调用栈识别上下文关系。(4)识别函数内局部变量的调用情况。(5)是数据流分析。(6)用来跟踪函数返回指针的使用情况。(7)(8)(9)(10)是检测模块。

Fig

(1)C_malloc函数识别

Fig

Membrush先通过返回值是否符合A1,对函数进行筛选。然后用污点跟踪筛选出满足A2和A3的函数。检测A4时,Membrush插入一个call loop反复调用这个函数,来看是否满足要求。反复调用时,需要对栈帧以及寄存器的值进行保存,然后再调用同一个函数。

(2)C_free函数识别

Fig

Membrush会跟踪c_malloc返回的指针来检测是否满足D1条件。通过跟踪调用该函数后,指针的使用情况来检测D2和D3是否满足。

(3)C_realloc函数识别

Fig

R1,R2,R3的检查类似与c_malloc。检查是否满足R4时同样需要多次调用这个函数确保同样的请求不会堆内存块产生新的操作。检查R5时,Membrush会检查是否存在从c_malloc分配出的内存到一块新内存块的连续内存拷贝操作,若存在则通过检查。R6的检查类似于c_free。

Evaluation

(1) 内存分配函数识别准确率

Fig

对不同类型的内存分配器函数的识别效果

Fig

各项标准对函数筛选效果的评估

Fig

将Membrush与Howard(数据结构识别)结合进行数据结构识别准确率的评估

Fig

A Software Approach to Defeating Side Channels in Last-Level Caches

  • 作者:Ziqiao Zhou, Michael K.Reiter, Yinqian Zhang
  • 单位:University of North Carolina, Ohio State University
  • 出处:CCS’16

论文下载

概要:

  • 作者提供了一种基于软件的方法来防御针对Last-Level Cache的access-driven 旁路攻击。
  • 这种方法基于安全域动态的管理物理页,禁止LLC 在不同行的物理页共享来防护FLUSH-RELOAD攻击,同时,通过控制单个安全域内的所有进程cache使用能力来防御PRIME-PROBE攻击。
  • 作者在Linux mainline 进行修改,实现了工具CacheBar。

1.介绍

  • Access-driven 旁路攻击是在不违反系统软件隔离的情况下,通过利用攻击者的计算能力,窃取同一台计算机上的秘密信息的攻击。
  • 在LLC上,这种攻击主要分成两类。
    • 第一类是FLUSH-RELOAD攻击,它要求攻击者和victim间存在物理页的共享。攻击者首先清空部分cache,接着执行victim进程,最后通过访问被清空cache所对应的物理页,来检测这部分页面是否被victim使用到。
    • 第二类是PRIME-PROBE攻击。攻击者首先在cache中填充满自己进程内存的数据。接着运行victim进程,通过PROBE先前载入的数据来查看哪些cache因为和victim的冲突被刷掉了。

COA For FLUSH-RELOAD Defense

Design

  • 在现代操作系统上,大多实现了按需配页和COW机制来减少应用级的内存拷贝。而这种内存共享是让FLUSH-RELOAD攻击得以实现的关键因素。
  • 作者在CacheBAR中基于安全域实现了一个COA机制,使得物理页共享只发生在同一个安全域中。
  • CachBAR给每个页4个状态UNMAPPED,EXCLUSIVE,SHARED和ACCESSED。当一个页面处于ACCESSED状态时,却被不同安全域的另一个进程访问,这页物理页会被拷贝,而latter 进程只能访问新拷贝的物理页。

Fig

Implementation

在实现上,主要分为四个部分,第一部分是在PID命名空间中添加了per Secuirty Domain per page 已经mapped了该物理页的进程个数。这个数组可以决定物理页的UMAPPED,EXCLUSIVE,SHARED状态。

Fig

第二部分是在struct page中实现的两个新链表,orignal_struct和 copy_struct。copy_struct中的owner指针决定了是SHARED还是ACCESSED。

Fig

第三部分是一个新的 page fault handler。在PTE中,状态为SHARED和ACCESSED的物理页会被设置COA bit,对它们的访问会触发page fault。

最后一部分是一个daemon ,定时的遍历original list,将最近没有被访问到的page 状态从ACCESSED变为SHARED,来减少不必要的COA。

作者在实现时还考虑到了KSM等page deduplication 机制。例如在下图中,将page5 merge to 7后,page5 会被unmap而page7的状态会变成SHARED。

Fig

Security

  • 安全性验证上作者采用了novel的system modeling的方法。
  • 作者在PROMELA语言中用一个byte表示一个物理页,page[virt]=0代表对应的物理页不在cache中,为1时在cache中。
  • 作者模拟了两个安全域的进程公用一个物理页的情况,开始时virt1=virt2=0,代表两个进程mapped了同一页,此时该页处于SHARED状态,按照设计的模型,当一个ACCESSED状态的物理页被另一进程access时,后者的virt就会变成一个新的值,代表COA拷贝了一个新的物理页。利用这个模型作者进行了模拟,找到了daemon和KSM导致的两个leakage。是由daemon或KSM将ACCESSED状态的页变为SHARED状态后攻击者发动RELOAD,此时由于处于SHARED状态且物理页在cache中,RELOAD攻击可以利用time side channel产生infomation leak。

Fig

Cacheability Management For PRIME-PROBE Defense

Design

另一种常见的攻击方法是PRIME-PROBE攻击。攻击者首先填充满cache set,让victim来冲刷掉cache中的lines,攻击者利用对相同内存的第二次访问时间来估算cache是否被洗刷掉了。CacheBAR在此的 countermeasure是禁止攻击者对整个cache set都拥有使用权限。

对于一个w-way cache,CacheBar给每个安全域分配一个随机数字ka作为能使用的cache set lines的个数(ki < w)。假设对于某个specific way,victim有d lines的需求,有三个因素会使攻击者无法准确评估d的大小。首先。如果ka < w-d,那么攻击者将完全无法看见任何eviction的发生。第二,如果前面的条件不满足,victim能使用的cache set lines为kv,那么攻击者无法区分demand为d还是的(d > d’ >= kv$)。最后,攻击者还需要确定victim的kv。

Implementation

在实现上,CacheBAR利用了PTE中一个reserved bit来表示该页是否是No-Domain的公共页。在此基础上,对于Domain-specific的页,为了保证最多只有ki lines的cache能被使用,CacheBAR对每个安全域能被cache的物理页个数进行了限定。由于同一个页上的内存会按照block大小cache到不同的cache set,所以限制能cache的物理页个数即限制了能使用的cache set lines。(在Linux中,可以在PTE中设置某些位控制该页能否被cache)

Fig

CacheBAR为每个安全域实现了一个队列,在一个有NC位的页发生page fault时,如果队列未满,就会执行一个入队的操作,如果队列已经满了,就会驱逐掉一个物理页。用clflush指令清除那一页的所有cache,并且清空TLB表,确保PTE得到更新。

同样,有一个daemon来负责动态的更新每个安全域的ki,并且根据页面的访问情况重排序队列。

Security

这里作者用了概率分析的方法来分析这种设计的安全性和对应情况下K的随机分布。

Evaluation

作者在一台有2个2.67GHZ Intel Xeon 5550 处理器的DELL服务器进行测试。CacheBAR修改的内核版本位3.13.11.6,系统使用Ubuntu14.04。利用Docker实现容器也就是安全域。

安全性验证

对于FLUSH-RELOAD攻击。作者在两个安全域中分别安置sender和receiver进程,共享一个库-libcrypto.so.1.0.0。sender不停地访问一个物理内存地址,而receiver在同一个物理内存地址进行FLUSH-RELOAD攻击。FLUSH和RELOAD的时间间隔位2500cycles,进行了50万次攻击。获得了一个访问时间的平均值。

可与看得出来开了CacheBar后unshared和shared的访问时间差很相近了。

Fig

对于PRIME-PROBE攻击。同样也使用两个进程,一个执行PRIME-PROBE攻击,另一在每次攻击间隔时执行d次内存访问。在测试机上w=16,ki取值范围为4-14,攻击者的目标为获知victim的demand d范围,简化将其分为6类:NONE={0},ONE={1},FEW={2,3,4},SOME={5,6,7,8},LOTS={9,10,11,12},MOST={13,14,15,16},攻击者有能力知道ka,但不知道kv。作者同样进行了50万次测试,并根据结果训练了两个朴素贝叶斯分类器。然后作者再进行了50万次测试作为测试集,得到了一个混淆矩阵如下

Fig

Fig

再开了CacheBAR后,预测不仅准确度有下降,有些错误更加离谱了。

然后下面是在不同的kv,ka设置下的总的准确率表。

Fig

最后作者对性能进行了相关测试。将开启了CacheBAR和没有修改的内核作性能上的比较。第一个测试在Apache 2.4.7web服务器上,使用PHP-FPM并开启了SSL。每个服务器对应一个client,重复的访问一个内容大小为86kb的网页。

从图中可以看出来对于最大流量的影响是很小的,而对于响应时间则会有20%的overhead。

然后作者对不同服务器应用语言配置做了测试。对每个测试开了16个container,页面大小为80KB,最差的情况是在Python+apache+cgi时产生,有25%的流量overhead。

最后作者对更加复杂的情况进行了模拟。使用nginx+php搭建了一个社区网站。利用Faban生成不同的请求测试响应时间,对于一些注册操作,响应时间的影响还是比较大的,overhead达到了30%多。同时测试了对流行的流媒体服务产生的响应时间的影响,在流媒体服务上响应时间基本就没有影响了。

Fig

Drammer: Deterministic Rowhammer Attacks on Mobile Platforms

  • Victor van der Veen,Yanick Fratantonio,Daniel Gruss et al.
  • Vrije Universiteit Amsterdam , CCS’16

论文下载

之前rowhammer的攻击要么是概率性的(ProjectZero),要么需要特殊的内存管理特性(KSM,THP)来把victim 数据放到会flip的物理地址上。这篇文章提出了利用android的内存管理接口来进行确定性的rowhammer攻击技术,不需要软件漏洞和权限的情况下进行root

Rowhammer

  • DRAM:row,rowbuffer,bank,refresh
  • Double-sided rowhammer: sandwich

000000000 111111111 000000000

攻击的基本条件:

  1. Fast uncached memory access:必须,bypass the cache
  2. Physical memory massaging:把victim 数据放到会flip的物理地址上 确定性 最有难度的一步
  3. Physical memroy address:非必须,需要连续的物理地址来做double-sided rowhammer

The First Flip

rowhARMer

android内核模块,ARM中的DCCIMVAC指令(类似x86中的clflush,但是需要root权限)

Fig

x86上实现3个利用条件的方式:

  • P1:Fast uncached memory access
    • 直接清cache:clflush
    • cache eviction set:不同地址映射到同一个cache line (rowhammer.js)
    • 非暂存的访问指令:不使用cache的内存访问操作
  • P2:Physical memory massaging
    • Page-table spraying
    • Memory duplication
    • MMU paravirtualization
  • P3:Physical memroy address
    • Pagemap interface
    • Huge pages

Fig

The Drammer Attack

  • 确定rowsize:时间旁路,同时访问page n和page n+i,当n+i位于下一个row时,n和n+i位于同一个bank中,第二次访问需要清空rowbufer,时间更长。(没有文档和工具)
  • DMA buffer management:让用户空间的程序访问外设的内存(用户控制cache,物理连续),解决了P1和P3
  • Physical memory massaging:
  • 整体思路:建立模板,利用物理内存分配器行为的可预测性,耗尽不同大小的连续物理块,从攻击者可以预测的地址开始分配内存
  • buddy allocator,slab

  • L chunk:slab largest chunk size,4k*210 = 4MB

  • M chunk:row size, 32k/64K
  • S chunk:page size, 4k

Fig

  • step2->step3:释放L*
  • step4->step5:释放M*
  • step6:不断消耗S chunk,S至M/2大小的chunk都会被用掉,一定会有一个落在刚刚释放出来的M*中。这里消耗S chunk就是不断mmap,产生页表项。
  • 判断是否达到临界条件:/proc/zoneinfo,/proc/pagetypeinfo

  • exploit:页表指向自身,写页表,任意地址读写

0->1,1—>0 不能超出攻击者的控制范围

  • 不可利用的flip:
    1. 位于page的后半部分 (ARM shadow pagetable)
    2. 位于32bit word的低12bit,PTE,页内偏移
    3. 位于32bit word的高11bit,L=4M时L中有512=29个页

一个页中可以利用的flip bit大约为7%

Implementation

  • android ion memory ,/dev/ion,用户空间获得uncached、物理连续的内存
  • 减少其他程序的干扰

Evaluation

Fig

Fig

  • Root Privilege Escalation
  • 寻找内核空间中的struct cred,并比较是否是攻击者进程的,通过访问不同page来刷TLB
  • 大约需要20s

Mitigation & Discussion

已有的措施:

  • 硬件:ECC,LPDDR4 Target Row Refresh
  • 软件:
    • 禁止cache有关指令 clflush
    • 封掉物理地址接口 pagemap

针对drammer的方法:

  • 限制用户空间的接口:google倾向于让设备提供商的代码运行在用户空间而不是kernel,限制ioctl
  • 隔离DMA的内存和其他内存:ION使得用户在ZONE_LOWMEM分配内存,而ZONE_LOWMEM通常是被kernel和pagetable使用的

vusec github

The Misuse of Android Unix Domain Sockets and Security Implications

论文下载

摘要

在本文中,作者针对Unix domain sockets(Android LocalSocket和跨层通信)的安全性进行了讨论和研究,并开发了一套半自动化工具,利用鉴别socket的地址、认证过程、数据流分析等技术检测和分析相关的安全漏洞。

背景

Fig

SInspector

Fig

  • 对APP的检查:首先检测APP是否含有Intnet权限、Java的API使用,native中API的使用。然后分析socket的安全性。每一次都如果有socket的连接,均会产生相应的文件。这个过程会检查系统产生的Socket文件是否是安全的,包括访问权限、配置和文件路径。然后检查认证过程中PID UID GID是否匹配。最后用程序分析的方式检查那些APP是否真的执行了那些含有Unix Domain Sockets的代码。
  • 对于系统服务的分析:采用动态分析的方式,收集runtime date。然后,Connection Tester模拟正常的client连接这些server,如果socket是安全的,就会拒绝这种连接。
  • 对于上述检测出来的可能有问题的APP、系统服务,人工验证。

RESULTS

  • 选取了google play中14,644个APP,3,734 (25.5%)用了Unix domain sockets。APP平均2,502秒一个,系统服务平均39秒一个。

Fig

Case study

  • 一键root工具:由于基于FILESYSTEM的socket在这种模式下的权限是全部可读可写可执行,任何app都可以在需要root的app发送自己的信息给su之前截获,恶意APP可以阻止或者授权APP获取root。
  • ES文件浏览器:在root模式下,没有检查client的合法性,任何APP可以读取隐私文件和受到保护的系统文件。
  • OpenVPN:由于文件权限没设置好,任何APP都可以通过OpenVPN的管理界面获取管理权限DOS。
  • LG手机用来初始化wifi的服务system/bin/atd:没有检查client的合法性,任何具有inet权限的APP可以通过这个系统服务出厂化手机。
  • LG手机的/system/bin/time_daemon:只检查了client的包名是否包含comm.timeservice,可以绕过。
  • Bluetooth

建议

  • 操作系统级的:默认的ABSTRACT很不安全,强行改变默认的模式或者更加细粒度的SEAndroid策略。
  • 从framwork层面解决。

EdgeMiner: Automatically Detecting Implicit Control Flow Transitions Through the Android Framework

论文下载

摘要和简介

当下,大多数静态分析工具通过手工添加或者是一些启发式的算法对回调函数建模。比如Flowdroid,通过类似白名单的方式,手工定义了这些可能用到的回调函数,这两种方法是不精确的,并不能完全的分析所有的回调函数,使得一些恶意程序能够通过一些隐式控制流的方法躲避分析工具的检查。

作者根据上述问题,提出一种静态的分析工具EdgeMiner。它能够通过分析整个android框架,寻找框架中描述隐式控制流的注册函数和回调函数对。同时,EdgeMiner的运行结果可以辅助当下比较流行的静态分析工具,提高精确度。

EdgeMiner的分析框架

Fig

  • 回调函数是一种需要应用实现,但是由android框架去调用。由于这种函数的特征,会导致一般绘制调用图的时候没有对应指向的边,当静态分析工具利用不精确的调用图去分析,其结果也是不精确的。
  • 将android的框架源码作为输入
  • 先提取所有可能的回调函数和调用这些回调函数的回调点的列表,然后通过前向数据流分析追踪调用点中事件的起源。如果一个事件作为注册函数的参数传入,那么这个事件可以将用户代码和框架代码连接起来,最后EdgeMiner输出这对registration-callback。

  • 预处理:EdgeMiner首先会将框架中每一个方法翻译成一个SSA的形式,然后提取类的层次结构和接口的定义,然后画出一个近似的call graph。同时,EdgeMiner在图中标记所有可能的回调函数,最后,找出一些描述类的元信息。

  • 前向数据分析:通过在使用-定义链的关系,检查每一个方法的参数传递关系、方法的调用、成员的修改和静态的定义,递归的遍历,直到发现该方法没有调用者或者回调函数的接收对象已经被定义了。

实现

  • 整个EdgeMiner用dx中使用的ROP中间语言实现。
  • 一个近似的调用图需要考虑到反射调用和native代码。
  • 反射调用:根据调用的特征,可以很快找到所有的反射调用。
  • native代码:native代码必须通过dvmCallMethod函数才能调用android的方法,根据这个特征,也能够很快找到所有的调用。

一些影响分析的因素

  1. 通过XML注册的回调函数:这种方法只使用于很少一部分回调函数,而现存在的大多数分析工具都能处理这些情况,没有必要去支持这种功能。
  2. Android Looper:其中消息传递的机制本质就是成员变量的传递,已经囊括在我们的算法中。
  3. IPC:现有的检测工具已经考虑到这种机制的影响,做了相应的处理,不需要再去添加算法。
  4. 同一个注册函数对应的不同回调函数:由于异步事件的存在,算法不能很好的计算回调函数执行的顺序,这个问题将作为作者未来的工作继续研究。

实验

Fig

Fig

在36GB内存的环境中,耗时4个小时,总共发现24089个类,196252个方法。为了检查误报率,手工分析随机抽取的200个样本,发现由于使用近似的调用表,使得有96%的误报率。为了辅助Flowdroid更加精确的分析,修改其源码,对比未修改的版本,准确度有明显的提高。

NJAS Sandboxing Unmodified Applications in Non-rooted Devices Running Stock Android

论文下载

简介

这篇文章提出了一种不修改系统,不需要ROOT,不重打包来制造一个沙盒的工具–NJAS(Not Just Another Sandbox)

特点

  • executing an Android application within the context of another one1
  • achieves sandboxing by means of system call interposition(using the ptrace mechanism)
  • no modication to the framework, no root access to the device, no require to enable unsafe options
  • cannot be evaded by using native code components

实现方法

原APP这里称为orig, 针对每个orig, 会单独生成一个stub APP。 这个stub包含orig的menifest.xml中少量基本信息,权限,组件声明等等,不包括资源文件和代码。

用户直接运行stub, stub收先会fork自身,生成一个monitor 子进程。monitor子进程会利用ptrace来在system call 层面上监督stub执行的代码,目前可以限制四个功能:network,filesystem,sms,contact。 而stub执行的代码来自orig。 stub通过从data/app目录下的apk文件中拿到orig的dex及资源文件。用classloader来读取并运行其代码。除了监控,monitor子进程还需要做一些对源代码的patch工作,来保证orig的代码可以在stub的context中正常运行。比如修改一些参数和返回值,(文件系统路径,包名等等)。

Security

by using syscall interposition, Njas is able to fully control the behavior of an app. In fact, the usage of the ptrace mechanism guarantees that the monitor process will be able to intercept every syscall invoked by orig。

  1. Java-level API
  2. native library
  3. syscall through inline assembly code

会阻止ptrace和kill指令,防止恶意APP绕过Njas

评估

Fig

Flip Feng Shui:Hammering a Needle in the Software Stack

Kaveh Razavi,Ben Gras et al. Vrije Universiteit,Usenix security’16

论文下载

Flip Feng Shui

条件:

  1. rowhammer,硬件问题
  2. physical memory massaging

过程:

  1. Memory templating:确定哪些物理地址上在rowhammer下会出现bit flip. 模板:物理地址,0-1/1-0,double-sided rowhammer
  2. Memory massaging:控制内存分配器,将敏感数据分配到有问题的物理地址上。理想情况下利用已知的模板可以修改任意的内存页(类似传统漏洞利用的任意地址写)。利用memory duplication的特性可以修改任意已知内容的victim page
  3. Exploitation: 触发bit flip,修改敏感数据。 场景设定:攻击者的VM和victim的VM在同一个host上,论文提出了哦两个攻击点 flip SSH’s authorized_keys:authorized_keys中存放用户的SSH公钥,构造出对应的私钥可以ssh登陆victim flip apt’s sources.list和trusted.gpg:souces.list保存了软件源的地址,trusted.gpg中的rsa公钥对软件包做认证。构造出合法的软件包签名可以让victim安装攻击者制作的软件包

Cryptanalysis of RSA with Bit flips.

  • 公钥n,e n常见的为1024和2048bit,e一般为65537
  • d = e-1 mod λ(n) 卡马克尔数
  • n=p*q, n为t bit,随机翻转一个bit后的值为 n’,假设n’是一个随机的奇数(LSB is trivial),
  • trivial case : 2 / ln(n’)的概率n’是素数
  • other : n’是合数,分解策略:

  • 尝试小素数 (<16bit)

  • Pollard’s p algorithm (40~60bit)
  • Lenstra’s Elliptic Curve factorization Method (<128bit)
  • General Number Field Sieve 目前已知的最好算法,最大记录为768bit

ECM的复杂度取决于素因子个数和最大的素因子。第二大素因子的期望值是0.21*t [D Knuth], n’的质因子个数分布的中值和方差是lnln n’ [Erdos], t=1024时质因子个数中值是6.56,不太可能只有两个因子;第二大素因子的期望 215bit,小于128bit的概率是0.26[D Knuth],可以使用ECM; t=2048时小于128bit的概率是0.12

结论: n在1024-2048bit时,任意的bitflip,可以有效分解n’的概率是12-22%

Implementation

  • KSM:Kernel same-page merging
  • THP:Transparent Hugepage

为了提高内存利用,kernel会将相同内容的虚拟页映射到同一个物理页上,修改时再分开。将后出现的页 映射到先出现的页的物理地址上(更新页表)。已知target内容时,攻击者将自己的页面merge,之后victim出现相同内容的页面时会被映射到攻击者的物理地址上

  • DIMM常见的row size是128kb >> 4kb页面
  • rowhammer是需要连续的物理地址,特别是在double-sided时。guest的物理地址映射到host的虚拟地址再映射到host的物理地址,论文利用Transparent Hugepage来解决,大页面2MB, 透过host映射到连续的物理地址。

  • KSM和THP同时的问题:KSM暂时不支持hugepage。。。

  • OpenSSH: authorized_keys,base64encode,(n,e),n’,factor

  • GPG:autoupdate,source.list URL flip,trusted.gpg flip

Evaluation

OpenSSH

Fig

Fig

Fig

  • 300次auto end-to-end attack,84.1%成功,平均时间5.3分钟

ubuntu apt

  • ubuntu官方的key是4096bit,8192个可能值中有344个可以分解
  • ubuntu.com 1bit flip URL

  • ubuftu.com ubunt5.com ubunte.com

  • ubunuu.com ubunvu.com ubunpu.com
  • ubun4u.com ubuntw.com ubuntt.com

212s URL flip,352s gpg flip, 566s malicious package installed

Mitigation

  • Hardware:ecc,ddr4
  • Software:
    • disable KSM and THP( performance VS security,add randomness ) not good.
    • 敏感数据完整性的自我校验:例如证书的签名。
    • 文件中敏感数据不应相信内存中的缓存。
    • 更安全的KSM和THP等优化特性的设计,不能让不可信的进程控制整体的内存布局。

TypeSan: Practical Type Confusion Detection

由Vrije Universiteit Amsterdam(阿姆斯特丹自由大学)和普渡大学的人一起完成。

论文下载 CCS’16

Introduction

Typecasting在C++中被用于将一个指针对象从一个类型转换为另一个类型。但是由于C++并不强制保护类型安全以及内存安全,不安全的typecasting就会引起type confusion漏洞

  • 例如,将一个父类实例强转为一个子类类型,但是由于在父类类型的定义缺少一些子类中的成员以及虚函数声明,一旦程序随后要使用子类中的这些成员的数据或者是要调用相应的虚函数,那么程序就会将父类实例中位于同一偏移量的内存上的无关数据,当做子类类型中相关成员或者是虚函数指针进行使用。
  • CVE-2015-3077: https://googleprojectzero.blogspot.jp/2015/07/one-perfect-bug-exploiting-type_20.html

在Typecasting中,可以分为两类:upcast以及downcast。

  • upcast:将一个子类实例转化为祖先类,这一过程是安全的,子类实例中会包含所有父类的域
  • downcast:将一个父类实例转化为子孙类

because the data layout is such that an object from a derived class contains the fields of its parent classes at the same relative offsets from each other.

关于C++类继承的内存布局(单继承、多继承、虚拟继承): http://www.cnblogs.com/chio/archive/2007/11/25/971644.html

C++允许相应的upcast以及downcast,并且允许程序员指定在运行过程中是否要检查downcast的正确性。

  • C++提供了三种基本的cast函数:reinterpret_cast, dynamic_cast以及static_cast
  • 其中dynamic_cast在运行时会强制进行类型检查,因此这个函数是安全的,但是会带来昂贵的overhead开销
  • static_cast以及reinterpret_cast没有运行时类型检查来保证转换的安全性。

针对type confusion的防护可以分为两类:一种基于对象实例中虚表指针,另一种基于disjoint metadata。

System Design

本文提出了针对Type confusion的防护,在提高type-confusion检测覆盖率的同时,也降低了防护所带来的overhead。

Fig

  • instrumentation layer: 在代码编译时插入hooks来监视objects的分配,以及潜在的不安全的cast
  • type management service:编码类型信息,进行typecast的认证
  • metadata storage service:存储了pointer-to-type mapping,用于在typecast认证过程中查询object的类型信息。

runtime overhead由以下两部分组成:

  • overhead for maintaining metadata (allocating and deallocating objects)
  • overhead for explicit type checks at cast locations

本文通过新定义的两个Service来简化这两个过程的复杂度,达到缩减overhead的目的。

Instrumentation Layer

  • TypeSan在LLVM的编译过程中添加了一个pass来检测object的分配,在object分配时添加一个指令来存储相应的pointer-to-type mapping。
  • 同时当遇到一个downcast操作时,TypeSan就会插入一个调用,进行typecasting verification。

Type Management Service

  • 在针对不安全的typecast的安全检测可以分为两步,首先根据目标对象,获取对象在内存分配时的类型,根据目标对象的初始类型来检测所要转换的目标类型是否合法。

所以这个serive维持了两个表:

  • Type layout table:Type layout tables describe each relevant offset within an allocation to enable fast lookups of the offset-specific type information during a check
  • Type relationship table:用来保存每一种类型可以转换的类型。

所以在检测过程中,系统会首先根据对象的type layout来从Type layout table中确定目标对象的类型,再根据相应的Type relationship table中进行typecast的认证。

Metadata Storage Service

这个sevice是用于根据对象的基地址来查询相应的type layout table中的信息。

关键的影响因素有两点:(i) fast update operations,(ii) range-based lookups

考虑到在内存同一页面,对齐策略是一样的,可以保证每一个alignment-sized slot对应一个单独的对象。 所以作者给出了一个page table-like infrastructure,在常数时间内根据对象地址查找到相应的元信息。

Fig

Evaluation

在实验阶段,作者利用了SPEC CPU2006 C++ benchmarks以及Firefox的Octane, SunSpider, Dromaeo benchmarks。

首先通过一些自己写的microbenchmarks,检测了TypeSan在allocation-time以及typecast-time时造成的额外开销,并与CaVer进行了比较,借以说明TypeSan在记录object信息以及进行verification的时间开销是常数级别的。

Fig

Fig

接下来针对SPEC以及Firefox,检测了TypeSan的Performance overhead以及Memory usage:

Fig

最后检测了检测覆盖率,依旧是和CaVer比较,检测包括了Object Allocation的识别率以及Typecast的识别率:

Fig

WuKong: A Scalable and Accurate Two-Phase Approach to Android App Clone Detection

ISSTA’15

论文下载

Abstrat

  • 本文介绍的是一种重打包检测的框架,相比以往的重打包检测,本文的特点是:分类粗粒度和细粒度两种检测模式,兼顾效率与精度,在检测初始可以排除第三方库,自动识别不需要白名单,提高检测准确率。
  • 对于效率与精度,之前有过的方法,主要是基于hashing的方法和程序依赖图方法,前者速度快精度差,后者精度搞速度慢。
  • 第三方库的处理上,现有的方法都是白名单过滤,但建立白名单需要预先知识,无法完全自动化。

Overview

本文针对上述问题给出的核心方法是两个,一是用聚类的方法实现自动化的第三方库识别,二是使用两步方式进行相似性检测,先通过粗粒度筛选找出备选APP,然后再进行细粒度比较。

Fig

第三方库识别中采用了聚类的方法,先反编译成SMALI代码,然后提取smali代码中的特征,这里的特征指的是不同API调用的次数

两步检测方法

  1. 粗粒度检测:
    • 特征向量为每个API调用的频率,使用曼哈顿距离,如果两个APP的距离超过阈值且签名不同则列为进一步检测对。
    • 在进行大规模比较的时候作者提到了一个技巧,两两比较计算量很大,实际操作中,如果两个APP的API种类数相差很大,那么就退出对比。
  2. 细粒度检测:
    • 细粒度检测的方法是分析一个context下的变量出现的次数,计数方法有三种,一种是简单的记录出现次数,一种是in-statement的计数,例如每个变量if判断下出现的次数,变量进行加操作的次数,最后一种是inter-statement的计数,例如循环展开,变量在每次循环中涉及的次数。

Evaluation

Fig

实验选取了一共10W个APP,来自5个不同的应用市场,预处理中,一共收集了440W个sub-package,图6是每个subpackage调用的API数量

Fig

预处理结果,过滤第三方库聚类的效果

Fig

Fig

处理之前超过70%的app包含有8到127个非空的sub-package,平均每个app包含41.8个。处理之后,大部分app包含1-32个subpackage,平均只有15.8个。

Fig

粗粒度检测

一共需要检测的app pairs大约50亿,经过粗粒度检测,剩下9W多app pairs需要检测。涉及的app为14702个。

Fig

结果验证,对于false positives,作者随机选取了2W个APP,将分析结果与Androguard的结果进行对比,结果显示,所有检出的重打包应用均为真实的重打包,所以作者说他们的工具没有false positive,此外他们还检测出了一些Androguard没有检测出的重打包应用。

此外作者在设计样本时人工生成了一些重打包应用,放到样本集中,最终没有一个漏报。由于无法建立ground truth,所以无法做false negative的实验

Towards a Complete View of the Certificate Ecosystem

IMC’16

论文下载

Abstract & Introduction

  • 本文比较了不同的PKI测量方式,比如扫描Alexa流行站点、扫描IPv4地址空间、搜索Censy数据集、查询CT记录,被动监视网络等,发现各有不足。Censys和CT记录两个数据集能覆盖99%以上的证书。
  • 同时研究发现不同的测量方式会影响相关的研究结果(比如受Freak攻击影响的网站数量)。

Certificate Perspectives

Fig

Results

  • Certificate Transparency的局限性:只能覆盖90%的证书。
    • 部分CA不把自己的证书提交到CT。
    • 一些基于TLS的服务没有把证书提交到CT,比如mail、VPN等。

Fig

  • Censys的局限性:只能覆盖38%的证书。
    • 扫描不支持SNI,而有的CA签发的证书只能通过SNI访问,比如CloudFlare。
    • 很多证书不在公开的站点上使用,比如Let’s Encrypt签发的很多证书。
  • SNI的应用:
    • 扫描了3000w个域名,结果如表4.
    • Alexa前100w的网站,基于IP的扫描会漏掉27%的证书和65%的网站。
  • 被动流量监测:
    • 会包含IPv6的证书,822,338个IP地址里8.2%的是IPv6的地址,出现4,512个证书,仅218个没出现在别的数据集里。
    • Notary数据集里仅9.7%的链接没使用SNI。
    • 有3,805个证书在别的数据集里没见过,由于被动监测周期长,大部分是过期了的。

Fig

对HTTPS研究的影响

Fig

Fig