虚拟化环境中的隐蔽通道检测

虚拟环境中的隐蔽通道实现与检测

摘要

可以说，一个系统的安全性仅与其最不安全的组件相当。由于虚拟化是云最重要的组成部分，攻破虚拟化就相当于攻破云本身。这正是隐蔽通道所能够实现的——“隐蔽通道”是一个既真实又古老的概念；它们利用共享资源甚至网络来传输机密信息。隐蔽通道难以检测，尤其是在当今服务器托管成千上万虚拟机的情况下。然而，这并非不可能完成的任务。
本文证明，尽管隐蔽通道对云构成真实威胁，但仍可以高精度地对其进行检测。我们还深入介绍了一种利用基于CPU负载的技术在虚拟机之间传输数据的方法。

关键词

隐蔽通道 · Security · Virtual机器 · Container基于虚拟化

1 引言

目前，我们正面临着一个真实的现象：人们并未意识到他们所使用的软件在后台执行的操作。有时，人们并不知道某个软件是否以及如何使用互联网或其他云基础设施。另一个同样真实的现象是，绝大多数用户并没有意识到自己正在使用云服务。云不仅以其新颖性著称，更因其提供的优势而引人注目：灵活性、冗余性、快速的数据传输、近乎无限的资源池，所有这些都能按需获取，而且价格并不高昂[10]。

正如该领域其他研究中所述[9], “互联网的设计初衷主要是为了具备抗毁性；它并非为安全性而设计。” 考虑到这一点，再加上任何分布式应用或服务都会带来更多的可利用漏洞区域，因此云继承了互联网的全部漏洞，并因资源管理方式——虚拟化、按需分配、外包资源[2]——引入了自身特有的漏洞，这并不令人意外。由于大型企业现在往往需要更强的共享能力、更大的数据存储空间和更高的可用性，它们开始关注云作为满足这些需求的解决方案。然而，当真正迁移到云时，安全和隐私成为一个实际问题。本文[7]中，我们证明了即使云环境仍可能成为基于CPU的隐蔽通道的受害者，也存在检测此类恶意行为的方法。本文其余部分结构如下：在第2节中，我们对当前关于隐蔽通道及其检测的研究工作进行综述。在第3节中描述了在LXC和KVM中设计和检测隐蔽通道所使用的方法，接着在第4和5节中详细展示了实验所得结果。第6节总结全文，并提出了该领域的未来研究方向。

2 相关工作

尽管虚拟化和云技术已经趋于成熟[3],，但其安全性仍然面临威胁。隐蔽通道只是针对虚拟化环境的恶意尝试之一。尽管隐蔽通道最早由Lampson于1972年提出[6],，但在如今多个用户共享资源的系统中，它仍然是一个现实的威胁[5]。
虚拟机间信息泄露仅仅是隐蔽通道所能发起的一种攻击。

在[11],中，吴等人提出了三种此类攻击。第一种针对虚拟机内隐蔽通道，这意味着同一操作系统中的两个进程若要通信，可利用隐蔽通道并通过该通道交换信息。第二种是跨平台隐蔽通道，即位于不同平台和域上的两个进程之间的隐蔽通道，可通过TCP和IP数据包头部来共享信息。虚拟机间隐蔽通道是第三种类型，意味着如果两个进程运行在不同的域中，但共享相同的硬件平台，则可以通过共享资源双向传输信息。虚拟机间隐蔽通道是一种受到广泛关注的攻击，因为它与云的核心组件——虚拟化密切相关[11]。

吴等人还在[11]中描述了一种为Xen实现的隐蔽通道检测框架。该框架由两部分组成：捕获器和检测器。捕获器在虚拟机监视器中实现，用于捕获虚拟机发出的所有系统调用。检测器位于Dom0中，负责管理捕获器收集的归一化信息。

如[8],所述，基于CPU的通道存在一些挑战，但本文的目的是确定某台特定机器是否试图建立隐蔽通道。在[1],中，作者提到了隐蔽通道检测框架中需要考虑和分析的四个参数：流量的形状、流量的规律性、流量的分布、上下文以及到达间隔时间。例如，在没有其他噪声的情况下，可以预期运行隐蔽通道的恶意虚拟机的CPU变化会随时间呈现特定的变化模式和一定的周期性。

