面向云计算平台的虚拟机同驻方法

刘维杰，王丽娜，王丹磊，尹正光，付楠



面向云计算平台的虚拟机同驻方法

刘维杰1,2，王丽娜1,2，王丹磊1,2，尹正光3，付楠1,2

（1. 空天信息安全与可信计算教育部重点实验室，湖北 武汉 430079；2. 武汉大学国家网络安全学院，湖北 武汉 430079；3. 阿里云计算有限公司，浙江 杭州 311121）

若攻击者想攻击云平台上某一目标虚拟机，则其必须与目标虚拟机同驻。基于此，提出一种虚拟机同驻方法，通过构建云环境中自适应的隐蔽信道，结合基于隐蔽信道的虚拟机同驻检测方法和自动化虚拟机洪泛策略，并在国内某知名商业云平台上进行同驻验证。实验表明，所构建的自适应隐蔽信道传输正确率可高达95%以上；所提出的同驻检测方法置信度高，误检率不超过5‰。同驻方法不会破坏云平台本身隔离性且具有一定的通用性，但潜在威胁极大，亟需重视与防范。

云计算平台；虚拟机同驻；隐蔽信道；虚拟机洪泛

1 引言

云计算的概念从提出到广泛应用，在短短几年的时间里经历了巨大的变革。目前，国内外的商用云计算业务都已进入蓬勃发展的重要时期，云计算也越来越多地被视为存储数据和部署服务的下一代IT基础设施。然而，多租户动态聚合、边界泛化的特点使云计算平台难以抵抗虚拟机之间共享计算资源所带来的安全威胁。其中，最主要的是虚拟机同驻威胁，即将属于攻击者的虚拟机实例运行在目标虚拟机所在的物理主机上。由于云环境“虚拟隔离、物理共存”的特点，云平台允许同驻的虚拟机共享物理主机的大部分资源，因此同驻威胁难以避免，其主要包括资源干扰、拒绝服务、隐蔽/侧信道、虚拟机跳跃、虚拟机逃逸和迁移间隙等[1-9]。恶意的虚拟机同驻会破坏云平台中数据的机密性和资源的可用性，导致严重的安全问题，对大规模企业用户和普通云租户都会造成极大危害。

如果攻击者意图实施针对云计算平台的攻击，则必须先实现其恶意虚拟机与目标虚拟机的同驻。早在2009年，Ristenpart等[10]首次提出了Amazon EC2（elastic compute cloud）平台上的虚拟机同驻方案，但是其检测同驻的方法是基于两台虚拟机之间的网络分组往返时延（RTT, round trip time）会随同驻与否而发生变化的原理，该原理过于简单，且未能考虑到云平台中复杂的网络环境所造成网络分组时延测量不准确的问题。

在判断虚拟机是否同驻方面，Bates等[11]提出利用“同驻水印”来进行同驻检测。其原理为利用检测虚拟机向外部周期性地发送网络分组，同时通过外部代理向目标虚拟机发送网络分组，通过测量网络分组通信是否有足够的时延来判断虚拟机是否同驻。然而，此方法与Ristenpart等[10]提出的同驻检测方法都依赖云平台允许虚拟机自由地和外部进行网络通信，很容易由于云平台因安全考虑将ICMP（internet control message protocol）禁止而失效[12]，且云平台一旦对不同的私有专用网进行隔离[13]，基于网络信息的同驻方案将会变得毫无用武之地。

Zhang等[14]提出了一种虚拟机同驻探测方案，其让租户将一些暂不使用的处理器缓存行留为警报行，若探测到警报行被使用或其负载与之前不同，则表明其他虚拟机使用了该处理器缓存（下文简称cache）区域，同驻检测器进程就会发出报警。同时，余思等[15]将虚拟机同驻检测问题具体化为cache负载的差异性度量，基于cache负载特征匹配来推断目标虚拟机与攻击者虚拟机是否同驻。这两种方案都根据cache的负载差异进行同驻判断，但是云平台为了降低能耗，提高资源利用率，引入了各种基于硬件特性的资源优化机制和资源隔离机制[16]，使cache的负载测量并不准确，并且计算cache负载特征方法复杂，很难保证同驻检测的实时性。

基于隐蔽信道的同驻检测方案效果好，但难以在此基础上实现虚拟机同驻[17]。针对这一问题，本文以“先假设，后验证”的思路，提出了一种面向云计算平台的虚拟机同驻方案，如图1所示。攻击者在实施同驻的过程中，需要对同驻情况进行判定，因此需要准确率高的虚拟机同驻检测手段来确定同驻情况。在攻击者有目的性地进行虚拟机洪泛后，还需借助合谋方案对目标虚拟机进行精确定位。

