RollBack Workspace

回滚分类

本章内容主要针对前期的工作以及，代博的建议将之前的回滚问题进行细化，分类。

攻击者可能是：恶意的用户，恶意的SaaS服务商，恶意的（好奇）云管理员。其中恶意云管理员场景主要负责利用回滚跳过陈海波论文中的场景的问题。

回滚导致状态失效错误

可能更加的倾向于多机的错误，网络中间盒的数据状态不一致等多机交互环境中回滚引发的错误的问题。

描述：回滚失效错误指的是由于回滚造成多台虚拟机的状态不一致使得两个虚拟机之间无法继续工作或者产生错误，需要使用其他手段统一虚拟机的状态。这个主要指的是错误的发生，这个错误中并不包含特定的攻击者角色（当然如果需要包含也可以强制的包含一个攻击者，利用回滚触发错误（它的目的是什么?触发错误完成DoS？），利用回滚其他虚拟机完成特定的意义）。

1. SP与CU 这个是否能归结为回滚漏洞
   假设：假设云用户，云提供商都不是恶意的，SaaS服务提供商是倾向恶意的，他们都对于自己的虚拟机拥有回滚权限（云用户回滚自身虚拟机，SaaS提供商能回滚自身云服务虚拟机，可能也可以攻击目标虚拟机导致目标虚拟机回滚，云提供商能回滚云用户的虚拟机），SaaS可以通过探测Google授权服务器的回滚（或者入侵Google触发回滚，这个难度可能比较高），从谷歌服务器的回滚错误之中提升自己的权限。
   场景：用户A利用Google上面的帐号来登录另外一个网站W（恶意的）（Single Sign-On模式），通过OAuth2.0协议，W网站在Google的Authorization Server上面进行了注册，并且获得了相应的授权。此时网站W能够通过该授权访问用户A的相应资源（照片，文件，通讯录）。之后用户A在Google的授权服务器上面注销网站W的注册授权（或者缩小了网站W的授权数据的范围，这个更加的有可能发生），然而Google的授权服务器发生回滚（此时的网站W能通过探测这个回滚,具体的探测方法？），用户A的注销的请求被回滚给覆盖。已经注销授权的网站W在此时能够再次访问用户A的未授权的数据。
   危害：发生回滚后，恶意的SaaS服务提供商能够在用户不知情的情况下访问未授权的用户数据。
   解决手段
   这个场景下面由于问题出现在于多方，无法计算出一致的检查点，所以无法利用传统一致性检查点回滚，以及非一致性检查点回滚解决。需要在授权服务器回滚之后重做由于回滚而丢失的用户注销授权的请求（回滚时候需要注意不能产生重放漏洞）。采用重放或者重做方案。

2. CU与SP之间或者内部的交互问题
   下面提及的问题感觉影响会比较小一点，并没有过大的危害，而且之前可能已经会有讨论了[checkpoint.ppt]（只不过给抽象化了，同样我们也能使用抽象的方法解决问题，例如实体的信息的类型，不产生孤儿信息以及孤儿信息产生的影响）。
   假设：虚拟机A,B都是安全的。都只能回滚自身的机器，并且他们使
   用的密钥交换协议对于对方的回滚与否是不可见的。这个场景下并没有特定的攻击者，这个是回滚引发的协议失效问题。
   场景：虚拟机A，B进行密码的交互沟通。这个沟通过程需要协商3个随机数。其中随机数RN1与RN3由A发送，随机数RN2由虚拟机B发送。交互进行到RN1与RN2都已经交互完成。在虚拟机A需要发送RN3的时候发生了回滚，虚拟机回滚到刚刚RN1的状态。此时回滚后虚拟机A希望B发送RN2，虚拟机B希望A发送RN3。双方都等待着对方不能发送的资源。A，B双方的交互进入“死锁”。如果协议有TTL时间限制，那么交互将被断开重新进行，如果没有将会进入死锁。
   后果：虚拟机A，B进入死锁，或者到等待时间到期时自动重联。
   解决手段
   当问题出现在CU与SP内部时，基于一致性检查点以及 基于非一致性检查点策略的方法也均能解决。（可能性能会不同，而且非一致性检查点策略中的多米诺现象是云环境中需要尽力避免的情况）。将虚拟机A，B的状态回滚到协议之前，或者没有丢失随机数的状态。这样A，B能够继续沟通下去。或者采用重放丢失的随机数。（回滚的时候同样需要防止重放漏洞），由于随机数的生成结果是不确定的（可能和时间相关）所以采取重放策略进行回滚的后续处理。（重做将导致随机数结果不一致，需要重新协商随机数）

