В JavaScript-библиотеке xml-crypto, используемой в качестве зависимости у 402 проектов и загружаемой из каталога NPM около миллиона раз каждую неделю, выявлена уязвимость (CVE-2024-32962), которой присвоен максимальный уровень опасности (10 из 10). Библиотека предоставляет функции для шифрования и верификации по цифровой подписи XML-документов. Уязвимость даёт возможность атакующему заверить фиктивный документ, который в конфигурации по умолчанию будет успешно верифицирован библиотекой, несмотря на то, что он подписан не тем ключом, что указан для проверки подписей. Проблема проявляется начина с версии xml-crypto 4.0.0 и без лишней огласки устранена в январском выпуске 6.0.0...Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61112
ай хорошо, молодцы малпы, показательно
Миллион дыр в неделю, только вдумайтесь
>Миллион дыр в неделюнет, миллион коммитов в корявых CI, которые выкачивают каждый раз эту нишевую либу по-новой.
не думаю, что на планете много проектов где на жабоскрипте проверяют подписи в XMLях
> Проблема проявляется начина с версии xml-crypto 4.0.0 и без лишней огласки устранена в январском выпуске 6.0.0.Плюсовики не отстают https://github.com/PowerDNS/pdns/issues/12234
Тихонько прикрыли гигадырень, и решили не упоминать об этом в release notes https://doc.powerdns.com/authoritative/changelog/4.9.html
Все ругали это в C и C++, но видимо скоро вернемся к тому от чего ушли - к подключению зависимостей папочками в проекте. Иначе проблема безопасности публичных репозиториев по-видимому не решаема.
Простите, и как бы это помогло от уязвимости в описываемом случае?Скорее наоборот, остались бы несколько сотен проектов, авторам которых было недосуг скачивать версию с прикрытой дырой себе в папочку™.
А она и не решаема. Неужели ли непонятно, что каждая зависимость это даже не то чтобы дыра, там лишь бы оно вообще работало. Безопасность там вообще аут оф скоуп. Это вообще отдельный жанр.
Судя по коммиту, там даже и не сразу поняли, что это уязвимость). Коммит отправлен в январе, а отчёт о дыре отправлен пару дней назад.
Там и переменные называются максимально похоже, подозреваю, что автор просто перепутал. Хотя там тесты есть и они вроде как работали. ЧТо тестировали тогда?
>Библиотека предоставляет функции для шифрования и верификации по цифровой подписи XML-документов.Лишь бы gpg/ssh не использовать.
Багофича ) для выявления тех, кто код не тестирует ))) и тех, кто тестирует только успешную валидацию, а неуспешную не проверяет))
Если код компилируется значит работает (tm)
Т.е. по мнению сообщество xz это злонамеренный троян. А тут просто чудовищная ошибка? И у этой ошибки нет ни имени ни адреса? И вообще никто не виноват.
Сравнение с xz было б более уместно, если здесь тоже был удаленный доступ к системе или похожее.
> Проблема проявляется начина с версии xml-crypto 4.0.0 и без лишней огласки устранена в январском выпуске 6.0.0.Хорошо, хоть только сейчас огласили, выждали время.
А разработчики, проектные менеджеры и руководство компаний часто пренебрегает обновлениями компонентов. А это нужно делать регулярно.
> загружаемой из каталога NPMПишите заголовки правильно - не "в библиотеке xml-crypto", а "в javascript-библиотеке xml-crypto", чтобы сразу было понятно, из-под какой коровы удобрение.
И чтоб два раза не вставать - вот это умиляет (https://www.npmjs.com/package/xml-crypto):
> A pre requisite it to have openssl installed and its /bin to be on the system pathНу, то есть, вы поняли - оно не либу дёргает за API, а бинарник запускает.