本文方案充分考虑具体的云计算环境，力求同驻检测正确率高且易于部署。该方案改进了现有的两种隐蔽信道，并将其运用到虚拟机的同驻检测方案中，打破了基于隐蔽信道的检测方案在现实环境难以实现同驻的壁垒；提出了一种基于后验概率的自动化虚拟机洪泛方法，有针对性地确定目标虚拟机与洪泛虚拟机的同驻。利用本方案在国内某知名商用云平台上进行实际验证，对增强现有商用云平台的安全性有重要意义。

2 云计算环境下同驻威胁模型

在公有云环境中，攻击者理论上可以通过合法渠道获得部分资源，即攻击者能够创建任意的虚拟机并对其进行管理。本文基于该事实提出如下假设。

假设1 云平台系统有良好的隔离性，云平台管理系统和其上的客户操作系统均是干净且安全的（及时更新，补丁完备），同时云管理员的操作均是善意且合规的，不存在内部威胁[18]。如此，本文中的攻击者仅通过侧信道的方式实现与目标虚拟机同驻。

假设2 云平台的各个租户之间是互不信任的，且不具有任何特殊权限。攻击者只能期望利用侧信道攻击来获取其他用户的隐私信息[19]。攻击者的目标为使用云平台的正常租户，他们利用虚拟机运行某些机密性的相关应用。

假设3 攻击者有足够的资金保证其能够开启足够多的虚拟机，同时还能够通过社会工程的方式获取目标开启虚拟机的准确时间[11]。

上述假设均符合实际应用场景，假设2中针对攻击者背景知识的假设也具有相当的普适意义。为了方便描述，下面将攻击者创建并拥有的虚拟机称为攻击虚拟机，将目标用户创建并拥有的虚拟机称为目标虚拟机。

3 基于隐蔽信道的虚拟机同驻检测

如果攻击者意图实现与目标虚拟机同驻，则必须拥有检测攻击虚拟机是否与目标虚拟机同驻的能力。于是，在描述同驻方案前，本节提出其实现的基础——基于隐蔽信道的同驻检测方案。

现有研究中，基于网络信息的同驻检测方法实现简单，检测效率较高，但是检测准确率低，只能作为其他同驻检测方法的辅助手段使用；基于资源干扰的同驻检测方法虽然实现复杂，但检测准确率较高，适用范围广。但是，随着虚拟机资源管理机制的优化以及硬件技术的不断发展，同驻虚拟机之间的相互干扰越来越难被发现[17]。基于硬件的隐蔽信道作为云平台中不可避免地存在，可被充分地应用于同驻检测中[21]。

因此，本文以准确性、高效性和实用性为目标，提出基于隐蔽信道的同驻检测方案，并以基于内存总线冲突的隐蔽信道和基于最高级缓存（LLC, last level cache）的隐蔽信道为例，实现了这两种同驻检测方案。由于该方案以云平台中的共享硬件资源为渠道构建，因此具备极强的通用性[17]。

3.1 云环境下隐蔽信道机理与构建

基于微处理器架构的隐蔽信道是多用户计算机系统中最常见的隐蔽信道类型，其主要存在于具有共享资源的系统中，如云计算环境中。不过在嘈杂的公有云环境中，微处理器架构隐蔽信道会面临更多的问题。虚拟机迁移、vCPU调度以及Hypervisor的活动增加了许多噪声，这些都给隐蔽信道精确同步带来了挑战。

图2 内存与新型LLC的映射索引

3.1.1 基于LLC的隐蔽信道

与其他隐蔽信道介质相比，cache对于攻击者更具吸引力。因为cache的高操作速度可产生高带宽，并且不受软件系统限制，可以绕过许多高级隔离机制，所以近年来基于cache的隐蔽信道备受重视[20-21]。其中，最常用的交替通信技术是Prime + Probe方法[22]和Flush + Reload[23]方法。

文献[24-25]提出了如何对该散列函数进行逆向，但这种逆向工程需要进行大量的实验，消耗大量时间。于是，文献[7]提出了一种通过构建冲突集的方法来寻找能够映射到相同cache set而虚拟地址不同的内存块。本文对这种方法进行了改进，提出了一种快速构建冲突内存块的方法，能够进一步地缩短寻找时间。改进的方法描述如算法1所示。其中，函数()为所定义的Probe访存原语。

算法1 基于LLC的隐蔽信道冲突集构建算法

输入 候选内存行lines

输出 驱逐集，每个分片一个驱逐集

(；)

读取；

for eachin set do

读取；

end for

end function

构建

随机化；

for each∈do

if not(_；)

将放入；

end for

构建

for eachindo

if(，)

for eachindo

if not(_；)

将放入；

end for

if∪≠Æ

=e∪

输出；

；

end for

