Mar*_*ico 1 security itext digital-signature itext7
我想知道 iText 是否正在研究或已经修补了此处描述的影子攻击：https ://www.pdf-insecurity.org/ 影子攻击：隐藏和替换签名 PDF 中的内容（2020 年 7 月）我刚刚找到有关2019 年发现的漏洞 https://itextpdf.com/en/blog/technical-notes/avoiding-pdf-digital-signature-vulnerabilities-itext
首先，iText 不需要打补丁，无论是 7.x 版本还是 5.5.x 版本。
在任何一种情况下，通过增量更新检查是否对签名的 PDF 进行了任何更改的方法，SignatureUtil.signatureCoversWholeDocument以及在 pdf-insecurity 站点上提供的操作示例的情况下AcroFields.signatureCoversWholeDocument分别报告的方法false，即它报告添加了某种更改签约后。
此外，在任一情况下，检索已签名的修改，该方法SignatureUtil.extractRevision和AcroFields.extractRevision分别也返回原来的，尚未操纵，对于这些实施例签名版本。
这种行为并不奇怪。影子攻击的描述清楚地表明这些攻击是通过增量更新（在 RUB 研究人员的漏洞报告中称为增量保存）的方式应用于 PDF 的。该signatureCoversWholeDocument方法现在会准确检查签名修订后文件是否没有内容；因此，它检测到影子攻击添加的增量更新。并且该extractRevision方法返回文件直到相应有符号范围的末尾；因此，它不会从影子攻击应用的增量更新中返回任何添加。
为了确保我检查了signatureCoversWholeDocument被操纵的示例文档的 iText 7输出，请参阅此 ShadowAttacks 单元测试，并且正如预期的那样，该方法报告有问题的签名没有覆盖整个文档。
可以阅读漏洞报告将类似 iText 的行为称为“有限漏洞”，描述为
在允许的修改（例如，评论）以及不允许的 修改（攻击）的情况下，会发出相同的警告。受害者无法区分这两种情况。
（漏洞报告 - 绕过 PDF 中签名验证的攻击 - 2020-03-02）
在我看来，这个术语只有在所讨论的软件以其他方式承诺时才有意义，即区分允许和不允许的更改并相应地报告。否则，它不是漏洞而是（希望记录在案的）行为，而易受攻击的只是错误地期望不同行为的用户。
据我所知，iText 并没有承诺分析增量更新的变化（超出检索 LTV 信息）。Bruno Lowagie 在他关于 PDF 数字签名的 iText 白皮书中写道，已经对开发路线图进行了分析；但是，据我所知，目前没有可用的（公共）实现。
因此，我不会将 iText 的行为特别称为“有限漏洞”。
当然，如果某些软件基于iText 进行签名验证，并承诺根据上述 iText 的验证结果识别允许和不允许的更改，那么该软件确实至少具有有限的影子攻击漏洞，除非将它们报告为不允许的更改.
至少被广泛使用的被报告为易受攻击的验证器，首先是 Adobe Acrobat Reader，很可能会迅速尝试更正他们的代码，至少表明存在更改，甚至报告它们为不允许的。尽管如此，尝试并实施一些检查影子攻击准备迹象的方法可能是有意义的。我目前正在研究这方面的一些概念证明。