3 云系统中隐蔽通道的架构

本文提出了一种基于CPU的隐蔽通道，将在LXC和KVM环境中进行测试。本节介绍了该隐蔽通道的架构与实现细节，以及用于检测它的方法。

隐蔽通道的实现

该隐蔽通道基于两台虚拟机尝试利用共享CPU核心作为通信手段。尽管这看起来似乎不太可能，但在现实生活中这种情况经常发生，因为云服务提供商倾向于超量分配可用资源，以从硬件中获取更多利润。我们还关注运行隐蔽通道如何影响机器的CPU活动，而这与核心是否共享无关。该隐蔽通道将数据进行分割并封装成数据包，每个数据包包含以下字段：有效载荷（四个字节，作为要发送的实际数据）、ID（一个字节，用于标识数据包是否已被接收过）以及CRC（一个字节的校验和，针对有效载荷和ID计算得出）。

隐蔽通道旨在支持全双工通信。该设计包含三部分：一部分专用于发送方，一部分专用于接收方，另一部分包含发送方和接收方共同使用的元素。

协议中使用了以下通信标记：0x17 表示确认，0x6B 表示通信请求，0xFF 表示通信结束。

发送方和接收方使用相同的机制来发送和接收比特。在传输一个比特时，若要发送“0”，则执行休眠；若要发送“1”，则执行CPU密集型操作。

Detection of a Covert Channel

由于隐蔽通道是一种云环境中的信息泄露，因此找到一种方法来确定哪些虚拟机正试图通过这种方式共享信息显得尤为重要。本节介绍了如何在KVM和LXC虚拟机上检测基于CPU的隐蔽通道。

从前一节和相关工作部分可以得出结论：隐蔽通道是一系列周期性操作。
发送方需要考虑多个方面以确保传输成功：（1）接收方已收到数据包；（2）接收方已以正确形式收到数据包；（3）接收方已收到所有数据包。为了实现这些，发送方需要接收来自接收方的确认数据包，发送计算出的校验和，最后发送数据包编号。

总之，任何数据包都应包含这些元素，因此整个传输应该是周期性的。为了确定从监控过程中获得的数据是否确实是周期性的，使用了自相关。自相关提供了在不同时间间隔内，某个时间序列数组与其自身平移版本之间相似性的表示。

所使用的自相关公式如[4]所示：
$$
r_k = \frac{\sum_{i=1}^{N-k}(Y_i - \bar{Y})(Y_{i+k} - \bar{Y})}{\sum_{i=1}^{N}(Y_i - \bar{Y})^2}
$$
(1)

在这种情况下，Y由CPU时间变化值表示，而$\bar{Y}$是Y的平均值。

隐蔽通道可能正在以每秒1比特、每秒8比特或每10秒1比特的速率传输。无法直接得知其具体速率，只能通过判断来确定。将使用连续的轮询周期，并对获得的结果进行解释，以确定某个虚拟机是否涉嫌运行隐蔽通道。

为了确定可疑的CPU活动，我们需要了解什么是正常CPU活动。为此，我们观察了一台在KVM上运行的机器。该机器浏览互联网、下载小图片、进行编译并执行简单操作。在这种情况下，虚拟化解决方案并不重要，因为无论机器运行在何种环境上，类似的操作都会导致类似的CPU活动。

对于CPU的监控，针对每个虚拟化环境使用了专用工具。对于LXC，使用了 lxc-info -SH <containername> 命令；对于KVM，则实现了 libvirt 调用。

对于LXC和KVM，使用了CPU时间。通过以不同的周期轮询CPU，计算运行隐蔽通道的两个虚拟机的CPU变化。

我们期望CPU时间的变化呈现出突然的修改，表明正在传输比特1或0。在这种情况下，我们将仅分析来自发送方机器的数据，因为接收方的过程是相同的。CPU时间变化值是自相关函数的输入值。

得到的数组被绘制成图，数值越接近1，表示移位后的值之间差异越小，从而表明在消息传输中多次使用了相同的模式。为了确定自相关数组是否具有周期性，我们需要判断其峰值是否均匀分布。如果是，则可以确定该机器正在运行隐蔽通道。