3. CU内部，或者SP内部（都是多机内部）
   这个问题和上面的问题可能可以抽象成为一类问题。
   假设：虚拟机A,B都是安全的。都只能回滚自身的机器，并且他们server的任务分配策略对于回滚也是不可见的。在这个场景中也没有特定的攻击者。
   场景：虚拟机A与虚拟机B作为协同工作的（同一个master的slaves）。共同完成一个计算任务（由input数据驱动的计算任务，具体是什么任务）。任务进行到下一个stage，（可能需要的仅仅只是几个标志位的不一致。）需要A的状态处于Sa，B的状态处于Sb。由于其中Sb发生了错误回滚，运行到了状态Sb'（状态Sb到Sb'需要经历过一系列的计算子任务）。导致任务不能正常运行到下一个stage。（需要找到一个现实的场景进行进一步的阐述。）
   后果：在没有外界介入的情况下面，协同工作将会无法进行，虚拟机B的状态将会与其他slaves均不
   一样的，导致协同工作
   解决手段
   当问题出现在CU与SP内部时，基于一致性检查点以及基于非一致性检查点策略的方法也均能解决。（可能性能会不同，而且非一致性检查点策略中的多米诺现象是云环境中需要尽力避免的情况）。回滚之后需要重做Sb'到Sb状态之间的子计算（这些计算中不包括输出于时间相关的动作，例如生成随机数随着时间随机数生成的是单调的）。

丢失用户的Auth请求（可以被攻击），协议的协商出现问题，

数据镜像回滚漏洞（各种漏洞，重放漏洞，安全性降低）静态的回滚

回滚探测攻击行为

描述：恶意的云用户，在云环境中收集目的虚拟机的Input/Output信息，并且通过检测目标虚拟机的回滚，从而对目标虚拟机发动基于回滚的攻击，重放信息。导致回滚虚拟机做出错误操作？这样的攻击行为的可行性是否存在？

这一点能否和结合起来，这个相对与是单机的错误。

重放漏洞的问题以及和本节结合在一起了

描述：回滚的另外一个重要的快照，并不是安全的。在之前的失效错误分析时候，所有的快照被默认为安全的。但是实际却不是这样的（问题1与问题2讨论的问题的场景并不是完全一样的）。快照表示着一个虚拟机的状态，这个状态里面可能存在着过期的密钥，过期的软件版本，没有打补丁的漏洞软件（但是这个问题看到和上面的内容也很相似，过期的密钥丢失了更新的部分，过期的软件版本缺少了升级的过程，漏洞软件缺少了打补丁的过程，但是上面引发的是错误，然而这个引发了安全漏洞，不一定会导致服务的失效，然而将会导致服务的安全性降低）。之前讨论的问题1的讨论的场景倾向于动态的多级问题，但是这个主要是静态的快照问题，也能当作单机问题（rvTPM问题）。

假设：虚拟机A是可信的，黑客或者是云提供商不
是可信的。他们尝试回滚用户虚拟机，降低用户虚拟机的安全特性，寻找恶意的快照。
场景：攻击者：无，或者黑客，通过回滚虚拟机使得自身能够继续进行攻击
在T0时刻虚拟机A使用了Key1进行安全通信，T1时刻感染了恶意软件，Key1被窃取。T2发现恶意软件，进行杀毒。并且更新了通信密钥Key2。T3时刻发生错误，虚拟机回滚到T0，通信使用密钥变成了Key1。由于密钥被窃取，导致黑客能够利用Key1对虚拟机A进行攻击。回滚产生了漏洞，降低了自身的安全性。
后果：用户虚拟机的安全性降低，黑客或者云提供商能够使用过期的密钥对云用户进行攻击。
解决手段
回滚之后将残留的Key1更新。（可以采用重放，也可以采用重做）重做需要重新与其他方进行沟通密钥。重放新生成的key2需要包成key2的绝对安全，并且重放过程的绝对安全。然而重做没有这么复杂的安全要求，但是当密钥的交互方增加的时候重做的效率可能会很低。

