5 лет, 160 комментариев и уязвимость устранена!

Всем привет!

Сегодня предлагаем вам очень увлекательную и захватывающую с первых минут статью.

Началось все с того, что Автор наткнулся на CVE-2022-1471, эксплуатация которой могла привести к RCE при использовании SnakeYAML.

И это удивило Автора, ведь в статье, которой на тот момент было уже 5 лет, упоминалась ровно та же самая уязвимость (только ей не был присвоен CVE), а SnakeYAML приводился в качестве одного из примеров.

Дальнейшее разбирательство немного шокировало: project maintainer перевел ее в значение «won’t fix», аргументируя это тем, что надо «просто использовать безопасный вариант реализации».

Да, он был прав. Но большинство людей не задумываются о том, как это правильно использовать. Им нужно реализовать десереализацию и только. Это подтверждается множеством примеров в интернете, где рекомендуется использовать небезопасный вариант.

С точки зрения Автора такой подход был в корне неверным. Ведь, если есть возможность, то лучше реализовать secure-by-default, а все остальное – на усмотрение пользователей.

Именно так и начался thread о том, что это надо исправить. На момент окончания обсуждения было порядка 160 комментариев.

Хорошая новость в том, что project maintainer все-таки согласился с тем, что можно сделать иначе и предоставил secure-by-default реализацию. Она попала в SnakeYAML 2.0.

В статье можно прочесть много интересных размышлений Автора:
🍭 О том, как используют средства анализа кода (иногда фокус смещается на создание новых правил для сканеров, а не на устранение существующих недостатков)
🍭 О том, что делать ИБ-исследователям, если они зашли в тупик при общении с «автором уязвимости»
🍭 О том, почему secure-by-default это важно и не только

Но это все лучше прочитать самим ☺️ Рекомендуем!