通过将具有同样元素的驱逐集合并，使本文构建驱逐集的方案更加圆满，能够在每个slice对应的驱逐集中找到超过组相联路数的可供驱逐的内存行。这样，在隐蔽信道构建时，就可以更加灵活地选用任意的slice ID和set ID作为LLC冲突集的ID。

3.1.2 基于内存总线的隐蔽信道

内存总线负责处理器与主存之间的数据传输，是现代计算机系统中不可或缺的组成部分。处理器内的CPU核心都共用该内存总线。因此，内存总线上的冲突将会导致系统范围可观测的内存访问时延。因此，利用某些特定的程序行为所触发的内存总线冲突就可以构建出一种隐蔽信道[26]。x86架构中，处理器利用总线锁（memory bus lock）实现内存原子指令。对于未对齐的内存区域，执行内存原子指令会触发内存总线锁。利用这种机制，可以构建一种高速、可靠、跨虚拟机的隐蔽信道，如图3所示。

图3 基于内存总线的隐蔽信道

同样地，对现有的基于内存总线的隐蔽信道进行了改进：当发送方使用特定的原子操作时，接收方使用SSE (streaming SIMD extension)指令集的某些访存指令操作，避免访问cache，使正常访问内存总线时的访存时间不会因cache命中而产生影响，从而保证每次正常访存（总线不冲突）时的时间基本一致，进而保证了信道传输的准确性。具体如算法2所示。

算法2基于内存总线的隐蔽信道构建算法

：异常操作数原子指令

[]，[]：发送和接收数据

发送方：

for=1 to1 do

if[]=1

for=0 to1 do

M内存访问；

end for

else

for=0 to1 do

SIMD内存访问；

end for

end for

接收方：

for=1 to1 do

for=0 to1 do

SIMD内存访问；

end for

if 平均访问时间

[]=1；

else

[]=0；

end for

3.2 面向码元识别的自适应信道优化

为了解决信道在嘈杂的公有云环境中传输正确率会受到影响的问题，本文引入了自适应的码元识别技术，以此来提升传输正确率。

本文通过使用数据帧（frame）来加强通信协议对时钟漂移和调度中断的弹性。传输的数据被分成固定长度，发送方使用伪随机数生成算法来产生每一个数据帧的载荷[27]，并用起始模式和停止模式将每个数据段构造成数据帧。这种方式具备两个优点：①当发送方检测到传输中断时，不需要重传全部数据，仅需重发相关数据帧；②在传输期间总是不可避免地会丢失部分数据，利用数据帧，接收方能更加容易地定位错误，进行纠错处理。

3.2.1 信号的平滑与连续识别

由于嘈杂的云环境带来的噪声，信道若未经过去噪便进行码元识别操作，将会引入相当大的传输错误。平滑滤波技术能够过滤低频信号中的噪声，它不经由傅里叶转换，在图像处理领域被广泛应用。本文利用平滑滤波来实现信号的初筛。

经过去噪操作后，所接收的“0”和“1”的区别已经较为明显（在基于内存总线的信道中，发送“0”仅消耗约100个CPU时钟周期，发送“1”需消耗几千个CPU时钟周期；在基于LLC的信道中，发送“0”消耗约30个CPU时钟周期，而发送“1”需要消耗约100个时钟周期）。因此，采取聚类的方式来区分接收的信息即可。在此情况中，仅需要将数据分为两类，即仅需要求出聚类中心，之后再进行简单判断。由于不用考虑时间序列，需要聚类的数据仅为一维数据。在此本文采用最为简单有效的均值聚类法来实现该功能。

3.2.2 信道自适应同步与校准

由于发送方和接收方分属不同的虚拟机，它们之间的调度差异将导致数据传输和检测过程不同步，进而对信道的调制造成很大的问题。本文通过自时钟编码克服时钟失步，并使用差分曼彻斯特编码传输数据位。更重要的是，当通信双方传输起始时间不同时，有很大的概率导致传输的数据极不连续。同时，为了减少重发次数，节省时间开销，必须确保发送方和接收方的时隙是对齐的。如果没有对齐，两者将在重叠的时间内争用该信道并引入位翻转错误。这种不受限制的争用会导致“0”和“1”的值的可分离分布较少，加剧发送方和接收方的竞争，明显降低信道的容量与可用性。针对这个问题，本文提出时钟同步与接收确认机制来提高信道可靠性，如算法3所示。其中，()与()分别表示发送帧与接收帧的函数方法，()表示搜索并微调当前帧延时的函数方法。

算法3 自适应的信道同步算法

[]，[]：发送和接收数据

()：信道传输正确率计算函数

发送方：

for<1 to 20 do

([])；

=+1；/* 微调1 μs */

end for

确定；

接收方：

for<1 to 20 do

([])；

end for

=([])；