假设：密码访问模块是可信的，虚拟机也是可信的，黑客或者是云提供商不是可信的。
场景：攻击角色：黑客攻击CU以及SP 陈海波论文中的场景 破坏单调性（单调性计数器可能在内存中也可能在持续存储的区域中，他们之间的也可能由于回滚造成差异） （这个貌似能够当做是重放攻击，并不能重放是重放过去发送过的信息但是这个并没有这样做）
目前的许多密码访问模块都是能够防止暴力攻击尝试的，但是在回滚许可的环境下面，这个密码访问模块的单调性，以及防止暴力攻击尝试的功能将会被破坏。破坏后攻击者能够暴力破解虚拟机的密码。
后果：用户密码尝试成功，用户虚拟机成功被攻击。
解决手段
采用部分回滚，将需要绝对单调的计数器隔离在回滚区域之外。保证密码访问模块能够保证其绝对单调。防止回滚造成单调数据不一致问题。（不回滚的数据存储区的设置是否可能？）

欺骗

这里的欺骗指的是，攻击者通过回滚自身欺骗其他人。陈海波的论文中的欺骗是攻击者通过回滚实体来欺骗实体。 此处的欺骗是回滚自身的状态，利用回滚的不可知性对其他第三方进行攻击。

欺骗就像是rvTPM中的回滚的单机的回滚的路径的问题。回滚的路径的可信的问题或许也能说成回滚的快照的可信问题。
回滚的不可见性，不容易被在别的层次的实体感知

描述：回滚作为一种状态的变化，但是很惊讶的是目前回滚对于很多的情况下来说的都是透明的。并不是那么容易让人感知的。例如虚拟机从S0状态到了S1状态。外界的虚拟机无法知道是由于回滚，或者是其他的操作让虚拟机到达了这个状态。

场景：

1. 假设：云提供商是可信的，云用户也是可信的。但是SaaS服务提供商不是可信的。攻击角色：SP攻击CU
   目前的虚拟机可以配置vTPM作为一个安全环境的度量工具。提供给外界进行远程证明。SaaS服务提供上使用一台虚拟机为用户提供服务。用户在开始使用服务以及服务结束的时候都进行远程证明。SaaS服务上在进行第一次远程证明进行回滚使用有漏洞的内核来为用户提供服务企图窃取用户的信息。在服务结束进行远程证明的时候将虚拟机进行回滚，然而vTPM无法记录回滚的事件。SaaS可以在用户不知情的情况下面恶意的窃取走用户的信息。
   后果：云用户使用了不可信的服务，这个服务将会将用户的信息，数据泄漏。（XCodeGhost苹果的App的安装环境的问题，安全编译问题）
   解决手段
   rvTPM中已经提及了，细粒度的回滚，数据划分

2. 假设：云提供商是可信的，SaaS服务提供商或者是云用户是不可信的。他们利用回滚将自身的内存状态回滚，欺骗云提供商。攻击攻击角色：SP攻击CP
   CP对于自身提供的虚拟机提供一系列的监控与检测工作（FMA，分析内存检查恶意软件，使用whitelist限制软件）。每次进行内存分析（定时或者触发的行为）。在内存分析取内存之间，使用回滚将待检查的内存，替换为没有问题的安全内存，欺骗CP的检测工具。让内存分析工具一直获取的是攻击者精心准备好的内存，从而欺骗云监控方，在监控结束之后将虚拟机状态回滚到恶意的状态。
   后果：云上的虚拟机摆脱了来自于云控制层的监控，或者利用回滚误导云管理层。从而在云的不知情的情况下从事恶意行为。
   解决手段
   对于回滚行为，当行为发生之后安全监控操作需要进行重做。或者使用其他手段对回滚到的镜像进行安全性的度量。

讨论结果

分别将之前的讨论的3个分类划分为：交互类问题，
单机类问题，欺骗问题。
同时对这3类的问题进行了进一步的细化分类。

交互类错误问题：
这类问题的统一的解决思想是re策略即replay以及redo。

1. 操作类交互问题。例子：授权被恶意或者无意地删除。来自外界的命令。
   用户的请求丢失，由于这个请求引发的修改或者称为sporadic操作的丢失需要采取re策略。传统的回滚基于非一致或者一致检查点的策略完成回滚恢复后用户的请求仍然处于丢失的状态，没有办法采取传统的手段完成。然而传统的基于日志的回滚，往往由于日志过于琐碎回滚的速度比较慢，并且由于允许过去的消息再次的重放可能会在成第二次的消息不一致的情况。(例如，支付请求，可能完成重复支付)。于是最终选择的方法是进行redo，将丢失的需要恢复的请求（这样的请求是什么）进行redo
   攻击后果：恶意的攻击者能够利用服务器的回滚（回滚的原因暂时不计）完成自身权限的提升获得访问权限之外的信息。

