@dyk
2016-02-24T06:48:51.000000Z
字数 10562
阅读 375
RollBack Workspace
对于场景的选择，需要将回滚者设定为攻击者而不是受害者。这样的场景才是有说服力的场景。
需要突出分类方法，分类思想。
传统的回滚问题主要是单机的问题，主要是如何保持单机的rollback-resist。云环境中的问题不仅包括传统的问题还包括云环境的特性引发的问题（交互问题，特有安全机制与回滚特性之间的冲突）。本文主要是为了分析回滚对于现存云安全属性以及安全策略的不良影响，并且提供相应的对策。（云环境中的机器之间的交互繁多，各自的角色也十分的复杂。回滚对云环境带来的冲击也较传统的冲击也更为复杂。）
安全记录回滚事件（陈海波，额外的状态记录机制，Memoir？），部分回滚（rvTPM细粒度回滚策略），回滚重放（重放过去的命令，重放之后的结果将被忽视），回滚重做（重做的结果将会被使用），不允许回滚。
云环境中的回滚问题可以分为三类（1）操作相关（2）数据相关（3）欺骗类。这三类问题在两种不同的场景（交互情况，单机情况）中又有不同的体现。其中（3）主要是恶意的攻击者利用回滚进行攻击。只有少数的研究针对回滚问题提出解决方案。
陈海波提出限制回滚的范围（只允许回滚到Running Epoch的开头或者结尾，每个Running Epoch 开始于 VM boot/resume 结束于VM shutdown/suspend），并且保持一个安全可信的回滚日志，记录所有的回滚（resume命令）以及回滚的理由提供给用户进行审查。不足的地方：限制了回滚（回滚应该能够回滚到任意的检查点），并且日志中的内容过少（只有快照的编号，以及4个相关的hypercall，没有快照的其他情况）使用 了TPM但是却没有考虑TPM的回滚带来的不一致情况。
Memoir提出了一套保护的机制，将目标模块使用Memoir lib封装起来使其获得rollback-resist，免疫replay攻击。主要是将应用的状态保存在了回滚免疫的NVRAM中，每次外界的请求将附带传入应用状态，目标应用将这个状态与NVRAM中的值进行比较判断如果一致那么认为不是可疑的重放信息（即untrusted模块前面一次和这一次发送的信息是不一致的，即不诚实的重放），如果不一致则判断发生了可疑重放信息即可理解为（自身）发生了回滚。
When Good Randomness Goes Bad: Virtual Machine Reset Vulnerabilities and Hedging Deployed Cryptography，提出了VM snapshot将会导致randomness的reuse问题。文章从密码学的方面提出一种密钥生成方法能够减轻randomness的reuse问题引发的问题。这篇文章解决问题的角度并不在回滚的带来的问题方面，而是从密码学的方法上面进行考虑。
在云环境多方交互过程中回滚的带来的错误的情况下，回滚导致了安全问题。例如：非法的使一方权限提升，或者由于资源死锁交互无法正常进行。在云环境中的，这些交互实体并不是都能通过回滚消除不一致状态。在这里讨论的多方可能是不同角色的服务甚至可能是用户的设备，回滚相关的所有设备是不切实际的。
场景：用户A利用Facebook（IdP）上面的帐号来登录另外一个网站W（RP，潜在恶意的，或者说是好奇的）（Single Sign-On模式）。通过OAuth2.0协议，用户A能够在网站W上面使用Facebook的帐号登录。此时网站W能够通过该授权访问用户A的相应资源（照片，文件，通讯录，个人资料）。之后用户A在IdP的授权服务器上面注销了网站W的注册授权（或者缩小了网站W的授权数据的范围，这个更加的有可能发生）并且添加了新的照片，文件。IdP的授权服务器发生回滚（网站W是否能通过探测这个回滚,具体的探测方法），用户A的注销请求被回滚给覆盖。已经注销授权的网站W在此时能够再次访问用户A的未授权的新数据（授权码到期之前）。
后果：在云用户不知情的情况下，恶意的网站W能够访问授权范围之外的数据。
假设：假设云用户，云提供商都不是恶意的，SaaS服务提供商是好奇的甚至是恶意的，三者对于自身的虚拟机拥有回滚权限（云用户回滚自身虚拟机，SaaS提供商能回滚自身云服务虚拟机，可能也可以攻击目标虚拟机导致目标虚拟机回滚，云提供商能回滚云用户的虚拟机），SaaS（RP，relying party）可以通过探测IdP（Identity Provider）授权服务器的回滚（或者入侵IdP触发回滚，这个难度可能比较高），在IdP服务器的回滚错误（操作丢失）之中提升自己的权限。
解决：由于用户的授权修改动作属于云环境中的sporadic操作，最可能由于rollback而丢失为了防止回滚之后的用户sporadic操作丢失，需要采取可信的日志记录方式安全记录sporadic操作。在发生回滚之后，将回滚影响的操作进行重做。对外面输出的操作的重做的再次的影响将会被忽略。
对应解决手段：磁盘事件记录，运行状态记录，日志处理与过滤，发生回滚的时候进行状态恢复。
通用解决方案：在服务运行过程中进行操作日志的记录，用户的sporadic操作的丢失需要采取redo策略。
基于一致性检查点与非一致性检查的恢复策略不合适：
基于一致性检查点与非一致性检查点的恢复策略是传统的分布式信息系统中的恢复方法，他需要将相关各方中的受影响的单位通通回滚到状态一致的状态。保证不会产生数据不一致的问题。
重放非必要：
在这个长期中，丢弃的是一个完整的sporadic操作（开始和结束都全部被跳过了）。并没有必要严格按照上一次的运行过程完全的将命令再一次的重现。并且允许重放也将会引发如下所示的问题。
建议采用重做策略，重做策略与重放不同，重放将会让交互完全按照之前样子再次运行一遍。对于这个操作来说操作以及结束了不需要精确的进行重放。只需要防止回滚将其影响消除即可。即只需要完成同样的事件达到相应的状态。因为这个场景只是涉及操作并不涉及任何的数据（无法重做的数据）。
基于非一致或者一致检查点的策略完成回滚恢复后用户的请求仍然处于丢失的状态，没有办法采取传统的手段完成。传统的基于日志的回滚，日志记录的粒度不同无法完成这个场景的日志需求（或者需要再理解源代码的情况下才能进行重放）。由于允许过去的消息再次的重放可能会导致回滚信息。(例如，支付请求，可能完成重复支付)。于是最终选择的方法是进行redo，将丢失的请求（这样的请求的影响被回滚消除了）进行redo。redo这一次操作的过程可能不是完全于上一次一致的，但是操作的之后的状态会达到与之前一致的状态。
这个问题主要是交互多方回滚之后的操作丢失的情况，云环境中存在着大多是多方交互的情况，不能采取一致和非一致检查点的恢复操作。因为云环境中的多方并不一定都属于同一个用户即不可能被同时按照状态一致点进行回滚，另外，一致和非一致检查点的策略并不能恢复云环境的sporadic操作，只会丢失更多（多台虚拟机将同时回滚）。对于这类的问题需要采取的手段有交互事件的记录（sporadic操作的记录）和事件重做，记录多方的交互事件，安全记录在日志中。在一方发生回滚之后，回滚恢复模块将会根据情况对回滚了的服务进行恢复，即进行重做（重新组织命令），将丢失的命令找回，对于需要找回的命令它的作用范围只能是回滚部分的。（对于重放方法，需要将当时的命令行为记录，完全的重放。由于模块能够接受过去的执行的命令，需要防止恶意的命令重放）。如果所在的多方交互环境中**禁止回滚**，那么不会出现一方授权由于回滚而丢失，但是对于系统的灵活性确是大大的降低了。 其他手段无。
多个虚拟机并不是单单的应为指令而产生了依赖关系，也可能是由于数据（除了新鲜数之外的，正常的数据呢？HDFS的namenode以及datanode）产生了依赖。（思考正常的数据存储是否需要归到这一类当中）
场景：虚拟机A，B进行密码的交互沟通。这个沟通过程需要协商3个随机数。其中随机数RN1与RN3由A发送，随机数RN2由虚拟机B发送。交互进行到RN1与RN2都已经交互完成。在虚拟机A准备发送RN3的时候发生了回滚，虚拟机回滚到发送完RN1的状态。此时回滚后虚拟机A希望B发送RN2，虚拟机B希望A发送RN3。双方都等待着对方不能发送的资源。A，B双方的交互进入“死锁”。如果协议有TTL时间限制，那么交互将被断开重新进行，如果没有将会进入死锁。
后果：进行协议交互的双方将会由于回滚产生死锁，无法解开，如果存在TTL限制那么会强制断开重新连接。
假设：虚拟机A,B都是安全的。都只能回滚自身的机器，并且他们使用的密钥交换协议对于对方的回滚是不可见的。这个场景下并没有特定的攻击者，这个是回滚引发的协议失效问题（各种前后资源相关协议）。
解决：首先在交互的过程中将协议的交互的内容都详细的记录。其次为了使协议多方状态一致，不产生死锁以及协议的连续性，需要将丢失数据RN进行重放。以达到多方一致的状态。这个方法与基于日志的回滚类似。
不存在时间相关的数据的情况：HDFS数据再次分布的情况，数据的增，删，改，查
场景：HDFS的场景中snapshot是针对全部的namenode以及datanode的，并没有设计单个datanode的snapshot，对于namenode的确有单个的checkpoint以及backup client。但是针对namenode的处理手段能够采用交互的操作相关方法进行处理。
增：重放
删：重做
改：重放，重做
查：不需要特殊操作
通用解决方案：
多方：协议的交互相当于normal操作，只要交互双方的状态一致，协议就会继续进行下去。所以回滚造成协议多方交互的状态不一致，需要replay之前的信息（需要确保信息与上一次的信息完全相同），让回滚的一方的状态达到与其它方的状态均一致的情况，让协议正常的向前运行。
重做不适合：双方交互的资源有时间相关的数据，例如密钥，随机数等等（具备单调性）。重做不可能达到一致的状态。
单方内部：除了上面的解决方法，单方内部的情况仍然能够使用一致性的检查点和非一致检查点的恢复。将交互的多个角色回滚到一致的状态点，使得协议能够继续执行下去。一致性检查点和非一致性检查点的策略对云系统的性能会有较大的影响。这些策略可能会带来大面积的虚拟机回滚，这在云环境中是不且实际的。
这个问题主要是交互多方回滚到先前的状态时候，造成当前正在运行的协议的状态阻塞。在非云环境的情况下面非一致的检查和一致的检查点的手段能够解决，但是这两个传统的方法在云环境中确是不适用的。为了解决这个问题，需要将所有的多方交互的内容（命令的参数等等）进行记录，在协议交互多方中的一方发生回滚之后，根据日志的情况计算出需要恢复的点，应为进行协议的多方，如果多方状态一致了那么所进行的协议也将会继续进行下去，类似于normal operation。这里采取重放的手段，将快照点到回滚点之间的状态根据日志进行重放之前的交互数据（例如随机数）。如果采取重做的措施，将会导致随机数将会与之前发送的随机数不同，将会导致多方状态不一致，从而导致多方交互失败。如果所在的多方交互环境中禁止回滚，这样的交互错误也不会发生。其他手段无。
使用回滚欺骗一次性的安全相关操作例如虚拟机自省以及远程证明。
场景：云管理者定时对于云虚拟机进行内存dump分析的检测，或者当云虚拟机运行新的进程的时候触发云管理者对于虚拟机的内存dump分析。然而恶意的云虚拟机拥有者，通过回滚自身的虚拟机到一个安全的内存快照状态。通过这样的方式欺骗云管理者对虚拟机进行内存分析。（其他的一次性的检测手段例如远程证明都能够使用回滚跳过。）
后果：虚拟机中的恶意行为将不会被云管理者检测出来，恶意的虚拟机操作者使用回滚机制欺骗云管理者的内存dump检测
假设：云虚拟机是不可信的，云用户是不可信的，云管理者是可信的。云用户可以回滚自身的虚拟机，云管理员可以回滚用户虚拟机，黑客可以通过入侵hypervisor层（hypervisor层的攻击面更广）获得虚拟机的回滚权限。云管理的内存分析手段并没有将回滚加入考量范围之内
解决：解决手段有如下两种。
通用解决方案：回滚能够改变虚拟机的状态，达到欺骗远程挑战者与云安全管理者的目的。针对这个问题需要完成一下步骤
回滚策略和re策略均不合适：多方欺骗问题是跨层次的欺骗，然而回滚策略和re策略能够解决的是同层的问题。
此类问题主要是旧快照中存在的安全隐患被回滚而再次出现。此类问题主要是采用不同的回滚策略（部分回滚，强删除）。通过部分回滚来让某些模块rollback-resist。本节的内容主要关注的是单台机器以及其内部出现的问题。
指的是各类的密钥与随机数。
假设：虚拟机A是可信的，黑客是不可信的，云管理者是好奇的。黑客尝试回滚用户虚拟机，降低用户虚拟机的安全特性，寻找恶意的快照。 虚拟机拥有自身的回滚权限，云提供商可以回滚用户虚拟机，黑客可以通过入侵获得虚拟机的回滚权限或者黑客能够探测到虚拟机的回滚事件。
场景：
新密钥丢失与旧密钥重现：
后果：用户虚拟机的安全性降低，黑客或者云提供商能够使用过期的密钥对云用户进行攻击。
解决：将密钥的存放介质设定为rollback-resist，这一部分介质在回滚之中将不会被回滚。
密钥恢复：恶意软件的攻击使得文件系统损坏，密钥文件无法读取，或者发生错误，需要使用回滚恢复密钥以及其他数据。此时的密钥希望是能回滚的。
解决：像正常的回滚一样将密钥回滚为原来的样子。
后果：只是正常的密钥的回滚需求，目前并没有在上述场景中发现什么安全问题。
额外的可能操作：密钥树的合并功能？
通用解决方案：
此类问题的解决方法需要将1，2两点进行结合，保证回滚的安全可靠。
关于密码学相关的数据，密钥，计数器等等，它们的状态都是时间相关的。计数器需要保持很强的单调性，所以关于计数器的部分不能回滚，然而密钥可以根据回滚的目的不同可能将采取不同的策略应对。如果是自动的错误恢复情况就按照rollback-resist策略进行，不回滚密钥区域。
旧的镜像表示软件也可能是旧的版本。这些旧的版本将会带来软件漏洞。这个问题已经在rvTPM中进行了测试。
假设：假设虚拟机不是恶意的，但是云管理员可能是趋于恶意的，或者黑客进行攻击掌握了虚拟机的回滚权限。虚拟机可以回滚自身虚拟机，云管理员可以回滚用户虚拟机，黑客可以通过入侵获得虚拟机的回滚权限黑客能够探测到虚拟机的回滚事件。
场景：
更新丢失：虚拟机动回滚将导致虚拟机中的软件的版本变为旧的版本，旧的软件版本众所周知有许多的不安全的因素，（例如旧的bash从v1.13到v4.3，可能存在heartshock漏洞），如果在回滚之后旧的软件的版本出现，将会导致虚拟机的安全性降低。
后果：恶意的攻击者利用残留的漏洞攻击虚拟机，导致虚拟机被黑客控制。
解决：在回滚之后，对安全相关的软件的版本进行度量，记入日志供远程证明使用，并且调用更新进程，进行低版本的升级、
更新恢复：更新发生的故障，需要回滚到更新之前的状态。这个过程只需要简单的恢复。
后果：只是正常的回滚动作，目前并没有发现什么安全问题
解决：只需要简单的回滚，没有后续的动作
通用解决方案：针对软件降级和软件升级失败的正常回滚两个方面进行考虑。
此类问题需要针对两种情况进行考虑。
由于软件在开发或者使用的过程中的（安全）问题，软件的版本需要不停的进行迭代升级。自发的回滚或者黑客的入侵回请然而回滚可能导致软件版本过低。从而降低软件的安全性，使得黑客更加容易的就能入侵目标虚拟机。需要在回滚之间检查软件的新鲜度，确保安全相关的更新不会被回滚跳过。
程序的执行过程
（和之前的交互问题之间进行比较，他们之间始终会有重叠）
假设：假设虚拟机是可信的，云管理者是好奇的，黑客是恶意的。虚拟机可以回滚自身虚拟机，云管理员可以回滚用户虚拟机，黑客可以通过入侵hypervisor层（hypervisor层的攻击面更广）获得虚拟机的回滚权限黑客能够探测到虚拟机的回滚事件。
场景：单机应用程序有一定的使用次数限制。应用大致分为3步，第一步检测剩余使用次数，成功后第二步提供服务，第三步退出服务。恶意的用户在第二步时给虚拟机做下了快照。之后在每一次需要使用服务的时候都能够利用快照进行恢复。（）
后果：收费软件的次数检测被跳过，能够被成功的跳过。
解决：将应用的操作详细记录日志，并且事先给出回滚抵抗点。要求回滚不能回滚到回滚抵抗点之后。
计数器混乱：应用A使用计数器保持自身的单调性，但是回滚可能导致应用A的计数器损坏，容易受到replay attack，例如一个login模块在计数器，单调性被破坏的情况下，它的输入密码错误次数上限的限制将会被轻易打破，从而攻击者能够使用brute-force攻击猜测登录密钥。
解决：为了保证计数器的单调性，计数器也是一个不能回滚的部分，需要将计数器设计为rollback-resist。上层的应用能够利用单调计数器抵御回滚产生的影响，保持自身的单调状态。
场景：虚拟机中的服务依照事务队列采取动作，事务队列中有许多的动作（查询数据库，数据库增加，数据库删除，例如，购买行为），在回滚之后，事务队列也同样回滚到过去状态，过去执行过的事务可能被再次执行。目前使用事务队列的数据库一般都是在命令发生错误之后回到发生错误之前的时间点（Redis的KV数据存储系统并不支持回滚）。
后果：导致服务重复进行已经完成过的操作，例如支付手段。（Apple）
解决：
对于软件的关键步骤被回滚跳过需要将关键步骤进行继续，对于回滚到关键步骤之后的回滚操作需要将关键步骤重做。防止恶意的回滚。
对于计数器的混乱问题，需要将计数器设定为rollback-resist（通过使用虚拟机外的计数器，这样需要修改源码或者使用Memoir）。
通用解决方案： 本场景中需要详尽的记录单机的事务队列的情况。
对于normal operation在虚拟机回滚之后仍然会按照
由于造成服务重复执行以及执行过的命令的原因是服务对于回滚是不可见的，对于自身的生命周期也是不可见的。需要添加额外的记录设备使之可见(Memoir)，同时能够处理由于回滚不可见造成的数据不一致的问题。
| 场景 | 额外安全记录 | 回滚手段 | 回滚重放 | 回滚重做 | 不允许回滚 | 其他 |
|---|---|---|---|---|---|---|
| 操作相关 | *交互记录 | 正常回滚 | 防止恶意重放 | *能够解决 | 缺少灵活性 | 无 |
| 数据相关 | *交互内容记录 | 正常回滚 | *防止恶意重放 | 时间相关无法重做 | 缺少灵活性 | 无 |
| 欺骗 | *可信回滚记录 | 正常回滚 | 不需要 | 不需要 | 缺少灵活性 | *重做安全手段 |
| 执行过程 | *单机事件记录 | 部分|回滚 | 防止恶意重放 | *重建任务队列 | 缺少灵活性 | 无 |
| 附加数据 | *单机事件记录 | 部分|回滚 | *防止恶意重放 | 需要重新交互 | 缺少灵活性 | 无 |
| 应用自身 | *回可信滚记录 | 部分|回滚 | 重放update | *重做update | 缺少灵活性 | 无 |
针对之前的场景将回滚问题的解决方法主要分为6种，分别是额外的安全记录（交互时间，回滚事件），回滚手段(正常回滚，部分回滚即将部分设备设置为禁止回滚），回滚重放（重放产生结果和之前的结果是一样的），回滚重做（重做的结果和之前的结果可能是不一样的），禁止回滚（所有环境下均禁止回滚），其他手段。
针对之前的分类情况，总共分为两大类一总是交互情况，一种是单机情况，针对每一种情况再分层3小类分别是欺骗类，操作相关类，数据相关类。下面针对这6类的问题的解决手段进行论述。
这个问题主要是交互多方回滚到先前的状态时候，造成当前正在运行的协议的状态阻塞。在非云环境的情况下面非一致的检查和一致的检查点的手段能够解决，但是这两个传统的方法在云环境中确是不适用的。为了解决这个问题，需要将所有的多方交互的内容（命令的参数等等）进行记录，在协议交互多方中的一方发生回滚之后，根据日志的情况计算出需要恢复的点，应为进行协议的多方，如果多方状态一致了那么所进行的协议也将会继续进行下去，类似于normal operation。这里采取重放的手段，将快照点到回滚点之间的状态根据日志进行重放之前的交互数据（例如随机数）。如果采取重做的措施，将会导致随机数将会与之前发送的随机数不同，将会导致多方状态不一致，从而导致多方交互失败。如果所在的多方交互环境中禁止回滚，这样的交互错误也不会发生。其他手段无。
这个场景主要是恶意的用户通过回滚自身虚拟机进行欺骗，针对一次性的安全相关操作例如虚拟机自省以及远程证明。在这个场景中并不是回滚，或者是重放重做策略能够解决的。因为回滚策略重做重放策略均是同层的安全解决手段，对于虚拟机自省类跨层次的问题就无能为力了。需要的是进行可信的回滚事件的记录，将每一次的回滚时间都可信的记录，并且不仅仅包括虚拟机的自身状态信息，同样也需要将回滚的快照信息，事件信息以及其他回滚相关的元素记录下来。在进行安全检测的时候将这些交于远程证明者或者是相应的监控程序，对于内存分析等虚拟机自省的场景为了防止回滚跳过检测需要在每一次回滚之后都需要重新进行内存dump分析。
虚拟机中的事务队列，维护这需要进行执行的操作等等。在回滚过程中，事务队列等的也同样发生回滚。解决这个问题首先需要进行事务的记录，详细记录快照点到回滚点时间的事务。回滚手段可以采取部分回滚的方法保持事务队列的回滚独立性（可能比较复杂也比较难），或者只是采取正常的回滚方法。对于回滚之后的恢复手段可以采取重放在保证重放不会产生恶意的前提下，或者重新根据日志建立新的任务队列。在不允许回滚的情况下能够保证执行过程不会被破坏
应用的自身运行也需要依赖其他的附加数据例如密钥，随机数，计数器等的数据完成自身的功能。上述谈到的3种数据有着自身的密码学属性（对于生成操作，只能被重放不能再次生成）。对于这个问题，首先需要记录事件，将关于附加数据的事件计入在可信的日志中。接下来可以采取两种不同的方式，一种是部分回滚，即保证附加数据的单调性，将附加数据的存储区域设置为不可回滚的以保证安全。但这这个解决方案不能解决所有用户的需要。另外采取完整回滚的方法，之后按照日志以自定义的策略对附加数据进行恢复。以试附加数据达到安全的状态。新旧密钥，有漏洞的密钥，单调的计数器，随机数的生成等等，根据用户的使用场景的不同将会采取不同的策略进行恢复。在禁止回滚的系统中，此问题将不复存在，同样也带来了不灵活的问题。
应用除了附加的数据之外，自身的状态也是需要进行额外的安全关注的。例如虚拟机自身的软件版本问题。当虚拟机回滚到了旧的image中，里面的软件版本也可能是旧的没有安装安全关键更新。由于虚拟机的回滚降低了软件的安全性，一些0day漏洞可能会被利用造成虚拟机的安全性降低黑客有所企图。对于这个场景。需要对回滚事件进行可信记录，以及对软件的安全关键版本进行记录。如果禁止安全关键软件版本的回滚，可能带来一些不便（软件升级失败问题）。所以采取正常的回滚将软件同虚拟机一同进行回滚。同时进行软件的安全版本进行相应的检测，并且将检测结果加入远程证明中。回滚结束之后根据用户需要进行软件的安全升级。