本文提出的同步协议能够实现在几百μs的时钟差异内，实现高精度的对齐传输。通过在隐蔽通道上传送一个已知的比特序列来进行多轮处理。在每次通信之后，发送方将其时钟移动1 μs，稍微改变两个进程的执行起始时间。随着时钟变得更加同步，两个进程的争用变得更加一致。一旦达到最高正确率后，发送方的每次移位都会降低信道的传输正确率。此时，接收方通过测量最高正确率便可能定位到最佳的移位大小。同步过程的耗时取决于用于测试的分组大小，基本上每个虚拟机只需要执行一次即可完成同步。

4 面向云平台的虚拟机同驻方案

由于虚拟机同驻造成的危害越来越大，研究人员在云平台的虚拟机投放策略上提出了抵御同驻危害的方法。已有研究[28-29]提出虚拟机动态部署算法，基于云提供商协助的VM迁移服务，通过不断地重新部署VM，使任意两台VM间不存在足够长的同驻时间，从而限制由侧信道引发的信息泄露。上述方法虽然能够在一定程度上抵御同驻威胁，但其防御窗口过长，仍无法从本质上防止虚拟机实例洪泛造成的同驻。

虚拟机实例洪泛，即攻击者在同一时间、同一个云平台可用区，开启大量的虚拟机实例。这些实例可能是攻击者利用自身账号投放，也可能是通过其控制的虚拟机僵尸网络投放。虚拟机实例洪泛本质上是对云平台虚拟机分布策略的滥用，但其并不违反云平台的商业策略和服务等级协议。

当攻击者实例开启时间接近受害者虚拟机实例开启时间时，攻击者可以有效地利用云平台平行放置的部署算法来实现一定概率的攻击者实例与受害者实例同驻。由于云计算的动态特性，服务器通常在实例上运行，不需要时终止，稍后再运行。例如，攻击者可以监视服务器的状态（如通过网络探测）直到该实例消失，然后在发现一个新实例（该服务）重新开启时进行实例洪泛。攻击者甚至可以利用该特点主动触发新的目标虚拟机实例。

4.1 基于后验概率的虚拟机洪泛覆盖

本节提出了一种基于后验概率的自动化虚拟机方案。通过该方案可以得出：①被攻击的虚拟机分布在各台物理主机的概率；②本次投放VM flooding虚拟机时，每一台攻击虚拟机与被攻击的目标虚拟机同驻的概率。该方案的总体思路为先大量投放虚拟机，再对所投放的虚拟机进行同驻检测，将确定为同驻的虚拟机归类，最后对所投放的虚拟机进行约减。具体步骤如下。

在实验结果上有

记

显然式(4)为凸函数，在式(6)中引入拉格朗日乘子，代入式(4)得

当式(7)取得最大值时，自变量偏导数为0，即

将式(4)、式(6)代入式(8)，有

由式(2)、式(9)可得

上述概率可以告知攻击者如何进行下一步的攻击实验，并给予攻击者理论上的指导。例如，优先从同驻发生率较高的物理主机开始进行同驻检测，从而加快发现与目标同驻的速度。

4.2 基于合谋的同驻虚拟机远程定位

当洪泛虚拟机数量达到一定程度时，可实现云平台可用区物理主机的全部覆盖。尽管如此，攻击虚拟机如何定位目标虚拟机依旧困难。

文献[4]提出，在云计算环境下，攻击虚拟机可借助前面所述的内存总线冲突来实现云环境的拒绝服务（DoS, denial of service）攻击，具体操作方式为不断触发内存总线冲突，正如构建隐蔽信道一般[30]，造成大量内存访问时延，从而达到平台上其他虚拟机无法正常使用内存的目的。除了该内存总线占用漏洞外，利用内存行锤击漏洞也可造成虚拟化平台的服务等级下降甚至停止。攻击虚拟机可通过不断锤击具有关键数据的内存行（如Hypervisor所维护的EPT/NPT页表），使整个虚拟化平台暂停服务[2-3]。本文基于上述DDoS攻击，结合合谋攻击的思路，提出一种能够快速定位目标虚拟机的方法。

5 同驻实验与行业验证

在对本文提出的同驻方案验证之前，首先对所提的基于隐蔽信道的同驻检测方案进行了实验验证，以确保该同驻检测（判定）方案在之后的方案验证中得到最大程度的效用。

5.1 虚拟机同驻判定

5.1.1 同驻阈值计算

为了确定传输正确率与虚拟机是否同驻之间的关系，选取分布在两台物理主机上的共10台虚拟机之间进行隐蔽信道通信实验。以基于内存总线的隐蔽信道为例，其传输正确率与同驻状态如图4所示。

图4 传输正确率的多次采样

