LINUX.ORG.RU

Исправление критической уязвимости в Alpine Linux

 ,


0

0

В apk, стандартном пакетном менеджере Alpine Linux, были обнаружены несколько уязвимостей. Наиболее серьезная из них позволяет произвести исполнение вредоносного кода на машине пользователя.

Пакеты Alpine распространяются как файлы .apk, которые по сути являются архивами tar.gz. Когда пакетный менеджер apk получает пакеты, он распаковывает их содержимое в корневую директорию файловой системы до того, как проверяет их подлинность. Во время распаковки архива каждый файл получает суффикс .apk-new. После, когда apk обнаруживает несоответствие контрольных сумм, пакетный менеджер производит удаление всех файлов.

Благодаря особенностям удаления символических ссылок существует возможность сделать файл доступным и после «удаления» файлов пакетным менеджером.

Тем самым существует возможность записи произвольного файла в выбранную директорию. Используя директории вида /etc/apk/commit_hooks.d/, запись файла может приводить к исполнению кода на целевой системе.

Один из сценариев эксплуатации уязвимости (посредством атаки типа «человек посередине») возможен по той причине, что по умолчанию для доступа к репозиториям не используется TLS.

Стоит отметить, что эксплуатация уязвимости происходит незаметно для пользователя.

Пользователям рекомендуется незамедлительно обновиться до последней версии, доступной от команды Alpine.

>>> Исправление

>>> Подробности

Deleted

Проверено: Shaman007 ()
Последнее исправление: Deleted (всего исправлений: 3)
Ответ на: комментарий от AVL2

Если авторы с самого начала решают проблемы безопасности, то скорее всего, их детище умрет еще в младенчестве.

Неправда. Я все свои проекты начинаю с SSL и TLS. Без этого ниодно мое приложение к базе не приконектится. Даже если сеть банально огорожена. И это единственный правильный путь.

Deleted
()
Ответ на: комментарий от anonymous

В твоём переводе формулировка безапеляционная.

Да, ты прав, стоит поправить ОП.

Deleted
()
Ответ на: комментарий от Deleted

Эксплуатация уязвимости требует man-in-the-middle. Был бы TLS — описанный вариант эксплуатации не сработал бы. То есть TLS выступил бы как mitigation.

Ну какбе MitM можно провернуть и без вклинивания в трафик, достаточно поменять пакет на зеркале. Или у альпины нет зеркал? ))

Aceler ★★★★★
()
Ответ на: комментарий от Deleted

В этой гонке за секурностью любой полезный функционал называют «уязвимостями». Надо не систему урезать, а песочницы нормальные делать на такие случаи. Странно то, что ещё не возник проект такой универсальной песочницы, которую затем бы просто прикручивали во всех дистрибутивах. Как популярных так и малоизвестных.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

В бзд такое было еще когда я под стол ходил, кстати. Мне вот интересно, зачем ты прилез в мир линуксов, если все что ты хочешь процветает в бзде.

Deleted
()
Ответ на: комментарий от Deleted

Так уж получилось. *BSD я смотрел уже потом, осиливал только FreeBSD, и значимых преимуществ для себя не обнаруживал.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Надо не систему урезать, а песочницы нормальные делать на такие случаи.

chroot или как ты себе это представляешь?

anonymous
()
Ответ на: комментарий от anonymous

Можно и подобным образом, да. Весь вопрос в том, что будет доступно из этого chroot'а и как будет обрабатываться выход из этого chroot'а, включая перенос файлов на свои места.

saahriktu ★★★★★
()
Последнее исправление: saahriktu (всего исправлений: 1)
Ответ на: комментарий от saahriktu

Странно то, что ещё не возник проект такой универсальной песочницы, которую затем бы просто прикручивали во всех дистрибутивах.

Рассказать тебе про Flatpak?

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Так вопрос же не в изоляции софтин друг от друга и не в пакетных менеджерах как таковых. А в том, чтобы в систему приходили только конкретные файлы, если это критично. Можно хоть в chroot'е распаковать пакет, а при выходе сверить файлы со списком, и перенести только прописанные, а остальные удалить. Вопрос в том, чтобы это не велосипедить, а чтобы была конкретная реализация для тех же dpkg и rpm.

saahriktu ★★★★★
()
Ответ на: комментарий от jekader

«Контейнеры» основанные на цгрупс и неймспейс сточки зрения безопасности являются говном. Любые. Более того,их наличие провоцирует написание кривых программ. Если нужна безопасность то квм,бхайв,джайл(фряшная) к твоим услугам. Даже виртуалбокс безопаснее линукс-«контейнера».

anonymous
()
Ответ на: комментарий от Deleted

Наличие паразитария ака репозитария сейчас опасно само по себе. Васянский паразитарий может быть безопаснее.

anonymous
()
Ответ на: комментарий от Aceler

Флатпак говно,его авторы мудаки.

anonymous
()
Ответ на: комментарий от anonymous

