安全与密码学2018arxiv.org
Chaff Bugs：通过让软件“更多 bug”来威慑攻击者
Chaff Bugs: Deterring Attackers by Making Software Buggier
进阶 · 约 35 分钟读完前置知识：软件安全基础、二进制漏洞利用、程序分析与SMT
导读
这篇论文提出用“chaff bugs”（诱饵 bug）来对抗攻击者：在软件中注入大量看似可利用、实际不可利用的缺陷，把真实漏洞淹没在噪声中，增加漏洞挖掘和利用的成本。根据评论中的转述，方法主要作为构建后阶段处理二进制，假定攻击者拿不到源码，因此不适用于开源软件；作者也承认未来代码变化可能让原本不可利用的 bug 变得可利用。评论重点质疑诱饵 bug 是否能真正与真实 bug 难以区分，以及会不会干扰开发者调试和漏洞分诊。
HN 关注点：HN 读者被这个反直觉的安全思路吸引，讨论焦点是它能否骗过有 profiling/SMT 工具的攻击者，以及工程副作用。
HN 评论精选
这几条评论里：质疑 2 亲历 2
质疑作者承认该技术只适用于不公开源码的二进制，且可能增加调试和分诊成本。
这个想法非常有趣，也相当“天马行空”。不过作者自己在第二页就列出了几个明显缺点：他们假设攻击者能拿到编译后的二进制文件，但拿不到源码。作者称这是一个严重限制（意味着该技术无法保护开源软件），但又是必要的：开发者不太可能愿意维护被塞进额外 bug 的源码，而且未来代码改动可能让原本不可利用的 bug 变得可利用。因此他们主要把系统视为构建过程中的一个额外阶段，用来加入不可利用的 bug。我担心的是，这个额外构建步骤是否也会让开发者调试和分诊真实 bug 时很头疼。
hyper_reality查看英文原文
The idea is quite fascinating and 'out there'. However, the authors themselves cover several clear drawbacks on the second page: > We assume that the attacker has access to a compiled (binary) version of the program but not its source code. Although this is a severe limitation (it means that our technique cannot be used to protect open source software), it is a necessary one. Developers are unlikely to be willing to work with source code that has had extra bugs added to it, and more importantly future changes to the code may cause previously non-exploitable bugs to become exploitable. Hence we see our system as useful primarily as an extra stage in the build process, adding non-exploitable bugs. I wonder if running software through this additional build step would also cause headaches for developers debugging and triaging real bugs in the software.
质疑质疑诱饵 bug 可通过变量使用统计、内存 profiling 等被识别，实验证据不足。
这可能是一个可行方向，但我有些担忧。我觉得它只会迫使攻击者更有选择性，而这些技术很难不露出破绽。例如，他们通过覆盖未使用变量来让 bug 不可利用；那有什么能阻止对手根据统计变量使用次数的 profile 数据来决定优先调查哪个 bug？这样诱饵 bug 就必须在动态使用次数上匹配真实变量。至于过度约束（over constraint），作者指出攻击者可以用 SMT 求解器判断某个 bug 是否被安全约束；他们提出把约束分散开，迫使攻击者推理所有路径。但同样，没有什么能阻止对手对内存区域做 profiling，了解施加了哪些约束，然后优先处理约束最少的区域。这个思路很聪明，因为它试图利用攻击者推理能力的根本极限，但我需要更多实验分析才能相信这些诱饵 bug 对攻击者真的不可区分——除非攻击者确实要收集规模随程序路径数指数增长的 profiling 数据。我认为跑几次程序就足以区分诱饵 bug 和真实 bug。
DSingularity查看英文原文
This could be a viable direction but I have some concerns. I feel it will simply push attackers to be selective and it will be difficult for these techniques to avoid standing out. For example, consider their technique of making things non exploitable by overwriting unused variables. What’s to stop adversaries from prioritizing which bug to investigate based on profile data counting uses of variables? Now these chaff bugs need to somehow match the dynamic use counts of real variable. What about the over constraint? Well the authors point out that attacker’s can use SMT solvers to determine that a bug is safely constrained. They propose spreading out the constraining to force the attacker to reason about all paths. Again, Nothing stops the adversary from profiling the memory regions to learn what constraints are being applied followed by prioritizing the least constrained regions. While clever in that it tries to use fundamental limits of reasoning against the adversary, I need more experimental analysis before I am convinced that these chaff bugs are actually indistinguishable to an attacker unless they truly collect profiling data that is exponential in size of programming paths. I think that a few runs would suffice to distinguish the chaff bugs and real bugs.
亲历早年用随机内存破坏制造“假 bug”来防软件换牌盗版的轶事。
过去，人们会拿品牌软件，覆盖掉版权声明，然后把结果当作自己的“兼容”版本出售。我的游戏会检查版权声明是否完整；如果不完整，它就会在随机时间用随机值覆盖内存中的某个随机字节。目的是让被“换牌”的游戏看起来有莫名其妙、没法用的 bug。我不知道这有没有效果，大概没有。
WalterBright查看英文原文
Back in the olden daze, people would take branded software, overwrite the copyright notice, and sell the result as their own "compatible" version. On my game, it would check to see that the copyright notice was intact. If it wasn't, it would, at random times, overwrite a random byte in memory with a random value. The idea was for the "rebranded" game to appear to be uselessy buggy. I have no idea if it was effective or not. Probably not.
亲历一个类似思路：不阻止未授权使用，而是注入隐蔽错误让盗版体验变差。
当年我不得不用硬件加密狗保护软件时，想出了一个我觉得最邪恶的点子。给不了解的人解释一下：加密狗是代表软件使用许可的硬件令牌，必须插在电脑上，软件才能检查到它。使用加密狗要么需要在程序里加代码检测其存在，要么用存放在加密狗里的密钥加密可执行文件，再由启动器从加密狗取密钥解密程序。无论哪种方式，如果加密狗不在，就会弹出对话框说软件未授权，然后终止程序。我的邪恶想法是：事先告诉用户软件必须用加密狗，但加密狗不在时并不终止程序，而是往程序处理的数据里引入细微错误。缺加密狗的 CAD 程序？每秒随机把一个顶点移动 1 像素。缺加密狗的统计程序？在聚合计算时往数据集里加入随机数。缺加密狗的视频游戏？游戏随机卡顿。当然，你可以在没有加密狗的情况下用软件，但会非常烦人。我一直没机会实现，因为后来大家意识到加密狗这玩意很蠢。
c-linkage查看英文原文
Back when I had to secure software using hardware dongles, I came up with my most evil idea. For those who don't know, dongles are hardware tokens that represent your license to use the software, and the dongle had to be attached to the computer so the software could check for its presence. Using dongles required you to either add code to your program to test for the presence of the dongle, or you could encrypt the executable using a key stored on the dongle and a program launcher would retrieve the key from the dongle to decrypt your program. In either case, if the dongle wasn't present a dialog would appear telling you the software was unlicensed and then terminate the application. My evil idea was to tell people up front that the dongle was required for the software to work, but rather than terminate the application when the dongle wasn't present I would introduce subtle errors into the data manipulated by the program. * CAD program missing the dongle? Each second, a random vertex is moved by 1 pixel * Statistics program missing the dongle? Random numbers are added to data sets during aggregate calculations * Video game missing the dongle? Game stutters at random intervals. Oh sure you could use the software without the dongle, but it would be super-annoying to do so. I never got the opportunity to implement this because people realized that dongles are dumb.
历次讨论
- 2018Hacker News 讨论帖100 分 · 30 评
- 2021Hacker News 讨论帖14 分 · 2 评
- 2022Hacker News 讨论帖26 分 · 15 评
同领域还值得读
如何入侵一台已关机的电脑：在 Intel ME 中运行未签名代码
How to hack a turned-off computer, or running unsigned code in Intel ME
这篇 Black Hat 2017 白皮书讨论 Intel Management Engine（ME）的安全问题：如何在 ME 中运行未签名代码，以及攻破处于关机状态的电脑的相关…
安全与密码学2017 · 543 分 · 107 评专业 · 约 40 分钟编辑精选比特币：一种点对点的电子现金系统（2008）
Bitcoin: A Peer-to-Peer Electronic Cash System (2008)
中本聪 2008 年发表的比特币白皮书，提出了无需可信第三方的点对点电子现金系统。
安全与密码学2017 · 536 分 · 394 评入门 · 约 45 分钟编辑精选GPRS 加密算法 GEA-1 的密码分析表明存在故意弱点
Cryptanalysis of GPRS Encryption Algorithms GEA-1 suggest intentional weakness
首次公开了对 GPRS 加密算法 GEA-1 和 GEA-2 的密码分析攻击。
安全与密码学2021 · 487 分 · 107 评专业 · 约 90 分钟编辑精选Signal 消息协议的形式化安全分析
A Formal Security Analysis of the Signal Messaging Protocol
用形式化方法分析 Signal 消息协议（TextSecure）的安全性：作者在多阶段密钥交换模型下，借助自动化证明工具对协议的密钥协商与 Double Ratchet 密钥更新…
安全与密码学2016 · 353 分 · 230 评专业 · 约 120 分钟编辑精选A2：模拟恶意硬件
A2: Analog Malicious Hardware
论文研究如何在芯片设计阶段植入模拟电路形式的恶意硬件后门，使其难以被常规检测发现。
安全与密码学2016 · 315 分 · 94 评专业 · 约 75 分钟编辑精选