The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

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

14.09.2018 18:28

Исследователь безопасности 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-контейнера и не вызвать подозрений.

  1. Главная ссылка к новости (https://justi.cz/security/2018...)
  2. OpenNews: Уязвимость, позволяющая удалённо выполнить код на сервере PHP-репозитория Packagist
  3. OpenNews: Уязвимость в Apache CouchDB, позволяющая совершить атаку на реестр пакетов NPM
  4. OpenNews: В RubyGems выявлена удалённо эксплуатируемая уязвимость
  5. OpenNews: Root-уязвимость из-за некорректных настроек в пакете nginx для Debian и Ubuntu
  6. OpenNews: Уязвимость в пакетном менеджере APT, проявляющаяся в конфигурациях с зеркалами
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/49273-apt
Ключевые слова: apt, alpine
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (25) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 20:38, 14/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Пользуюсь voidlinux, но рад, что дружественный проект исправил уязвимость.
     
     
  • 2.2, Оффтоп (?), 20:50, 14/09/2018 [^] [^^] [^^^] [ответить]  
  • –3 +/
    кстати про voidlinux и уязвимости. Они до сих пор не переехали с гитхаба?
     
     
  • 3.3, Аноним (1), 20:55, 14/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Да что-то они не в тренде.
     

  • 1.5, freehck (ok), 21:23, 14/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Выполнить любой код в Alpine? Ммм, значит дистр, ориентированный на безопасность. :)
     
     
  • 2.6, Аноним (6), 22:14, 14/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    интересно, как в этом плане обстоят дела у apt/dnf/zypper
     
     
  • 3.16, DerRoteBaron (ok), 23:30, 15/09/2018 [^] [^^] [^^^] [ответить]  
  • –1 +/
    У dnf/zypper в их родной среде должно быть меньше проблем, так как rpm это не матрёшка из tgz/txz, а специфичный формат, содержащий подпись в заголовке и, если я правильно понял, подписывающей cpio-payload, а не файлики внутри по одному.
    И собственно инвалидность подписи проверяется ещё до начала транзакции
     
     
  • 4.25, freehck (ok), 07:46, 01/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > У dnf/zypper в их родной среде должно быть меньше проблем, так как
    > rpm это не матрёшка из tgz/txz, а специфичный формат, содержащий подпись
    > в заголовке и, если я правильно понял, подписывающей cpio-payload, а не
    > файлики внутри по одному.

    Ещё бы тебе уяснить, что на подписи отдельных пакетов, если таковые вообще имеются, никто и никогда не смотрит, потому что достаточно один раз проверить подпись репозитория, а дальше уже просто сверять хеш пакета с проверенным. И это общий подход для дистров, что для deb, что для rpm.

     
  • 3.24, Аноним (-), 18:42, 27/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Лучше. За годы развития их все-таки в целом отучили от детских болезней. Тот же apt+dpkg вообще ничего распаковывать не будет если подпись или хэш кривые. До этого дело просто не дойдет.
     
  • 3.26, EHLO (?), 10:29, 01/10/2018 [^] [^^] [^^^] [ответить]  
  • +/
    >интересно, как в этом плане обстоят дела у apt/dnf/zypper

    предсказуемо хуже. Поиск по базе CVE в помощь.

     

  • 1.7, ALex_hha (ok), 23:42, 14/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –5 +/
    > используется по умолчанию для контейнеров Docker

    Кем используется?

     
     
  • 2.11, anonimous (?), 08:57, 15/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Всеми используется
     
     
  • 3.17, ALex_hha (ok), 02:29, 16/09/2018 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Есть статистика или лишь перднуть?
     
     
  • 4.20, anonimous (?), 19:56, 16/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Перднуть. А разве не так?
     
  • 4.22, your mom (?), 21:58, 16/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    в след раз почитай про сабж прежде, чем начнешь быковать.
     

  • 1.8, Аноним (8), 00:38, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Очень интересует, что употребляют люди, которые придумывают такие атаки, и можно ли эти вещества где-то купить без рецепта?
     
     
  • 2.13, test_test (?), 09:21, 15/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ничего они не употребляют. Просто используют метод научного тыка, курят мануалы и комбинируют мелкие уязвимости в большие. Просто чуваки оч умные.
     
     
  • 3.14, trunk (?), 16:48, 15/09/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    А говоришь - не употребляют. И тут же - курят... маны. )
     

  • 1.9, Аноним (9), 04:25, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > проект Alpine Linux выпустил обновление 3.8.1, в который включено данное исправление.

    ...которое загружается тем самым пакетным менеджером?

     
  • 1.10, Аноним (10), 05:12, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    rm -rf /* init скрипт запихнуть.
     
     
  • 2.12, anonimous (?), 08:59, 15/09/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Хорошая атака ничего не ломает и никак себя не выдает.
     

  • 1.15, нонима (?), 23:04, 15/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >> ошибка проявляется на стадии распаковки пакета, которая выполняется до проверки цифровой подписи

    Л - логика. Распаковать и только потом проверять.

     
  • 1.18, Аноним (18), 09:55, 16/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает, проверяет КС и часть, которая на самом последнем этапе помещает прошедшие проверку файлы в ФС ОС. Первая часть должна перед началом работы сменить владельца процесса на какого-нибудь совсем бесправного пользователя.
     
     
  • 2.19, Аноним (19), 11:12, 16/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    > Это значит, что пакетные менеджеры следует разбивать на часть, которая принимает, распаковывает,
    > проверяет КС и часть, которая на самом последнем этапе помещает прошедшие
    > проверку файлы в ФС ОС. Первая часть должна перед началом работы
    > сменить владельца процесса на какого-нибудь совсем бесправного пользователя.

    А почему нельзя сделать, чтобы системное дерево и файлы принадлежало пользователю типа rootfs?
    Чтобы никто кроме rootfs и root не мог изменить файлы.

     
     
  • 3.21, your mom (?), 21:51, 16/09/2018 [^] [^^] [^^^] [ответить]  
  • +/
    они и так руту принадлежат
     

  • 1.23, sposob (?), 03:03, 17/09/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    ...стукнули буквы с квэрти, это самая ужасная новость за пол ночи...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру