Прежде всего, iText не нужно исправлять ни в версиях 7.x, ни в версиях 5.5.x.
В любом случае метод, который проверяет, были ли внесены какие-либо изменения в подписанный PDF посредством инкрементных обновлений SignatureUtil.signatureCoversWholeDocument и AcroFields.signatureCoversWholeDocument соответственно сообщает false в случае манипуляций с примерами, представленными на сайте pdf-insecurity, то есть сообщает, что после подписания были добавлены какие-то изменения. 1007 * Более того, в любом случае метод, который извлекает подписанную ревизию, SignatureUtil.extractRevision и AcroFields.extractRevision соответственно, также возвращает исходную, еще не измененную подписанную ревизию для этих примеров.
Такое поведение неудивительно . В описании теневых атак четко указано, что эти атаки применяются к PDF-файлу посредством инкрементного обновления (в отчете об уязвимостях исследователи RUB называют инкрементное сохранение ). Метод signatureCoversWholeDocument теперь точно проверяет, нет ли в файле содержимого после подписанной ревизии; таким образом, он обнаруживает инкрементное обновление, добавленное теневыми атаками. А метод extractRevision возвращает файл до конца соответствующих диапазонов со знаком; таким образом, он не возвращает никаких добавлений из инкрементного обновления, примененного теневой атакой.
Просто чтобы убедиться, что я проверил вывод iText 7 signatureCoversWholeDocument для манипулируемых примеров документов, см. этот модуль ShadowAttacks test , и, как и ожидалось, метод сообщил, что данная подпись не покрывает весь документ.
Отчет об уязвимости можно прочитать, чтобы назвать поведение, подобное поведению iText, «ограниченной уязвимостью», описанной как
такое же предупреждение появляется в случае модификации разрешено (например, комментирование), а также в случае неразрешенных модификаций (атак). Жертвы не могут различить guish между обоими случаями.
( Отчет об уязвимости - Атаки в обход проверки подписи в PDF - 2020-03-02 )
На мой взгляд, эта терминология имеет смысл только в том случае, если программное обеспечение, о котором идет речь, обещало иное, то есть различать разрешенные и запрещенные изменения и сообщать об этом соответственно. В противном случае это не уязвимость , а (надеюсь, задокументированное) поведение , а уязвимость - только пользователь, который неверно ожидает другого поведения.
Насколько мне известно, iText не обещал анализировать изменения в дополнительных обновлениях (сверх получения информации LTV). Бруно Лоуаг ie в своем техническом документе iText по цифровым подписям для PDF-файлов написал, что анализ был включен в дорожную карту разработки; однако, насколько мне известно, в настоящее время его реализации (publi c) не существует.
Таким образом, я бы не назвал поведение iText, в частности, «ограниченной уязвимостью».
Конечно, если какое-то программное обеспечение основано на iText для проверки подписи, а обещает распознавать разрешенные и запрещенные изменения на основе результатов проверки iText, описанных выше, это программное обеспечение действительно имеет как минимум ограниченная уязвимость к теневым атакам, если они не сообщаются как запрещенные изменения .
Весьма вероятно, что по крайней мере широко используемые валидаторы, признанные уязвимыми, в первую очередь Adobe Acrobat Reader, быстро попытаются исправить свой код, чтобы хотя бы указать на наличие изменений или даже сообщить о них как о запрещенных. Тем не менее, имеет смысл попробовать реализовать некоторые методы, проверяющие признаки подготовки к теневым атакам. В настоящее время я экспериментирую с некоторыми доказательствами концепций в этом отношении.