其中，实际同驻的虚拟机共20对，非同驻的虚拟机共25对。实验中，同驻虚拟机传输正确率最小值为90.7%，非同驻虚拟机传输正确率最大值为57.9%。两类样本间有明显间隔，因此，可以通过设定传输准确率阈值判定虚拟机是否同驻。

实际上，当隐蔽信道的参数一定时，同驻虚拟机传输正确率与非同驻虚拟机传输正确率均为客观上的定值。由于实验数据的局限性和某些可能出现的噪声的影响，传输正确率符合正态分布。为了确定虚拟机是否同驻的判定阈值，需要先由样本估计出正态分布的参数，然后经过计算得到最优的判定阈值。

不同驻时传输正确率分布函数为

最优判定阈值应满足

5.1.2 检测效果评估

通过上述计算得到判定阈值后，重新对3台同样的物理主机上的共15台确定编号的虚拟机进行隐蔽信道通信实验。为了尽可能地模拟实际云平台环境，所有虚拟机每15 min进行一次随机迁移(目标主机不确定)。

以基于内存总线的隐蔽信道实现为测试工具，同样每15 min对105对虚拟机进行同驻检测，每次检测持续8 s，持续测量1 h，实验结果如表1所示。

表1 同驻检测效果评估

通过表1可以看出，本文提出的同驻检测方法具有极低的误检率和漏检率。这一方面是由于对两种隐蔽信道的实现做出了改进，且充分考虑到云环境中的噪声和其他不良影响，对信道的通信进行了针对性的优化；另一方面是由于所设的判定阈值具有较好的置信度。随后，本文提出的同驻检测方法在实验室环境中检测成功的前提下，将此方法应用于商用云平台的同驻检测中，通过虚拟机洪泛碰撞的方式使两台云实例同驻。

5.2 同驻方案行业应用验证

现阶段，国内公有云服务竞争激烈。其中，某云平台（下文中简称α云）作为行业标杆，其他公有云服务平台架构与其极为类似。因此，为了使实验结果具有标准性和普适性，本文选取α云作为目标，对其商业策略和服务等级协议进行研究，并在α云上有针对性地利用前面提出的VM flooding攻击方案进行了一系列实验。

目前，在物理基础设施方面，α云提供了5个配置自由度，分别是：①地域；②可用区，可用区是指在同一地域内，电力和网络互相独立的物理区域，通常为一个机房；③~⑤实例系列，实例系列代表着不同的硬件系列，分别为系列Ⅰ、系列Ⅱ、系列Ⅲ。其中，不同系列采用不同的CPU类型，且其内存也不尽相同。在上述5个自由度中，前两个（地域和可用区）属于对地理位置的配置，而后3个属于对实例类型的配置。本文选择华南1-可用区A进行投放实验，后续如无特殊说明，虚拟机实例都在该可用区创建。

5.2.1 自动化同驻检测

为了能够对每个虚拟机实例进行同驻检测，每个虚拟机实例上都必须安装隐蔽信道通信程序。因此，首先创建了一个含有隐蔽信道发送和接收程序的镜像Image-covert-channel，其用户操作系统为64 bit Ubuntu14.04。后续的虚拟机实例均以此镜像为模板创建。

为了更进一步实现同驻检测的自动化，本文基于Ansible开发了配置管理与自动化运行工具，通过SSH（secure shell）连接服务器并运行配置任务。它非常适合将bash脚本转换成Ansible任务，并且由于其基于SSH，因此更易于检查运行结果。Ansible同样支持在α云或其他大型商用云（如Amazon EC2）中采用组（group）的形式管理虚拟机并遍历组内的所有主机。由此，使用add_host模块动态创建一个由这些新实例组成的group，便于在后续任务中立即在主机上执行所需操作。

图5 ACD工作流程

5.2.2 同驻实验案例研究

由于考虑到CPU核数和内存大的虚拟机可能被分配到更具特殊性的物理机中，首先用账号甲同时创建了n1.small和n1.medium虚拟机实例各50台，基于第3节提出的同驻检测方法，对其进行两两检测。检测结果显示，任意两台虚拟机都不同驻。再考虑到独享型的虚拟机可能被分配到更具特殊性的物理机。继续用账号甲同时创建了n2.small和n2.medium虚拟机实例各50台，对其进行两两检测。检测结果显示，任意两台虚拟机都不同驻。结果如表2所示。

表2 单一账号同时创建多台虚拟机

基于上述推测可知，单一账号的同驻情况并不理想。于是，本文调整最初的洪泛策略，使用多个账号进行实验。

首先，改用两个账号分别同时创建了5台sn1.medium虚拟机实例，对其进行同驻检测，检测到一对虚拟机同驻，其实例ID分别为i-wz91n5w6 koukiloem6lj和i-wz952qiz9n49r2vj5yyg。