«Контейнеры» основанные на цгрупс и неймспейс сточки зрения безопасности являются говном. Любые. Более того,их наличие провоцирует написание кривых программ. Если нужна безопасность то квм,бхайв,джайл(фряшная) к твоим услугам. Даже виртуалбокс безопаснее линукс-«контейнера».

Аргументы будут или сразу пройдёшь?

anonymous
()
Ответ на: комментарий от anonymous

Аргументы будут или сразу пройдёшь?

Да аргумент хотя бы в том, что в этих Докерах постоянно дыры находят.

Xroft ★★
()
Ответ на: комментарий от AVL2

Если авторы с самого начала решают проблемы безопасности, то скорее всего, их детище умрет еще в младенчестве.

Ты про Debian?

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от Deleted

Но сценарий менее вероятен (хотя черт его знает, на самом деле).

Как раз подмена пакета на сервере более вероятна чем вклинивание в трафик. Ибо слом одного зеркала равнозначен сотням, если не сотням тысяч, вклиниваний в трафик.

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от saahriktu

Дык. В бзде не преимущества. Там их отсутствие — ничего лишнего, простота до безобразия, как туалет в поезде. И однобайтовые кодировки, как ты любишь. Думаю, если поставишь NetBSD, за уши не оттащить будет.

Deleted
()

Решето! Хорошо, что я в своём alpine-бутстрапе стал делать так:

REPO='http://dl-cdn.alpinelinux.org/alpine/edge/main'
DM='curl -Sq --progress-bar -O'
$DM $REPO/x86_64/APKINDEX.tar.gz
tar xf APKINDEX.tar.gz APKINDEX
APKVER=$(grep -A1 -e 'P:apk-tools-static' APKINDEX | sed -n 's/V:\(.*\)/\1/p')
$DM $REPO/x86_64/apk-tools-static-$APKVER.apk
tar xf apk-tools-static-$APKVER.apk -C root sbin/apk.static 2>/dev/null
rm apk-tools-static-$APKVER.apk APKINDEX.tar.gz APKINDEX
Хотя, подсунуть мне скомпроментированный apk-tools таким образом тоже не особо сложно.

CYB3R ★★★★★
()
Ответ на: комментарий от commagray

Отдельный ноут с виндой справляется с этим еще лучше, че.

Любой менеджмент пакетов в обход пакетного менеджера - зло.

t184256 ★★★★★
()
Ответ на: комментарий от Aceler

Так в новости же про то, что установочные скрипты из пакета могут создавать произвольные файлы в системе. И это у авторов новости считается уязвимостью. Мол, для секурности должны приходить только изначально присутствующие в пакете файлы.

saahriktu ★★★★★
()
Ответ на: комментарий от Xroft

Да аргумент хотя бы в том, что в этих Докерах постоянно дыры находят.

А в квмах дыр не находят, гений.

anonymous
()
Ответ на: комментарий от saahriktu

И это у авторов новости считается уязвимостью.

Нет. Уязвимостью является сама возможность подменить пакет по ходу его доставки к пользователю, а дальше — пакетный менеджер в любом случае имеет право переписать любые файлы в системе.

Единственная разница — если установочные скрипты из пакета могут повредить файлы в системе, это ещё и не будет отражено в базе данных установленных файлов.

Aceler ★★★★★
()
Ответ на: комментарий от saahriktu

То есть для секруности надо не запретить создавать производльные файлы в системе, а сначала проверять пакет, а потом уже давать ему какие-то полномочия.

Aceler ★★★★★
()
Ответ на: комментарий от DNA_Seq

1 Можно подумать, в дебиане не было проблем с безопасностью. Их даже самих ломали.

2 можно подумать, дебиан образец роста и успеха.

AVL2 ★★★★★
()
Ответ на: комментарий от ne-vlezay

Но это никак не мешает собирать софт из сорцов.

CYB3R ★★★★★
()
Ответ на: комментарий от Deleted

зачем ты прилез в мир линуксов, если все что ты хочешь процветает в бзде.

Наверно потому, что в Линуксе поддержка железа лучше?

Odalist ★★★★★
()
Ответ на: комментарий от AVL2

1. SELinux это во многом заслуга Дебиана.
2. Это второй по древности дистрибутив и первый по распространенности если считать с бубунтой (которая есть переупакованный sid).

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от DNA_Seq

Сомнительно. Насколько я помню, они крутили rsbac. Selinux пришел из другого проекта.

Убунту sudo раздает по дефолту пользователям. Абсолютно антисекурный дистр.

AVL2 ★★★★★
()
Ответ на: комментарий от anonymous

Сраные цгруппы не делались для изоляции изначально,делались чтоб ресурсами рулить. В том же джайле запускается копия ведра, в л икс це нет. Эпичные дыры линуксовых «контейнеров» гугли сам.

anonymous
()
Ответ на: комментарий от anonymous

В квмах с бихайвами находят нетривиальные и часто сложноэксплатируемые дыры. Неймспейсы же дыра по умолчанию :-)

anonymous
()
Ответ на: комментарий от actionless

А мне нравится ходить пешком. В крайнем случае по городу езжу на автобусе...

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.