2. 数据相关问题。例子：协议的随机数，时间戳协商问题。交互协议问题，找到死锁场景，没有time out时间设定的例子。
   A显示连接已断开，然而B显示连接尚未断开。导致A无法请求重连（因为B显示已经连接上，不会重新建立连接），B也无法请求断开（A的状态已经是断开的了）。
   采取的策略也主要是re策略。
   造成死锁的原因是因为交互双方所求的资源，正常的情况下对方都不可能会再次发送。
   一方回滚：由于对方的情况不会发生改变，不能采取redo（这样导致双方的信息不一致，例如：如果重新发送一个新的RN2，会导致和之前的RN2不同，密钥的交互一样会失败），在这里将会采取replay重放数据保持数据一致。
   双方回滚：回滚之后还是在协议交互的中间过程，已有的重叠协议部分采取replay，非重叠的部分既可以采取replay也可以采取redo，这里采取redo比较好，因为协议的运行实际上以normal operation并不是sporadic operation，只要双方的状态是一致的那么协议的交互就能自然而然的进行下去。

3. 数据操作混合相关计算问题。例子：待补充，多数据库融合同步的问题问题。云环境中自身的数据交互问题。数据同步，数据共享。

单机类错误问题：
此类问题主要是采用不同的回滚策略（部分回滚，强删除）。通过部分回滚来保持某些模块的rollback-resist

1. 密码学key相关的的漏洞。例子：密钥过期，密钥丢失。
   密钥丢失：由于回滚导致无法重新生成的key发生了丢失，密钥存放在硬盘上面，并且以及和远端进行了交互，这个密钥作为一组虚拟机之间通信的密钥，如果回滚之后密钥丢失，那么必须重新交互密钥。采取部分回滚策略，将密钥的存储区域设置为rollback-resist，在回滚的时候将不予以回滚。这样保证了新生成的密钥不会丢失。
   密钥删除：对于以及泄漏的或者是过期的登录密钥，如果由于回滚的原因发生了重现，导致安全性降低（攻击者将会使用过期密钥进行攻击，获得虚拟机的权限），将密钥的存储区域设置为rollback-resist的将会防已经删除

2. 软件或者系统的相关update补丁丢失。
   云环境中的软件众多，打补丁也是一件十分平常的事情。升级过程中失败，发生错误需要采用回滚消除影响。回滚与更新的主要两个方面如下：
   更新丢失：回滚导致软件的版本变为旧的版本，旧的软件版本总所周知有许多的不安全的因素，（例如旧的bash从v1.13到v4.3，可能存在heartshock漏洞），如果在回滚之后旧的软件的版本出现，将会导致虚拟机的安全性降低。
   更新恢复：更新发生的故障，需要回滚到更新之前的状态。这个过程只需要简单的恢复即可。

3. 事务队列的回滚不可见性，回滚产生事务被重放，counter（是否能够划分为第一类子问题）。陈海波论文中的暴力破解问题。并不是主动的，是回滚之后出现了可以重放攻击的机会。
   系统中一些模块需要依靠单调的counter，来保持自身的对于请求新鲜度的判断，如果不采取其他的措施将导致这些模块容易受到重放攻击。
   对于counter在允许回滚的系统当中需要被设置为rollback-resist的属性即在回滚过程中不将回滚counter，即部分回滚。counter在部分回滚的过程之中保持自身的单调性。

欺骗类错误：

欺骗机器内部应用，应用破解等等，通过回滚

1. 攻击者通过回滚自身来欺骗监管者，挑战者。
   主要的问题是目前的一些检查机制，可能并不会将回滚的因素考虑其中，回滚能够将攻击的痕迹进行消除，例如VMI的例子。在为了应付来自云管理层的检查将自身的内存回滚到正常的状态，在回滚结束之后继续进行恶意的行为。
   采用的方案：重做安全手段，对于每一次发生回滚之后，安全检测都将重新进行检测，防止在回滚带来的恶意的影响。

2. 用户在使用服务的时候，恶意的服务提供商可能将会利用回滚对允许的用户配额进行欺骗。（weak）
   需要对每一个回滚给出理由，允许用户对回滚理由进行升级（陈海波论文中的只是记录回滚，并没有给出具体的回滚的度量的办法，只能给用户回滚的日志并不能提供其他的度量办法）