以i-wz91n5w6koukiloem6lj作为发送方，i-wz952qiz9n49r2vj5yyg作为接收方，采用经过调试的最优参数：=6 700、=300、=7，测量隐蔽信道传输正确率高达95.3%，其传输效果如图6所示。其中，发送信息被封装到一个frame中，“+”“−”分别代表所发送的“1”和“0”。后续如无特殊说明，所有同驻实验均采用上述参数作为输入。

(a) 发送方

(b) 接收方

图6 隐蔽信道在α云上的检测效果

之后，用甲、乙、丙这3个账号分别同时各创建了5台sn1.medium型实例，共15台实例。为了进一步具体测量同驻产生率，本文分别使用两个账号同时创建5台sn1.medium虚拟机及3个账号同时创建5台sn1.medium虚拟机，并进行50次重复实验。其中，当两个不同账号同时创建medium型实例各5台时，有48%的概率实现一对虚拟机同驻；当3个不同账号同时创建实例各5台时，有90%的概率出现至少一对虚拟机同驻，有82%的概率出现至少两对虚拟机同驻，有52%的概率出现3对虚拟机同驻。另外，观察到同驻的这两台虚拟机分别处于两个不同的内网网段，因此判断α云有极大可能使用了类似VPE[13]或VxLan的网络隔离措施来构建安全组或私有云的网络边界。

采用更多的账号进行了相同的实验。当使用4个账号甲、乙、丙、丁同时创建sn1.medium虚拟机实例时，共出现了35对同驻。其中，有两台物理机上同驻了4台虚拟机，3台物理机上同驻了3台虚拟机，14台物理机上同驻了两台虚拟机，另外，75台物理机上只分配到一台虚拟机，总计120台虚拟机被部署到了94台物理机上。同时，5个账号与6个账号同时创建共120台虚拟机的同驻结果如表3所示。由表3可知，当账号越多时，同驻情况越好，实证了5.2.1节所提出的假设。

接着，为了探究虚拟机同驻概率与实例类型之间的关系，本文对n1.tiny、sn1.medium、sn2.medium这3种类型的实例进行了实验。此次实验使用了12个账号同时各创建一台虚拟机，重复实验50次，同驻结果如表4所示。可以看出，sn1.medium型实例的平均同驻对数略高于其他两种类型。

表3 多账号同时创建多台虚拟机

表4 多账号同时创建不同类型实例

由上述分析可知：当账号越多时，同驻比例越大；当实例类型为sn1.medium时，同驻比例最大。因此，为了进一步对本文所提的洪泛策略进行改进与实验验证，在36 d时间内α云使用高峰时间段（晚8时—晚9时），使用12个账号同时开启共360台、480台和600台sn1.medium型实例各10次。具体情况如图7所示。

图7 大规模虚拟机实例洪泛

由图7(c)可知，110台物理主机中，载有5个和6个同驻虚拟机的数量最多，分别有32台和31台。所有的物理主机均有3个及以上同驻虚拟机，单台物理主机上最大的同驻虚拟机数为9。由第4节结论可知：在同一时间再开启10~15个虚拟机，有约15%~21%的概率使攻击虚拟机与这9个目标虚拟机同驻。另外，在所有的12个账号中，每50个实例均被投放到了40~43台物理主机上，其中，载有两个虚拟机的物理主机均不少于6台。

图8显示了采用上述基于后验概率洪泛策略进行有针对性的虚拟机投放时，仅使用2、5、10个账号迭代开启虚拟机时同驻的覆盖率。从图8可以看到，当投放数量超过100时，同驻覆盖率有大幅提升；当使用5个不同账号投放72次（360台虚拟机实例）时，同驻覆盖率就已经接近90%；当使用10个不同账号投放25次时，覆盖率超过95%；当投放实例数超过500时，无论使用多少数量的账号，都可基本实现全部覆盖。

图8 同驻覆盖比

5.2.3 实验结果分析

通过历时多个月的同驻实验，可以发现与验证如下规律。

1) 现阶段α云对于同驻威胁做出了基本的防护，采取了一些简单的应对措施。首先，ICMP分组被禁止使用于网络探测，不同用户的虚拟机之间的网络与其所处的物理主机无关。其次，同一账号的虚拟机在正常情况下无法被分配到同一物理机。

2) 不同账号同时创建相同可用区、相同实例类型的虚拟机时，产生同驻的可能性极大，且采用的账号越多，攻击成功率越高。实例类型对于同驻率的影响不大。

3) 当启动大量的虚拟机来进行VM flooding实验时，由于物理主机的数量远小于开启的实例数，同一账号的虚拟机无法被分配到同一物理机的规律被打破。在同一时间大量虚拟机被分布在百余台物理主机上，基本覆盖了该可用区子网的物理主机，充分说明了该洪泛策略的可行性。

6 结束语

