[ON] Уязвимость в пакетном менеджере APK, позволяющая удалённо выполнить код в Alpine Linux

[rssbot]

Исследователь безопасности Max Justicz, известный выявлением уязвимостей в репозиториях Packagist, NPM и RubyGems, опубликовал информацию о новой критической уязвимости в пакетном менеджере APK, применяемом в дистрибутиве Alpine Linux (используется по умолчанию для контейнеров Docker). Уязвимость несколько дней назад уже устранена в APK, а проект Alpine Linux выпустил обновление 3.8.1, в который включено данное исправление.

Атакующие, имеющие возможность совершить MITM-атаку или изменить пакеты на зеркале, могли подменить загружаемый пользователем apk-пакет и инициировать выполнение своего кода в системе c правами root. В Alpine Linux при доступе к штатным репозиториям по умолчанию не применяется TLS-шифрование канала связи, а используется только верификация целостности и источника пакета по цифровой подписи. К сожалению подобной проверки оказалось недостаточно, так как приводящая к уязвимости ошибка проявляется на стадии распаковки пакета, которая выполняется до проверки цифровой подписи.

Суть проблемы в том, что через манипуляцию с путями внутри пакета атакующие могут добиться распаковки непроверенного файла в системный каталог. Пакет apk представляет собой архив tar, при распаковке которого файлы поочерёдно извлекаются в корень с добавлением к имени окончания ".apk-new". В случае несовпадения проверочного хэша распакованные файлы удаляются. Проблема проявляется из-за ошибки при обработке символических ссылок.

Атакующий может создать в пакете ссылку с именем "link", указывающую, допустим, на файл "/etc/apk/commit_hooks.d/x". Данная ссылка будет распакована с временным именем "link.apk-new", но продолжит указывать на "/etc/apk/commit_hooks.d/x". Кроме символической ссылки в пакет можно поместить обычный файл тем же именем "link". Пакетный менеджер попытается сохранить его как "link.apk-new", но с данным именем уже присутствует символическая ссылка, что приведёт к созданию адресуемого через ссылку файла "/etc/apk/commit_hooks.d/x". Когда apk обнаружит несоответствие пакета проверочному хэшу, он удалит link.apk-new, но файл "/etc/apk/commit_hooks.d/x" останется в системе.

В итоге злоумышленник может переписать любой файл, в том числе разместить скрипт в каталоге /etc/apk/commit_hooks.d/, скрипты из которого вызываются перед завершением работы apk, что приведёт к выполнению кода до завершения обработки текущего пакета. Подобная особенность может использоваться для скрытия атаки. Изменив на лету память процесса apk через /proc/pid/mem, атакующий может добиться завершения apk всегда с нулевым кодом возврата, что позволяет успешно довести до конца процесс обновления или сборки Docker-контейнера и не вызвать подозрений.


Источник: https://www.opennet.ru/opennews/art.shtml?num=49273
(opennet.ru, основная лента)