无服务器共存通信中的隐蔽通道分析

1005CoResidentEvil：与Lambdas在云中的秘密通信Anil YelamUC San Diego斯特凡·萨维奇UC San DiegoShibani SubbareddyUC SanDiego阿丽亚娜·米利安UC San Diego吉尔塔纳·甘尼桑UC SanDiego摘要“Serverless” 这些服务很受欢迎，部分原因是它们的轻量级特性以及调度和成本方面的灵活性，但是与无服务器计算相关的安全问题尚未得到很好的理解。在这项工作中，我们探讨了构建一个实用的隐通道从Paddas的可行性 我们建立了一个快速的共同居住的检测为bridas是关键，使这样一个隐蔽的通道，并着手开发一个可靠的和可扩展的共同居住的检测器的基础上的内存总线硬件。我们的技术可以动态发现共同驻留的数据库，并且非常快，在几秒钟内执行我们评估我们的方法的正确性和可扩展性，并使用它来建立隐蔽通道，并在AWS数据库上执行数据我们表明，我们可以建立数百个独立的隐蔽通道，每1000个部署的数据包，这些通道中的每一个可以发送数据的速率为2千比特每秒，从而证明通过数据包的隐蔽通信是完全可行的。CCS概念• 安全和隐私→虚拟化和安全。关键词云，制图，无服务器，共存，隐蔽通道ACM参考格式：阿尼尔·耶拉姆，希巴尼·苏巴雷迪，克尔塔纳·甘尼桑，斯特凡·萨维奇和阿尔亚娜·米里安. 2021年 CoResident Evil：Covert Communication In TheCloud With Lambdas.在网络会议2021（WWW '21）的会议记录，2021年4月19日至23日，斯洛文尼亚卢布尔雅那。ACM，纽约州纽约市，美国，12页。https://doi.org/10.1145/3442381.34501001介绍在过去十年中，组织越来越多地将其数据处理和存储需求转移到第三方“云”平台。然而，云平台的经济性是基于高水平的统计复用，因此共同租用-在同一物理硬件上同时执行来自不同客户的计算-是常态。的风险本文在知识共享署名4.0国际（CC-BY 4.0）许可下发布。作者保留在其个人和公司网站上以适当的署名传播作品的权利WWW©2021 IW 3C 2（国际万维网大会委员会），在知识共享CC-BY 4.0许可下发布。ACM ISBN 978-1-4503-8312-7/21/04。https://doi.org/10.1145/3442381.3450100与这种布置相关联的数据泄漏和干扰都得到了很好的理解，并且已经产生了大量的研究文献（从Ristenpart等人开始，[19]）以及云平台提供商采用的各种技术隔离对策。这项工作的大部分都集中在用于虚拟化专用网络连接服务器的传统概念的长寿命、重型虚拟机（亚马逊术语中的“实例”）的信息通道的风险然而，在过去的六年中，大多数最大的云提供商已经引入了一种新的“无服务器”服务模式，该模式按需执行短暂的轻量级计算 （ 例 如 ， Amazon 的 Lambda [ 14 ] 、 Google 的 CloudFunctions [ 10 ]和Microsoft的Azure Functions [ 5 ]）。 这些服务在设计上使用较轻的租户隔离机制（所谓的“微VM”或容器）以及固定的系统环境，以提供低延迟启动和减少的内存占用。反过来，无服务器系统可以支持更高级别的统计复用，从而可以为客户节省大量成本，客户的需求能够匹配此模型（例如，具有嵌入状态的事件驱动计算）。然而，与无服务器计算相关的安全问题远不如它们的重量级兄弟那么好理解。虽然无服务器计算的瞬态和动态特性给攻击者带来了固有的挑战，但其低成本和轻量级隔离也可能带来新的购买点在我们的工作中，我们通过一个单一的问题来探索这些问题：一个实际的隐蔽通道可以完全从现有的隐蔽通道提供了一种绕过传统监视或审计的数据传输方式-在虚拟化环境中，隐蔽通道通常涉及一些共享资源（例如，高速缓存），竞争为该高速缓存提供了信令手段在无服务器环境中，威胁模型是攻击者能够从目标组织内部启动或注入代码到恶意软件中，并希望将信息传达给组织外部的各方（即，他们的行为，没有任何明显的迹象。打开网络连接等）然而，无服务器上下文为实现隐蔽通道提出了许多独特的挑战。首先，lambda的物理位置是未知的，因为lambda的调度和放置由云服务提供商管理因此，没有办法安排发送lambda和接收lambda将在相同的物理硬件上执行，更不用说同时执行了。1我们将使用术语“服务”来代表未来的所有此类服务1006WWW其次，考虑到这一现实，任何无服务器的隐蔽通信协议都必须反复启动AMDA，希望至少有两个发送和接收AMDA同时驻留在同一硬件上。 这在成本合理的现有云平台上的可行性尚不清楚。第三，仅仅实现共同居住是不够的，但任何幸运的共同居住者必须能够迅速确定这一事实，然后利用他们有限的生命来实现沟通。最后，由于无服务器系统中的会合本质上是统计性的，因此任何这样的协议都必须预测干扰的可能性（即， 当多个发送AAA碰巧与一个或多个接收AAA共存时）。在本文中，我们依次解决了这些问题，并完全在亚马逊的无服务器云平台的背景下展示了隐蔽通信的可行性。具体而言，我们做出了三项关键的技术贡献：快速共居检测。利用Wu et.在[26]中，我们开发并实现了一种λ共存检测器，其是通用的、可靠的、可扩展的，并且最重要的是，快速的，对于数千个并发的λ共存检测器在几秒钟动态邻居发现。我们提出了一种新的协议，其中共同居住的多个代理使用基于硬件的隐蔽通道来通信他们的ID，以便识别彼此。该协议还允许发送方或接收方λ枚举其所有共同驻留的邻居，这是在执行隐蔽通信时避免不必要的通信干扰的要求。隐蔽通道演示我们使用我们的共存检测器在AWS上建立lambda隐蔽通道。然后，我们进行了一项研究的可行性隐蔽通信1）估计每个通道的容量和2）测量共同居住的密度-也就是说，对于一个给定数量的ERADA在同一时间点发射，有多少会成为共同居住？我们在一系列亚马逊数据中心进行这些测量，以确定有足够的lambda共存，并且隐蔽通信是可行的。我们的实现可以在https://github.com/anilkyelam/columbus上公开获得。2背景我们首先简要介绍相关主题的2.1Lambdas/无服务器函数我们在本文中重点关注无服务器功能，因为它们是增长最快的云服务之一，并且从安全角度来看研究较少。这些功能在AWS [14]上作为云函数提供，并在GCP [10]和Azure [5]上作为云函数提供，因为它们不需要开发人员提供，维护或管理服务器。 除了这种低维护之外，由于它们允许更有效地将功能打包到服务器上，因此它比虚拟机（VM）更具成本效益。此外，Apache执行的单元要小得多，而且更短暂虚拟机。例如，在AWS上，Rendas的内存上限为3 GB，最大执行时间限制为15分钟。与其他云服务一样，用户无法控制服务器的物理位置，他们的服务器在其上产生。虽然Apache在它们可以执行的计算方面受到限制（通常是用Python，C#等高级语言编写的），但它们相反是非常轻量级的，可以在很短的时间内启动和删除。云提供商在具有有限资源的专用容器（例如，fixtacker [1]），这些文件通常会被缓存并重新用于将来的数据库，以减轻冷启动延迟[2]。无服务器函数的短暂性及其有限的灵活性增加了检测共存的难度，我们将在后面讨论。虽然以前的研究主要关注性能方面，如冷启动延迟，函数实例生命周期和各种云的CPU使用率，但安全方面仍然相对不足。2.2云计算中的隐蔽通道在我们试图阐明的安全方面的Bundas，我们特别关注的可行性，建立一个可靠的隐蔽通道在云中使用Bundas。 隐蔽通道是一种绕过传统监控或审计的实体之间传输信息的方法。通常，这是通过在非预期信道上传输数据来实现的，例如通过引起服务器上共享硬件介质上的争用来传输信令比特[16，18，25-27 ]。过去的工作已经证明了虚拟化环境中的隐蔽通道，如云使用各种硬件，如缓存[19，27]，内存总线[26]，甚至处理器温度[16]。特别感兴趣的这项工作是隐通道基于内存总线硬件介绍吴等。[26]第10段。 在x86系统中，只要操作数保持在高速缓存行内（通常是语言编译器确保操作数对齐的情况），高速缓存一致性协议就支持被设计为促进多处理器同步的原子存储器指令。然而，如果操作数分布在两个高速缓存行上（称为“外来”内存操作），x86硬件通过锁定内存总线来防止任何其他内存访问操作，直到当前操作完成为止，从而实现原子性。与传统的存储器访问相比，这导致因此，几个连续的锁定操作可能会导致内存总线上的争用，这可能会被利用来进行隐蔽通信。Wu等人在理想的实验室设置中，在存储器总线通道上实现了每秒700比特（bps）的数据速率。然而，在云环境中实现这样的理想性能通常是不可能的 云平台采用虚拟化来实现统计多路复用，因此，隐蔽信道上的通信可能受到以下因素的影响：1）调度器中断，因为发送方或接收方可能仅获得对通信的间歇性访问。···使用LambdasWWW1007信道和2）来自其他非参与工作负载的干扰 这可能会导致传输数据中的错误，并需要额外的机制，如纠错[26]，以确保可靠的通信。2.3共居检测在云环境中，通过传统的隐蔽通道进行通信带来了将发送者和接收者放置在同一台机器上的额外挑战然而，这种共同驻留信息是隐藏的，即使实体属于同一租户。 过去的研究已经使用了各种策略来实现共同驻留，以展示云中的各种隐蔽通道攻击。通常，攻击者会启动大量云实例（VM、Lambda等）， 遵循特定的启动模式，并采用共存检测机制来检测那些实例中的任何一对是否在同一机器上运行。传统上，这种检测是基于在同一服务器上运行的两个实例可能共享的软件运行时信息，如公共/内部IP地址[19]，procfs中的文件或其他环境变量[24，26]，以及其他此类逻辑侧通道[21，29]。随着虚拟化平台向实例之间更强的隔离（例如， AWS的FirecrackerVM[1]），这些逻辑隐蔽通道已经变得不那么有效或不可行。 此外，这些通道中的一些通道仅在共享底层OS映像的基于容器的平台上有效，因此不太适合基于管理程序的平台。这促使人们转向使用基于硬件的隐蔽通道，例如第2.2节中讨论的那些，它们可以绕过软件隔离，因此通常更难修复。例如，Varadarajan etal. [22]使用内存总线隐蔽通道来检测EC2实例的共存然而，他们的方法并不能很好地扩展到Paddas，因为它既不快速也不可扩展。3动机在本节中，我们将讨论我们的隐蔽通道攻击场景，在启用这种攻击时，Biddas将带来的挑战，以及Biddas对共存检测器的需求威胁模型隐蔽通道攻击通常需要一个“内部人员”通过隐蔽介质发送数据进行渗透。 我们假设攻击者使用社会工程技术或其他一些手段（超出本工作的范围），在受害者系统中引入这样的内部人员。在lambda的情况下，这个内部代码可能在lambda本身中，或者在控制组织的lambda部署的系统中，并且已经拥有需要被泄露的敏感数据。我们进一步假设攻击者知道受害者正在操作的云区域，并且可以在自己的帐户下部署恶意软件在典型的攻击中，攻击者在云区域中启动一组接收器，其中受害者接收器（receiver）被期望操作。然后，攻击者和（受损的）受害者可以一起工作2，通过隐蔽通道交换数据，如前面讨论的内存总线硬件。然而，在这方面，2我们不明确区分攻击者和受害者，因为它们都被认为是在攻击者的控制之下。如前所述，在我们可以在云中使用传统的隐蔽通道之前，存在一些独特的挑战。我们需要：1）将发送者和接收者共同定位在同一服务器上（通过共同居住检测），2）处理此类信道上的中断，例如嘈杂的邻居邻居或调度。虽然这些挑战已经被其他云平台（如VM）处理过[21，26]，但云服务器本质上是不同的，因为它们的生命周期非常短。两个共同居住的居民之间的秘密渠道不会持续很长时间。然而，虽然Biddas不是持久的，但一次性大量启动Biddas并建立多个共同居住点以允许更隐蔽的通信是微不足道和廉价的。此外，集群也比虚拟机更密集，加剧了嘈杂的邻居问题。短暂的，众多的，和密集的性质，需要一个快速，可扩展的，和可靠的共存检测器。这个检测器还应该允许攻击者识别所有具有两个或更多个共同驻留的代理的服务器，并在每个这样的服务器上建立一个隐蔽通道此外，检测器应该精确地识别出有多少个和哪些是共同驻留的，允许攻击者在给定的机器上选择任何两个共同驻留的，并在这两个共同驻留的之间建立一个隐蔽的通道，而不受其他机器的干扰。4在本节中，我们将描述基于lambda的共存探测器的必要要求，以及这些要求如何推动我们的设计选择，我们用来克服在这种情况下的独特挑战的详细实施，以及对其有效性的评估。4.1规范给定部署到公共云的一组云实例（VM、容器、函数等），共存检测机制应该为该组中的每对实例识别该对实例是否在某个点运行在同一物理服务器上。Varadarajan et al. [22]，任何这种机制要在广泛的发射战略中发挥作用，就应具有下列特性：通用技术应该适用于广泛的服务器架构和软件运行时。在实践中，该技术将在大多数第三方云平台上工作，甚至在云中的不同平台之间工作。可靠该技术应该具有合理的检测成功率，具有最小的假阴性（未检测到共同驻留的实例）和甚至更少的假阳性（被归类为共同驻留的非共同驻留的实例可扩展启动策略可能需要部署数百甚至数千个实例，并且必须扩展，使得该技术将以合理的成本检测所有共存对我们在这个列表中添加了另一个属性，它与Biddas相关快速技术应该是快速的，最好在几秒钟内完成。 由于云计算是短暂的（有些云将其执行时间限制为一分钟），····WWWAnil Yelam、Shibani Subbareddy、Keerthana Ganesan、Stefan Savage和ArianaMirian1008←←←←←←←←（）下一页（）联系我们←∗←←←←←（）（）联系我们该技术应留出充足的时间用于利用所产生的共同驻留信息的4.2设计4.2.1一般性。 如第2.3节所述，以前使用独特的软件标识符来完成共同居住检测，该软件标识符向租户显示底层服务器。这种软件标识符提供了最快的，也许是最可靠的方式（在地面真相方面），用于共同居住检测。在我们的场景中，每个lambda都可以快速“读取”标识符，并将此信息与所有其他lambda通信（通过网络或共享远程存储），以识别共同驻留的lamb-das。然而，这样的信息可以很容易地被平台提供商混淆;例如，目前没有这样的标识符可用于AWS服务器。因此，我们转向基于硬件的隐蔽通道，根据定义，单个服务器上的所有租户都可以访问这些通道基于硬件的隐蔽通道通常也更难以移除，并且更普遍，因为硬件在计算平台上比软件更同质。4.2.2挑战隐蔽渠道。 由于隐蔽通道可以发送信息，因此可以潜在地使用它们来在共同居住的多个代理之间传送身份信息（诸如唯一ID）以检测共同居住。然而，隐蔽信道一般假设发送者和接收者是已知的，并且只有两方进行通信。当多方共享信道时，我们需要对信道进行更严格的控制，以仲裁对信道的访问并处理冲突。然而，隐蔽信道通常是二进制信道（即，各方一次只能发送或接收一个比特，而不能同时发送和接收两个比特），而不具备冲突检测能力隐蔽信道通常还具有非常有限的带宽（通常每秒只有几十比特），信道仲裁可能足够复杂并且存在被认为是不可行的显著开销。4.2.3有效的ID广播。对于共同居住检测，lamb- das只需要彼此通信它们的ID。因此，我们不要求通道是通用的或表达性的，只要求它可以尽可能有效地传递这些ID 为了保持对隐蔽通道的限制，我们假设可以访问通道的任何lambda可以选择发送或侦听1位，并且如果至少有一个lambda选择发送一位，则所有侦听器都将记录1位。此外，我们假设，在发送或listening在每个时隙的位之间，TDMA可以同步自己。我们在4.3节中证明了这两个假设是合理的。因此，我们提出了一种通信协议，有效地广播这些ID（即，固定长度的位串，例如N）。我们将协议的总运行时间划分为多个阶段，每个阶段执行N个比特时隙的间隔。 每个阶段都有一组参与的Padda，在第一阶段中是所有的Padda。在一个阶段中的N个时隙的每个比特时隙K中，如果其比特串（ID）的第K个比特是1，则每个参与的lambda广播比特，否则它监听。如果侦听lambda在侦听时检测到1位，则它停止参与，并侦听阶段的其余部分。因此，只有具有最高ID的算法1ID广播协议1：sync_point所有实例的启动时间2：ID实例ID3：ID中的位数N第4章：你是谁？5：实例6：W AIT_TILL sync_point7：whileid_readdo8：插槽09：id_read010：participatin参与11：而插槽N<12：ID的第th个最高有效位的位槽13：如果participatin和位，那么14：W RITE_BIT（Alg. （二）15：bit_read116：其他17：bit_readREAD_BIT（Alg. 第三章18：如果bit_read，则第19章：你是谁？20：如果结束21：如果结束22：id_read2id_read+bit_read23：插槽插槽+1第24章：结束25：如果id_read=ID，则第26章： 你是谁？27：如果结束28：instances实例id_read第29章：结束30：返回实例初始的一组参与的AAA继续广播，直到协议结束，有效地将其完整ID通告给其余的（现在正在侦听的）AAA。在下一个阶段中，具有先前最高ID的lambda现在仅侦听，允许下一个最高lambda通告其ID，依此类推。 如果ID是唯一的，那么在每个阶段中总是只有一个lambda广播。协议在x个阶段（其中x是共同驻留的多址广播的数量）之后结束，此时没有多址广播持续N个连续的比特时隙。算法1中提供了协议的伪代码。时间复杂度假设总共有N个部署到云的lambda，位串需要log2N位才能唯一地标识每个lambda。如果在任何单个服务器上启动了最多K个这些缓存，则协议执行K个阶段，每个阶段为log 2N位槽，整个操作采用K +1 log 2N位槽。事实上，没有必要对所有K个阶段运行该协议在第一阶段之后，所有共同驻留的lambda都将知道他们的一个邻居（因为每个阶段都会向其他人揭示最大参与lambda如果我们使用全局唯一的ID，那么所有共同驻留的Apache将看到相同的ID。然后，代理可以离线交换这些ID（例如， 通过网络）来推断其邻居的其余部分。这种简化消除了对共同驻留的数据集的数量（K）的依赖性，并降低了复杂度使用LambdasWWW1009（）下一页←−_←←（）103103103102010102505 10151020 10偏移量（mm）偏移量（mm）偏移量（mm）图一：这些图显示了当我们分别在AWS、Azure和Google（GCP）上从一个缓存行跨边界滑入另一个缓存行时，在8B内存区域上执行的原子内存操作的延迟。当8B区域落在两个高速缓存行（偏移0- 7 B）上时，延迟是更高的数量级，这表明所有这些云提供商上都存在至Olog2N，提供了亚线性共驻留检测机制。4.3执行使用刚才讨论的设计考虑，我们实现了上述协议使用基于内存总线硬件的隐蔽通道。 我们讨论了如何使用硬件来发送和侦听比特，以满足协议的要求。4.3.1内存总线隐蔽通道。 我们利用第2.2节中描述的内存总线隐蔽通道，因为它利用了所有代x86硬件中存在的基本硬件漏洞。从历史上看，多个公共云服务都容易受到此通道的攻击[21，32]，我们发现它们今天仍然很脆弱。为了证明漏洞的存在，我们测量了8B内存区域上的原子操作的延迟，因为我们将该区域从一个高速缓存行滑动到另一个高速缓存行边界。 我们在三个主要的云平台（AWS，Google和Microsoft Azure）上执行此实验，并在图1中显示了观察到的延迟。 从图中可以看出，所有三个云平台对于内存区域跨越高速缓存行边界的“外来”内存锁定操作仍然表现出显著的延迟差异。当与常规内存访问相比时，它证明了所有这些内存访问上都存在这种隐蔽通道此外，我们能够在无服务器函数实例上执行这些实验 由于Apache的运行时通常仅限于高级语言（这会阻止执行这些外来操作所需的指针算法），因此我们在这些云上使用了不安全的环境-AWS上的C++，GCP上的Unsafe Go，Azure上的Unsafe C#。这表明了在不同类型的云实例中使用隐蔽通道的适用性，实现了我们机制的通用方面4.3.2发送一点。发送方和接收方可以准确地commun- nicate 0位和1位造成内存总线上的竞争。为了传达1位，发送器实例通过使用特殊的内存锁定操作（在第2.2节中讨论）锁定内存总线，从而引起内存总线上的争用。发送方实例的伪代码如算法2所示。4.3.3听了一会儿。接收方可以简单地对争用的冗余总线进行采样，从而推断通信是否是算法2从发送方←时间Now（）end now+samplin <$duration地址cache_line_boundary2whilenowenddo

下载后可阅读完整内容，剩余1页未读，立即下载