4 隐蔽通道实现的测试与结果

为了确定所提出的隐蔽通道和隐蔽通道检测两种算法的效率，我们使用了一个在同一物理主机上的Sender VM和一个Receiver VM的设置。

虚拟机发送方和虚拟机接收方正试图通过基于CPU的隐蔽通道共享信息。由于云中使用了多种虚拟化解决方案，本文重点研究该隐蔽通道在不同虚拟化解决方案上的表现情况。

隐蔽通道在每个传输间隔下运行了三遍。下面展示的实验结果包含一个表格，其中列出了每种传输间隔的测试结果，表格包含以下各列：间隔（发送消息中每个比特的时间间隔），时间（完整消息传输所用的时间），NB（传输位数），NMB（错误位数），NP（数据包数量）和NMP（畸形包数量）

LXC

表1展示了在两个Linux容器上运行隐蔽通道后获得的结果。这两个容器均运行Ubuntu 14.04，并分配了512MB内存。

间隔(μs)	时间(秒)	传输位数	错误位数	数据包数量	错误数据包数量
1000000	496	432	0	9	0
800000	396	432	0	9	0
600000	297	432	0	9	0
500000	248	432	0	9	0
300000	154.4	480	1	10	1
100000	49.60	432	0	9	0
80000	39.679	432	0	9	0
50000	24.80	432	0	9	0
20000	9.92	432	0	9	0
16000	7.93	480	1	10	1
13000	6.62	432	0	9	0
10000	6.64	576	3	12	3
8000	6.95	720	6	15	6

从表中可以看出，隐蔽通道在传输间隔从1000000微秒到13000微秒之间变化时几乎完美地工作。出现了两个畸形比特：一个是在使用300000时间间隔时，另一个是在使用16000时间间隔时。由于每个间隔都运行了三次测试，因此可以将它们视为偶然现象。显然，最佳传输间隔是13000微秒，总传输时间为6.62秒，且没有畸形比特。从10000μs间隔开始，畸形比特的数量开始增加。

在三次运行的测试中，每次测试恰好有三个畸形比特，导致出现三个畸形包，并使传输比特总量显著增加：从432增加到576，增长了33%。8000时间间隔又引入了三个畸形比特，以及另外三个畸形包，这意味着比特总数增加了66%。

下一个使用的时间间隔为7000微秒，导致在一分钟内没有数据包被传输。

注意到畸形比特几乎总是在其数据包中的首位，这表明所使用的阈值在判断比特是0还是1时不够准确。

KVM

表2包含了在两台KVM虚拟机上运行隐蔽通道后获得的结果。这两台机器均运行Ubuntu 14.04，并分配了512MB内存。

间隔(μs)	时间(秒)	传输位数	错误位数	数据包数量	错误数据包数量
1000000	496	432	0	9	0
900000	446	432	0	9	0
800000	396	432	0	9	0
700000	347	432	0	9	0
600000	297	432	0	9	0
500000	248	432	0	9	0
400000	198	432	0	9	0
300000	568	1632	79	34	25

可以明显注意到，此处成功传输的时间间隔远低于LXC：300000微秒对比8000微秒。

与LXC每个畸形数据包仅有一个畸形比特不同，在此情况下，每个畸形数据包包含3个畸形比特，每个畸形数据包最多包含36个畸形比特，占一个数据包总比特数的75%。在这种情况下，最佳传输间隔为400000微秒，总传输时间为198秒，这与LXC容器在相同间隔下获得的值相同，但远低于LXC获得的值：13000微秒的间隔对应6.62的总传输时间。

已经可以看出，所提出的隐蔽通道设计在选定的虚拟化环境中是成功的。

在LXC上，已证明8000微秒到1秒之间的传输速率是可行的，而KVM的该值则高得多：300000微秒。

根据我们的实验，KVM在300000μs的传输间隔下工作正常，超过此间隔时，大量数据包无法正确接收。对于这两种环境而言，该值是确保任何传输能够进行的最低值。在LXC上，当使用低于13000微秒的传输间隔时：如10000微秒和8000微秒，隐蔽通道会出现轻微的性能问题，这使得它成为一个更不安全的环境，具体细节将在下一节中详细说明。

5 隐蔽通道检测的测试与结果