本文对适用于商用云平台的虚拟机同驻方案进行了研究。以“先假设，后验证”的方式来完成攻击虚拟机与目标虚拟机的同驻，且在强安全条件下依旧有效。该方案能够使攻击者快速实现恶意虚拟机与目标虚拟机的同驻，尽可能地减少不必要的开销。

[1] DESNOS A, FILIOL E, LEFOU I, et al. Detecting (and creating!) a HVM rootkit (aka BluePill-like)[J]. Journal in Computer Virology, 2011, 7(1): 23-49.

[2] RAZAVI K, GRAS B, BOSMAN E, et al. Flip feng shui: hammering a needle in the software stack[C]//Usenix Security Symposium. 2016: 1-18.

[3] XIAO Y, ZHANG X, ZHANG Y, et al. One bit flips, one cloud flops: cross-VM row hammer attacks and privilege escalation[C]//Usenix Security Symposium. 2016: 19-35.

[4] ZHANG T, ZHANG Y, LEE R. DoS attacks on your memory in the cloud[C]//ACM Symposium on Information, Computer and Communications Security. 2017: 253-265.

[5] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Fine grain cross-VM attacks on Xen and VMware[C]//ACM Conference on Cloud Computing. 2014: 737-744.

[6] IRAZOQUI G, INCI M S, EISENBARTH T, et al. Wait a minute! a fast, cross-VM attack on AES[C]//International Symposium on Recent Advances in Intrusion Detection. 2014: 299-319.

[7] LIU F, YAROM Y, GE Q, et al. Last-level cache side-channel attacks are practical[C]//IEEE Symposium on Security and Privacy. 2015: 605-622.

[8] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Cross processor cache attacks[C]//ACM Conference on Computer and Communications Security. 2016: 353-364.

[9] YAROM Y, GENKIN D, HENINGER N, et al. CacheBleed: a timing attack on OpenSSL constant time RSA[C]//International Workshop on Cryptographic Hardware and Embedded Systems. 2016: 346-367.

[10] RISTENPART T, TROMER E, SHACHAM H, et al. Hey, you, get off of my cloud: exploring information leakage in third-party compute clouds[C]//ACM Conference on Computer and Communications Security. 2009: 199-212.

[11] BATES A, MOOD B, PLETCHER J, et al. Detecting co-residency with active traffic analysis techniques[C]//ACM Conference on Cloud Computing. 2012: 1-12.

[12] XU Z, WANG H, WU Z, et al. A measurement study on co-residence threat inside the cloud[C]//Usenix Security Symposium. 2015: 929-944.

[13] 王丽娜, 张浩, 余荣威, 等. 基于VPE的可信虚拟域构建机制[J]. 通信学报, 2013, 34(12): 167-177.

WANG L N, ZHANG H, YU R W, et al. Building mechanism of trusted virtual domain via the VPE[J]. Journal on Communications, 2013, 34(12): 167-177.

[14] ZHANG Y, JUELS A, OPREA A, et al. HomeAlone: co-residency detection in the cloud via side-channel analysis[C]//IEEE Symposium on Security and Privacy. 2011: 313-328.

[15] 余思, 桂小林, 张学军, 等. 云环境中基于cache共享的虚拟机同驻检测方法[J]. 计算机研究与发展, 2013, 50(12): 2651-2660.

YU S, GUI X L, ZHANG X J, et al. Co-residency detection scheme based on shared cache in the cloud[J]. Journal of Computer Research and Development, 2013, 50(12): 2651-2660.

[16] LIU F, GE Q, YAROM Y, et al. CATalyst: defeating last-level cache side channel attacks in cloud computing[C]//IEEE International Symposium on High Performance Computer Architecture. 2016: 406-418.

[17] 梁鑫, 桂小林, 戴慧珺, 等. 云环境中跨虚拟机的cache侧信道攻击技术研究[J]. 计算机学报, 2017, 40(2): 317-336.

LIANG X, GUI X L, DAI H J, et al. Cross-VM cache side channel attacks in cloud: a survey[J]. Chinese Journal of Computers, 2017, 40(2): 317-336.

[18] 王国峰, 刘川意, 潘鹤中, 等. 云计算模式内部威胁综述[J]. 计算机学报, 2017, 40(2): 296–316.

WANG G F, LIU C Y, PAN H Z, et al. Survey on insider threats to cloud computing[J]. Chinese Journal of Computers, 2017, 40(2): 296-316.

[19] WANG L, LIU W, KUMAR N, et al. A novel covert channel detection method in cloud based on XSRM and improved event association algorithm[J]. Security and Communication Networks, 2016, 9(16): 3543-3557.

[20] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. S$A: a shared cache attack that works across cores and defies VM sandboxing-and its application to AES[C]//IEEE Symposium on Security and Privacy. 2015: 591-604.

