iText 和 Shadow 攻击
iText and Shadow attacks
我想知道 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 和 AcroFields.signatureCoversWholeDocument，报告 false pdf-insecurity 网站上提供的操纵示例，即它报告说在签名后添加了某种更改。
此外，在任何一种情况下，检索签名修订的方法，分别为 SignatureUtil.extractRevision 和 AcroFields.extractRevision，以及 return 这些示例的原始的、尚未操作的、签名的修订.
这种行为并不奇怪。影子攻击的描述清楚地表明，这些攻击是通过 增量更新（在漏洞中称为 增量保存 的方式应用于 PDF RUB 研究人员的报告）。 signatureCoversWholeDocument 方法现在准确检查文件在签名修订后是否没有内容；因此，它检测到影子攻击添加的增量更新。而 extractRevision 方法 return 将文件保存到相应有符号范围的末尾；因此，它不会 return 从影子攻击应用的增量更新中添加任何内容。
只是为了确保我检查了 iText 7 signatureCoversWholeDocument 输出的被操纵的示例文档，请参阅 this ShadowAttacks unit test，正如预期的那样，该方法报告有问题的签名没有覆盖整个文档.
可以阅读漏洞报告，将类似 iText 的行为称为“有限漏洞”，描述为
the same warning is raised in case
of an allowed modification (e.g., commenting) as well as in case of unallowed
modifications (attacks). Victims are unable to distinguish between both cases.
(Vulnerability Report - Attacks bypassing the signature validation in PDF - 2020-03-02)
在我看来，这个术语只有在所讨论的软件另有承诺时才有意义，即区分允许和不允许的更改并相应地报告。否则，它不是 漏洞，而是（希望有记录的）行为，而 漏洞 只是一个用户错误地期望不同的行为。
据我所知，iText 并未承诺分析增量更新中的变化（超出检索 LTV 信息）。 Bruno Lowagie 在他关于 PDF 数字签名的 iText 白皮书中写道，已经对开发路线图进行了分析；不过，据我所知，目前没有 (public) 可用的实现。
因此，我不会将 iText 的行为特别称为“有限漏洞”。
当然，如果某些软件基于 iText 进行签名验证，并且承诺根据上面解释的 iText 的验证结果，该软件确实至少具有有限的影子攻击漏洞，除非将它们报告为 不允许的更改。
很可能至少被报告为易受攻击的广泛使用的验证器，最重要的是 Adobe Acrobat Reader，将迅速尝试更正其代码以至少表明存在更改，甚至将它们报告为不允许。尽管如此，尝试并实施一些检查影子攻击准备迹象的方法可能是有意义的。在这方面，我目前正在研究一些 proofs-of-concepts。
我想知道 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 和 AcroFields.signatureCoversWholeDocument，报告 false pdf-insecurity 网站上提供的操纵示例，即它报告说在签名后添加了某种更改。
此外，在任何一种情况下，检索签名修订的方法，分别为 SignatureUtil.extractRevision 和 AcroFields.extractRevision，以及 return 这些示例的原始的、尚未操作的、签名的修订.
这种行为并不奇怪。影子攻击的描述清楚地表明，这些攻击是通过 增量更新（在漏洞中称为 增量保存 的方式应用于 PDF RUB 研究人员的报告）。 signatureCoversWholeDocument 方法现在准确检查文件在签名修订后是否没有内容；因此，它检测到影子攻击添加的增量更新。而 extractRevision 方法 return 将文件保存到相应有符号范围的末尾；因此，它不会 return 从影子攻击应用的增量更新中添加任何内容。
只是为了确保我检查了 iText 7 signatureCoversWholeDocument 输出的被操纵的示例文档，请参阅 this ShadowAttacks unit test，正如预期的那样，该方法报告有问题的签名没有覆盖整个文档.
可以阅读漏洞报告，将类似 iText 的行为称为“有限漏洞”，描述为
the same warning is raised in case of an allowed modification (e.g., commenting) as well as in case of unallowed modifications (attacks). Victims are unable to distinguish between both cases.
(Vulnerability Report - Attacks bypassing the signature validation in PDF - 2020-03-02)
在我看来，这个术语只有在所讨论的软件另有承诺时才有意义，即区分允许和不允许的更改并相应地报告。否则，它不是 漏洞，而是（希望有记录的）行为，而 漏洞 只是一个用户错误地期望不同的行为。
据我所知，iText 并未承诺分析增量更新中的变化（超出检索 LTV 信息）。 Bruno Lowagie 在他关于 PDF 数字签名的 iText 白皮书中写道，已经对开发路线图进行了分析；不过，据我所知，目前没有 (public) 可用的实现。
因此，我不会将 iText 的行为特别称为“有限漏洞”。
当然，如果某些软件基于 iText 进行签名验证，并且承诺根据上面解释的 iText 的验证结果，该软件确实至少具有有限的影子攻击漏洞，除非将它们报告为 不允许的更改。
很可能至少被报告为易受攻击的广泛使用的验证器，最重要的是 Adobe Acrobat Reader，将迅速尝试更正其代码以至少表明存在更改，甚至将它们报告为不允许。尽管如此，尝试并实施一些检查影子攻击准备迹象的方法可能是有意义的。在这方面，我目前正在研究一些 proofs-of-concepts。