对于每种虚拟化环境，选择了一个能够通过隐蔽通道成功传输消息的中位传输间隔，以及另外两个轮询间隔。这些间隔将用作检测算法中的CPU轮询时间。
由于无法知道隐蔽通道实际使用的传输间隔，因此确定传输间隔与轮询间隔之间的差异程度至关重要，以确保仍能检测到隐蔽通道。

每次检测测试将展示两张图表——一张包含来自CPU轮询的两个虚拟机的CPU变化图表，另一张为发送方CPU轮询的自相关结果图表。

LXC

对于LXC隐蔽通道检测，使用了以下时间间隔：隐蔽通道以200000微秒的传输间隔运行，较高的轮询间隔为1秒，较低的轮询间隔为100000微秒。
此外，无论轮询间隔如何，发送方和接收方的图表都完全处于反相状态。
然而，这还不足以说明这些容器上存在隐蔽通道（图1）。

如果对我们从发送方机器的CPU变化轮询结果进行自相关分析，我们将得到图2所示的图表。

在图2中，当我们以更高的频率进行轮询时，即每100000μs一次，这比传输速率快两倍，自相关的结果仍然是周期性的，但此时周期更长，且峰值分布不均匀，尽管它们平均相隔130个位置。

对于LXC，我们可以得出结论：使用与隐蔽通道传输间隔相同或更低的轮询间隔会产生周期性自相关结果，这有助于我们判断某个容器正在运行隐蔽通道。轮询频率高于传输间隔五倍时，并不能提供表明任何恶意活动的自相关结果。

KVM

KVM隐蔽通道检测使用了以下时间间隔：隐蔽通道在700000微秒的传输间隔下运行，较高的轮询间隔为1秒，较低的轮询间隔为300000微秒。

发送方和接收方虚拟机的CPU变化如图3所示。CPU利用率的变化与LXC隐蔽通道检测中的变化类似。同样，发送方和接收方在每个轮询间隔内的CPU时间变化图呈反相。然而，这一次由于轮询间隔非常接近，因此图表非常相似。

发送方机器CPU时间变化的自相关结果如图4所示。当以300000μs进行轮询时（该频率高于传输间隔），自相关信号的峰值平均相距130个位置，如图4所示。这并不奇怪，因为100000μs是LXC隐蔽通道传输间隔的50%，而300000μs是KVM传输间隔的42.8%。

对于KVM而言，隐蔽通道仅在300000微秒到1秒的传输间隔范围内工作，这使得检测容易得多。尝试使用小于300000微秒的轮询周期进行隐蔽通道检测毫无意义，因此可选择的轮询周期的时间间隔要小得多。由于隐蔽通道无法使用低于300000微秒的传输间隔，因此可以确定，300000微秒的轮询间隔将始终给出表明隐蔽通道明确存在或不存在的自相关结果。

前几节表明，在选定的虚拟化环境LXC和KVM中，隐蔽通道检测是可行的。我们还使用Xen进行了相同的测试，其表现与KVM类似。然而，在考虑LXC的结果时存在显著差异。LXC在多个传输周期内均能确保隐蔽通道成功运行，从而使得检测困难得多。

6 结论与未来工作

如所见，本文的范围不仅在于分析云及其漏洞，还在于表明隐蔽通道等安全威胁是可检测的。

所提出的隐蔽通道的设计验证了以下理论：无论虚拟化如何，隐蔽通道都可以用于发送信息技术。确实，客户机的特性对成功率有显著影响，但任何能够轻易破坏机器隔离和机密性规则的程序都是不可接受的。作为一种虚拟化解决方案，除了Xen和KVM等管理程序外，还有一种新概念可以提供与虚拟机相同的环境，但开销更小：LXC ‐ Linux容器。然而，已经证明使用容器需要付出代价：LXC是一种更利于隐蔽通道存在且使检测机制更难成功的环境。

通过使用特定环境工具和自相关方法，我们得出结论：运行基于CPU的隐蔽通道的虚拟机表现出异常行为，但更重要的是具有周期性。研究表明，还可以区分通信的每一个周期，从而将消息分解为更小的部分以便于分析。未来，这些截断的消息可以作为模式检测算法的输入，以尝试确定通信协议和传输的消息。