本文来自TEEX投稿，Odaily星球日报授权转载。
L1TF漏洞是Intel平台近日爆出的严重安全漏洞，该漏洞影响极大、涉及范围广、利用难度低，尤其是对IntelSGX安全扩展带来了冲击，使许多依赖该安全特性的系统面临极大的挑战。TEEX团队首先分析了该漏洞的技术原理以及Intel的官方应对方案，并在此基础上提出了“虚拟化+SGX”安全增强设计，可有效抵御L1TF漏洞，同时对SGX该如何应用于区块链系统做了初步的讨论。1.什么是IntelL1TF漏洞？
L1TF漏洞允许一个低权限的攻击者窃取被加载至一级缓存中且属于特权级软件的隐私数据。该漏洞有三个变种：L1TerminalFault-SGX：一个用户态攻击者能够窃取位于一级缓存中的属于Enclave的数据；L1TerminalFault-OS/SMM：一个低权限的攻击者能够窃取位于一级缓存中的属于更高权限的数据；L1TerminalFault-VMM：一个恶意的客户虚拟机能够窃取位于一级缓存中的属于虚拟机监控器或者其他客户虚拟机的数据。L1TF几乎影响了所有拥有预测执行技术与页表翻译功能的Intel处理器，官方公开的受影响处理器列表几乎包含了Intel近几年发布的所有CPU型号。1.1背景介绍：页表、缓存、预测执行与隐蔽信道页表：页表是CPU管理内存的核心机制。当页表机制启用时，CPU指令采用虚拟地址访问内存。随后，CPU利用页表将该虚拟地址翻译为物理地址，从而从物理内存中读取/写入数据。页表中，每个虚拟地址页都拥有一个自己的页表项。一个页表项中包含了该虚拟地址页对应的物理地址页，以及相应的权限位与控制位。其中有两个特殊位P位以及预留位与本次攻击相关。P位表示当前页表项是否有效，同样的对于预留位的检查失败也表示当前页表项无效；缓存：缓存是CPU内部的一块高速储存区域。CPU将物理内存中的数据加载到内部的缓存中，之后对于该物理内存的访问将直接在缓存中进行，从而提升CPU访问内存的速度。当前处理器的缓存往往分为多个级别，一级缓存、二级缓存以及三级缓存。在多核处理器中，每个CPU核都拥有自己的一级与二级缓存。而三级缓存往往是所有CPU核共享的；预测执行：预测执行是当前CPU加速指令处理的一项主要技术。当CPU执行某些引起控制流跳转时，并无法立刻获得下一条指令时，CPU将会预测性地继续执行指令。如果预测正确，那么就能有效提升指令处理速度。而如果预测出错，那么CPU将会回滚所有由于预测执行而产生的结果；隐蔽信道：隐蔽信道是一种间接的数据传输方式。两个被隔离的程序能够通过控制某些系统状态的变化，间接的传递数据，从而绕开诸多隔离机制。假如A希望向B传递一个隐私数据，那么A首先根据该数据的内容，相应的更改系统状态。而B之后能够通过观察系统状态变化，从而间接获得A传递过来的隐私数据。这种间接的数据传递方式被称为隐蔽信道。1.2L1TF漏洞的详细原理当CPU访问某个虚拟地址时，会通过页表将虚拟地址翻译到物理地址。此时，如果页表中的P位被置0，或者预留位被置上，那么意味着该页表项无效，即所对应的虚拟地址没有被映射到物理地址。此时，CPU中负责地址翻译的模块将立即停止地址翻译过程，并抛出一个PageFault。这一特殊的PageFault也被称为TerminalFault。然而，当TerminalFault发生之后，拥有预测执行特性的CPU并不会立即跳转至错误处理函数，而是会预测执行触发错误的指令。此时，CPU会根据页表项中的内容，预测性的将目标虚拟地址翻译为物理地址，并且继续访问内存。具体来说，CPU会从发生Fault的页表项中读取物理页的起始地址，从访问的虚拟地址中获得页内的地址偏移，最终组成一个物理地址。如果该物理地址中的数据已经被加载到当前CPU核的一级缓存中，那么该数据将被读取，并且传递给之后的预测执行指令。虽然最终这些预测执行的指令运行结果都将被CPU回滚，但是CPU无法恢复这些指令对缓存状态产生的影响。因此，这些预测执行的指令能够利用缓存状态建立一条隐蔽信道并将读取的目标数据传递给攻击者。由于TerminalFault发生之后，CPU访问的物理地址是预测生成的，而不是通过页表翻译得出的，因此该次物理地址访问将能够绕过诸多内存访问检查，具体来说有三种：绕开IntelSGX的Enclave内存保护检查。Enclave是IntelSGX提供的可信执行环境，Enclave的数据在内存中会被加密，只有被加载至缓存中时才会解密。当完成虚拟地址到物理地址的翻译之后，CPU会检查目标地址是否属于某一Enclave并且当前是否在该Enclave中运行；绕开SMM的内存保护检查。SMM模式是Intel的一个具有高权限的运行模式。页表翻译完成之后，CPU会检查目标物理地址是否是属于SMM模式的内存，并且检查当前运行模式是否能够对其进行访问；绕开Intel虚拟化技术系统的扩展页表。在虚拟化环境中，完成页表翻译之后，得到的物理地址将被扩展页表进行第二次翻译，从而得到最终用来进行内存访问的物理地址。扩展页表被广泛用于保证不同虚拟机之间的内存隔离。由于L1TF漏洞能够绕开以上三类不同的检查，因此该漏洞也被分为三个不同的变种，L1TF-SGX、L1TF-OS/SMM以及L1TF-VMM。1.3L1TF漏洞有哪些依赖条件？L1TF漏洞要求攻击代码所处的CPU核的以及缓存中必须存有目标数据。目标数据可以是任何当前权限级别或者用户无法访问的数据。同时L1TF要求攻击者能够在目标机器运行攻击代码。具体来说，L1TF依赖于以下三个攻击条件，只有这些条件均被满足时，攻击才能进行：1.目标数据必须被加载至攻击者所在CPU核的一级缓存中；而一级缓存的大小非常有限，并且内容更替频繁，因此攻击窗口非常小；2.攻击代码必须运行在一级缓存中存有目标数据的CPU核中；同时，攻击代码所用的页表中必须存在能够利用的页表项，从而构造出目标数据的物理地址；3.攻击代码只能通过预测执行进行目标数据的读取，并且必须通过隐秘信道才能最终获得目标数据。条件1意味着攻击者必须实现通过某些技术保证目标数据已经被加载到一级存中。条件2、3要求攻击代码必须运行在目标数据所缓存的CPU核中。在拥有Hyperthead技术的IntelCPU中，一个CPU核会拥有两个能够同时执行并且共享一级缓存的物理线程，因此攻击代码仅需运行在目标CPU核中的任一物理线程之中。2.L1TF对IntelSGX有什么影响？
欧盟委员会启动新的欧洲数字基础设施联盟 (EDIC):金色财经报道，欧盟委员会启动一个新的欧洲数字基础设施联盟 (EDIC)，致力于加大力度与其他大型区块链基础设施竞争，欧盟的区块链致力于整合大量公共应用程序，例如持有公民的数字身份和钱包、追踪和验证商品、存储许可证以更轻松地在国家之间转移等等。在幕后，已经与其他司法管辖区就如何为某些用例整合区块链进行谈判。[2023/6/15 21:39:27]
IntelSGX是IntelCPU提供的硬件安全特性。SGX提供了一种可信执行环境Enclave，允许用户将关键代码与数据运行在Enclave中并且保证安全性，同时提供了一些列指令用以创建、管理、销毁Enclave。Enclave中的代码和数据均存储在专用的物理内存区域EPC中，EPC中的数据会以密文形式保存在物理内存之中，只有当其被加载至CPU内部之后，EPC中的数据才会被解密保存在缓存中。因此，Enclave除了能够防止来自高权限级别的软件攻击之外，还能够抵御冷启动攻击、总线侦测攻击等物理攻击手段。2.1如何利用L1TF读取Enclave中的加密内存？虽然Enclave中的数据在内存中是加密的，但是其在CPU缓存中是以明文存储的。L1TF漏洞能够绕开CPU对Enclave内存访问的检查，使得攻击者能够窃取被加载至一级缓存中的Enclave数据。在今年的USENIXSecurity2018大会上，L1TF的发现者们发表了论文“FORESHADOW:ExtractingtheKeystotheIntelSGXKingdomwithTransientOut-of-OrderExecution“，阐述了如何利用L1TF-SGX漏洞窃取Enclave中的隐私数据。在论文中提到，L1TF漏洞在攻击Enclave时能够被更加容易的实现。IntelSGX提供了一条特殊指令*eldu*，用以帮助不可信的操作系统安全的加载Encalve的内存。攻击者发现，eldu指令在加载Enclave内存时，会同时将其加载至当前CPU的以及缓存之中。也就是说，攻击者无需猜测目标数据何时会被加载至一级缓存中。其能够直接通过eldu指令，将任意Enclave内存加载至当前CPU核的一级缓存，并且利用L1TF-SGX漏洞对其进行读取。2.2Intel提供的L1TF漏洞补丁与防御机制针对L1TF漏洞，Intel官方提供了微代码补丁。对于保护SGX而言，补丁主要做了两处安全性增强：在进出Enclave时，清除当前CPU核的一级缓存。保证在退出Enclave之后，Enclave内部的数据不会残留在一级缓存之中，从而无法被窃取；在Enclave的远程验证信息中加入当前是否启用Hyperthread的报告，同时建议用户拒绝相信运行在开启Hyperthread平台中的Enclave。对于上文提到的eldu指令，Intel的官方文档里并没有提到是否对该指令打上补丁，以防止其被用来进行L1TF攻击。如果该指令的行为未被修改，那么攻击者仍然能够利用L1TF漏洞读取Enclave内部的数据。本方法要求用户拒绝将Enclave运行在开启了Hyperthread的平台之上。然而，Hyperthread的控制主要由BIOS完成，无法在运行时动态开启/关闭。这也就意味着，用户为了使用SGX必须完全放弃Hyperthread技术。与此同时，某些硬件厂商的BIOS并不支持关闭Hyperthread的操作，导致用户无法安全地在这些平台上使用SGX技术。3.TEEX团队的“虚拟化+SGX”安全增强方案
Azuki：官方Instagram账户被盗，目前正与Meta取得联系以夺回控制权:4月12日消息，NFT 项目 Azuki 在社交媒体上发文表示，Azuki 官方 Instagram 账户被盗，目前正与 Meta 取得联系以重新获得对该帐户的控制权。[2023/4/12 14:00:02]
考虑eldu指令是否被修补的未知隐患，以及部分机器可能未打上Intel的微代码补丁，同时为了管控SGX在将来可能存在的侧信道攻击等安全隐患，TEEXteam提出了一个基于虚拟化技术的SGX安全增强方案：TXVisor。该方案利用虚拟化技术，将不同的Enclave环境，以及Enclave与非Enclave环境相隔离，以保证用户数据与代码逻辑不受类似L1TF等攻击的影响。该方案包括以下技术点：L1Cache隔离：在每次退出Enclave时，TXVisor都将清除当前CPU核的一级缓存，从而避免攻击者利用一级缓存，在Enclave内外构建隐蔽通道，从根本上杜绝了L1TF攻击，即使在没有应用Intel补丁的硬件平台也同样适用；ELDU指令安全增强：对于Intel官方补丁中未提到的eldu指令，TXVisor将通过“Trap-and-emulate”的方法，动态捕获该指令的执行，在保证其原有功能的同时增加额外的安全检查，从而防止其破坏一级缓存的隔离；Hyperthread模式下安全性增强：TXVisor通过控制调度，防止攻击者利用Hyperthread技术在运行时利用L1TF漏洞攻击目标Enclave。通过将Enclave环境与非Enclave环境的隔离，本方案既能够保证Enclave安全，又允许用户在Enclave外使用Hyperthread技术提升系统性能，从而进一步降低安全防护所带来的性能损失；可信运行环境验证：TXVisor提出了软硬件结合的双重远程认证方法，使得用户能够安全的验证应用程序是否运行在受SGX与TXVisor保护的平台之上。该方案可在没有应用Intel硬件补丁的平台上完全防御类似L1TF等类型的攻击；同时，我们还提出了若干系统优化的方法，以降低安全增强所带来的性能损失。该工作也是继CHAOS、CloudVisor、HyperCoffer、TxIntro、CrossOver、SeCage、AdAttester、Nexen、SGXMigration、vTZ、VButton、Fidelius、EPTI之后，在虚拟化与可信隔离环境方面的系列工作之一。4.SGX与区块链
如何保证数据的隐私性一直是区块链领域的难题之一。目前，诸多领域内的技术团队正在探索如何利用IntelSGX等硬件安全技术，为区块链提供隐私性保证。虽然当前还未有利用IntelSGX解决区块链隐私问题的成熟方法，但研究人员在探索的过程中已经证明，SGX技术能够有效提升区块链中数据与运算的隐私性。然而，SGX技术并不是“不坏金身“。无论是此次的L1TF-SGX漏洞，还是之前的测信道攻击，都揭示了SGX存在着安全隐患。因此，对于区块链系统来说，一个合理的SGX使用方案，应当既能够利用SGX技术提升区块链的安全性能，也能够在SGX存在漏洞的情况下，限制漏洞所造成的影响。现有的部分方案存在过分依赖SGX的问题，例如将区块链的一致性协议完全依赖SGX的隐私性进行设计。一旦SGX的安全性存在漏洞，安全隐患将瞬间蔓延至整个区块链，导致整个链的崩溃。TEEX团队在利用SGX保证用户数据、计算逻辑安全性的同时，通过结合虚拟化等技术与区块链本身的特性，能够有效控制SGX出现漏洞后的影响范围。在利用SGX提升区块链隐私性的同时，也不过分依赖于其作为整个系统的安全根。综上，我们认为TEE将会与密码学一样，成为区块链的重要支撑技术之一。TEEX团队希望通过在TEE安全技术上的多年积累，为现有和将来的区块链系统提供安全可靠的基础架构服务，进而促进整体生态的繁荣。后续，TEEX会带来更多TEE与区块链结合的讨论，敬请期待。关于TEEX团队TEEX团队希望将TEE与区块链技术相结合，建立一个去中心化的可信执行平台。团队主要研究的领域包含IntelSGX、ARMTrustZone、AMDSME/SVE、TPM/TXT、形式化验证、以及虚拟化在内的各类TEE解决方案与安全增强方案，同时在如何将TEE应用于区块链领域也有相应的技术积累。更多信息详见：https://teex.io。参考文献1.VanBulckJ,PiessensF,StrackxR.Foreshadow:ExtractingtheKeystotheIntel{SGX}KingdomwithTransientOut-of-OrderExecution,USENIXSecurity'2018.2.(https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-l1-terminal-fault)3.Daonity-GridSecurityfromTwoLevelsofVirtualization.HaiboChen,JieyunChen,WenboMao,andFeiYan.ElsevierInformationSecurityTechnicalReport.(InvitedPaper),Volumn12,Issue3,pp.123–138.June2007.4.FengzheZhang,JinChen,HaiboChenandBinyuZang.CloudVisor:RetrofittingProtectionofVirtualMachinesinMulti-tenantCloudwithNestedVirtualization.In23rdACMSymposiumonOperatingSystemsPrinciples,SOSP,2011.5.YubinXia,YutaoLiuandHaiboChen.ArchitectureSupportforGuest-TransparentVMProtectionfromUntrustedHypervisorandPhysicalAttacks.InProceedingsof2013InternalSymposiumonHighPerformanceComputerArchitecture,February,2013.6.YutaoLiu,YubinXia,HaibingGuan,BinyuZang,HaiboChen.ConcurrentandConsistentVirtualMachineIntrospectionwithHardwareTransactionalMemory.InProceedingsofthe20thIEEEInternationalSymposiumOnHighPerformanceComputerArchitecture(BestPaperNominee),Orlando,Florida,2014.7.WenhaoLi,YubinXia,HaiboChen,BinyuZang,HaibingGuan.ReducingWorldSwitchesinVirtualizedEnvironmentwithFlexibleCross-worldCalls.Inthe42ndInternationalSymposiumonComputerArchitecture,Portland,Oregon,USA.June2015.8.YutaoLiu,TianyuZhou,KexinChen,HaiboChen,YubinXia.ThwartingMemoryDisclosurewithEfficientHypervisor-enforcedIntra-domainIsolation.Proceedingsofthe22thACMConferenceonComputerandCommunicationsSecurity,Denver,Colorado,US,October,2015.9.WenhaoLi,HaiboLi,HaiboChen,YubinXia.AdAttester:SecureOnlineAdvertisementAttestationonMobileDevicesUsingTrustZone.InProceedingsofthe13thInternationalConferenceonMobileSystems,Applications,andServices,Florence,Italy.May2015.10.LeiShi,YumingWu,YubinXia,NathanDautenhahn,HaiboChen,BinyuZang,HaibingGuan,JingmingLi.DeconstructingXen.TheNetworkandDistributedSystemSecuritySymposium2017.SanDiego,California.March,2017.11.JinyuGu,ZhichaoHua,YubinXia,HaiboChen,BinyuZang,HaibingGuan,JinmingLi.SecureLiveMigrationofSGXEnclavesonUntrustedCloud.The47thIEEE/IFIPInternationalConferenceonDependableSystemsandNetworks,June26-29,2017.Denver,CO,USA.12.ZhichaoHua,JinyuGu,YubinXia,HaiboChen,BinyuZangandHaibingGuan.vTZ:VirtualizingARMTrustZone.USENIXSecuritySymposium2017.Voncouer,Canada,August,2017.13.WenhaoLi,ShiyuLuo,ZhichuangSun,YubinXia,LongLu,HaiboChen,BinyuZang,HaibingGuan.VButton:PracticalAttestationofUser-drivenOperationsinMobileApps.InProceedingsofthe16thACMInternationalConferenceonMobileSystems,Applications,andServices,2018.14.YumingWu,YutaoLiu,RuifengLiu,HaiboChen,BinyuZangandHaibingGuan.ComprehensiveVMProtectionagainstUntrustedHypervisorthroughRetrofittedAMDMemoryEncryption.The24thIEEEInternationalSymposiumonHigh-PerformanceComputerArchitecture,Vienna,Austria.Feb2018.15.ZhichaoHua,DongDu,YubinXia,HaiboChen,BinyuZang.EPTI:EfficientDefenceagainstMeltdownAttackforUnpatchedVMs.USENIXATC,2018.
币安转向“半自动”流程来管理其发行的代币储备:金色财经报道，Binance正在转向\"半自动化\"流程来管理其发行的代币储备，多年来，储备与客户资金混合，至少有一种主要的稳定币，即币安挂钩BUSD，并不总是完全支持。
Binance一位发言人表示，现在已经创建了一个部分自动化的流程，确保B-tokens “始终透明地得到系统的支持”，该系统只允许在相应的钱包中添加抵押品后才可以制造新的代币。币安已决定将其新流程部分自动化，而不是完全自动化，以限制安全风险。[2023/2/23 12:24:05]
DeversiFi与StarkWare合作首次使用新型L2交易“条件转移”，使L1和L2之间的互操作成为可能:3月9日消息，基于扩容方案StarkEx的去中心化交易所DeversiFi宣布，已与StarkWare合作，首次使用一种称为“（conditional transfer）条件转移”的新型L2交易，使得以太坊L1和L2之间的互操作成为可能。（CryptoNinjas）[2021/3/9 18:27:47]
以太坊基金会社区经理：Polkadot和Cosmos等L1链上治理仍不奏效:11月20日，以太坊基金会社区经理Hudson Jameson刚刚发推称，Layer 1链上治理仍然是一个坏主意，Polkadot和Cosmos尝试的链上治理并不奏效。[2020/11/20 21:28:55]
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。