简要总结

• 方法：提出了一种自动化黑盒技术，检测有状态网络协议实现中的状态机错误
  • 自动化要求：需要提供协议的实现模型（可能不准确）和以 DFA 形式提供的协议状态机错误目录
• 贡献：
  • 提出了一种新的完全黑盒技术，用于检测有状态网络协议实现中的漏洞和错误，其起点是一个模型和一组编码为自动机的协议状态机错误。从此时起，该技术就完全自动化了。
  • 为我们的技术的
    • 通用性提供证据，将其应用于两种不同网络安全协议（SSH 和 DTLS）的广泛使用的实现
    • 自动检测以前未知和/或肉眼错过的漏洞和错误的有效性检查学习到的模型。

问题与思考

这篇文章看上去是根据提取的协议的实现模型和协议状态机去检查协议的实现状态机是否正确。那么问题来了：

• 怎样提取的现实中实现的协议状态机？
  • 通过机器学习去提取实现的协议状态机，在论文：Model learning and model checking of SSH implementations 和 Analysis of DTLS implementations using protocol state fuzzing 中实现的。都是同一位一作，看来是一脉相承的工作了。
• 根据什么去判断是否出现了漏洞？
  • 通过检查现实实现的协议是否满足错误状态序列来检查协议实现是都正确。
  • 那么错误状态序列又是什么？
    • 查看他们发布的虚拟机，检查其中的代码，发现他们的执行流程是
      1. 通过 DTLS_bugpatterns 和 SSH_bugpatterns 下面的 dot 文件加载错误状态的状态机，这应该就是文章中提到的协议状态机错误目录（catalogue of state machine bugs）了。
      2. 加载通过机器学习的现实实现的协议状态机
      3. 根据文章中的算法检测现实协议状态机实现是否正确
    • 尽管这篇文章的核心在于他们的算法，但我对这个错误状态序列的提取更感兴趣。
      • 作者们宣称这个错误状态也是通过模型学习获得的，那么它的实现在哪呢？
      • 论文的第 IV-B 小节开头描述了可以通过实现规范（比如 RFC）提取安全性和正确性要求，然后就开始描述 DTLS 的错误状态机的构建以及将错误编码到自动机的方法，最后才考虑如何获取这些需求（也就是寻找错误匹配模式）：
        1. 根据协议规范中的特定要求直接构建和完善；
        2. 来自先前报告的协议实现的状态机错误；
        3. 通过使用我们关于协议的知识并运用尝试。
      • 呃。
      • 接着看，作者们提到他们在第五节提出了一种补充方法，根据协议会话中允许的交换消息序列的描述系统地构建错误模式。
        • 让我们来先猜一波：是不是根据协议的描述将不正确的消息序列判断为错误模式？
      • 好，让我们来看看第五章
      • 首先介绍通过 RFC 定义来组合几种 DTLS 的状态机（主要是捕获违反 RFC 定义的状态），然后介绍缺点：
        1. 通过 RFC 定义的错误状态机会很大，用于检测时速度慢；
        2. 发现违规行为时不会告知违背了哪种要求
      • 于是作者的想法是先检测特定错误模式，后检测通用的模式
      • 好吧，看上去是手动组装的错误模式
    • 接下来看实验吧
    • SSH 模型学习也给出了源码：https://repository.ubn.ru.nl/handle/2066/184275
    • 作者们在他们的历史文章基础之上又添加了一些新的错误模式，看上去都是手动构造的：

• 然后通过扩展的错误模式去检测新的漏洞

总结

并不是我想找的内容，叹气，可以深究的点应该还有：

• 本文主要讨论的是 DTLS 协议，提供了 DTLS Fuzzer，可以看一看是不是根据协议状态去 Fuzz 的。
• 文章作者整理的 DTLS 和 SSH 错误模式可以借鉴，看看能不能用到 Fuzzer 上。

还有一张不错的作者视角的 SSH 协议状态图，也可以参考分析一下。