[21] 沈晴霓, 李卿. 云计算环境中的虚拟机同驻安全问题综述[J]. 集成技术, 2015, 4(5): 5-17.

SHEN Q N, LI Q. Review on co-residency security issues of virtual machines in cloud computing[J]. Journal of Integration Technology, 2015, 4(5): 5-17.

[22] OSVIK D A, SHAMIR A, TROMER E. Cache attacks and countermeasures: the case of AES[C]//Cryptographers’ Track at the RSA Conference. 2006: 1-20.

[23] YAROM Y, FALKNER K. FLUSH+RELOAD: a high resolution, low noise, L3 cache side-channel attack[C]//Usenix Security Symposium. 2014: 719-732.

[24] MAURICE C, SCOUARNEC N L, NEUMANN C, et al. Reverse engineering intel last-level cache complex addressing using performance counters[C]//International Symposium on Recent Advances in Intrusion Detection. 2015: 48-65.

[25] IRAZOQUI G, EISENBARTH T, SUNAR B, et al. Systematic reverse engineering of cache slice selection in intel processors[C]//Euromicro Conference on Digital Systems Design. 2015: 629-636.

[26] WU Z, XU Z, WANG H, et al. Whispers in the hyper-space: high-bandwidth and reliable covert channel attacks inside the cloud[J]. IEEE/ACM Transactions on Networking, 2015, 23(2): 603-615.

[27] PAAR C, PELZL J. Understanding cryptography: a textbook for students and practitioners[M]. Springer Science & Business Media, 2009.

[28] LI P, GAO D, REITER M K, et al. Replica placement for availability in the worst case[C]//International Conference on Distributed Computing Systems. 2015: 599-608.

[29] MOON S, SEKAR V, REITER M K, et al. Nomad: mitigating arbitrary cloud side channels via provider-assisted migration[C]//ACM Conference on Computer and Communications Security. 2015: 1595-1606.

[30] LIU W, GAO D, REITER M K. On-demand time blurring to support side-channel defense[C]//European Symposium on Research in Computer Security. 2017:210-228.

[31] NEEDLEMAN S B, WUNSCH C D. A general method applicable to the search for similarities in the amino acid sequence of two proteins[J]. Journal of Molecular Biology, 1970, 48(3): 443-453.

[32] VARADARAJAN V, ZHANG Y, RISTENPART T, et al. A placement vulnerability study in multi-tenant public clouds[C]//Usenix Security Symposium. 2015:913-928.

Virtual machine co-residency method on cloud computing platform

LIU Weijie1,2, WANG Li’na1,2, WANG Danlei1,2, YIN Zhengguang3, FU Nan1,2

1. Key Laboratory of Aerospace Information Security and Trusted Computing, Ministry of Education, Wuhan 430079, China 2. School of Cyber Science and Engineering, Wuhan University, Wuhan 430079, China 3. Alibaba Cloud Computing Co., Ltd., Hangzhou 311121, China

If the attacker wants to compromise a target virtual machine on a cloud platform, the malicious virtual machine must be co-resident with the target. Based on this, a virtual machine co-residency method was proposed. The method combined a co-residency detection scheme based on covert channel construction and an automatic virtual machine flooding strategy, and was evaluated on a well-known domestic cloud platform. Experiment shows that the adaptive covert channel can achieve accuracies of 95%, the proposed detection scheme has strong robustness whose false positive rate is less than 5 ‰, the proposed method is versatile and keeps the virtualization isolation barrier intact, which has great potential threat and should be paid great attention and precaution.

cloud computing platform, virtual machine co-residency, covert channel, virtual machine flooding

TP309

A

10.11959/j.issn.1000−436x.2018241

刘维杰（1991–），男，湖北武汉人，武汉大学博士生，主要研究方向为虚拟化安全、图像处理等。

王丽娜（1964–），女，辽宁营口人，博士，武汉大学教授、博士生导师，主要研究方向为多媒体安全、云计算安全、可信计算等。

王丹磊（1992–），男，湖北武汉人，武汉大学硕士生，主要研究方向为机器学习、信息内容安全等。

尹正光（1989–），男，江西吉安人，硕士，阿里云计算有限公司高级开发工程师，主要研究方向为cloud native和IaaS架构等。

付楠（1993–），女，江西九江人，武汉大学硕士生，主要研究方向为网络安全、云计算安全等。

2018−04−03；

2018−06−29

王丽娜，lnwang@whu.edu.cn

国家自然科学基金资助项目（No.U1536204）；中央高校基本科研业务费专项基金资助项目（No.2042018kf1028）

The National Natural Science Foundation of China (No.U1536204), The Central University Basic Business Expenses Special Funding for Scientific Research Project (No.2042018kf1028)