LINUX.ORG.RU

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива

 , ,

Уязвимость в Rust-библиотеках для формата TAR, приводящая к распаковке файлов из вложенного архива

0

7

В написанной на языке Rust библиотеке async-tar, предоставляющей функции для чтения и записи tar-архивов, выявлена уязвимость (CVE-2025-62518, кодовое имя TARmageddon), позволяющая при распаковке специально оформленного tar-архива не только извлечь размещённые в нём файлы, но и файлы, содержащиеся во вложенном tar-архиве. Уязвимость может быть использована для обхода систем верификации архивов и распаковки файлов, для которых не выполнялась проверка.

Уязвимость также проявляется в форках библиотеки async-tar, таких как tokio-tar, krata-tokio-tar и astral-tokio-tar, а также в утилитах на их основе, например, в пакетном менеджере uv, развиваемом в качестве высокопроизводительной замены «pip» для проектов на языке Python. Из популярных проектов, использующих уязвимые библиотеки, также отмечаются инструментарий testcontainers для запуска docker-контейнеров и WebAssembly runtime wasmCloud. В репозитории crates.is за последние 90 дней библиотека async-tar насчитывает 1.3 млн загрузок, tokio-tar - 2.2 млн, testcontainers - 2.9 млн.

Уязвимость вызвана некорректным выбором позиции при разборе разных значений размера в заголовках ustar и PAX. В tar-архивах в формате PAX для каждого файла внутри архива указываются два заголовка - классический ustar и расширенный PAX. Проблема вызвана тем, что уязвимые библиотеки при распаковке файлов вместо вычисления смещения на основе размера из расширенного заголовка PAX, брали размер из устаревшего заголовка ustar. При нулевом значении размера в заголовке ustar, идущее за ним содержимое файла обрабатывалось как корректный блок TAR-заголовков для следующего файла.

Для совершения атаки достаточно создать TAR-архив, в котором в ustar-заголовке указан нулевой размер, а в заголовке для формата PAX актуальный размер, из-за чего содержимое файла с другим tar-архивом будет обработано как часть основного архива. Пример кода для создания подобных архивов размещён на GitHub. Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5. Для остальных библиотек исправления пока не опубликованы, но для astral-tokio-tar, async-tar и krata-tokio-tar отдельно подготовлены патчи.

Уязвимости в библиотеках присвоен уровень опасности 8.1 из 10, так как проблема может использоваться для перезаписи распаковываемых файлов (в уязвимых реализациях будут распакованы не те файлы, что были видны в архиве). При этом уязвимость в пакетном менеджере uv отмечена как неопасная, так как если атакующий может влиять на содержимое исходного архива, нет смысла усложнять атаку и эксплуатировать уязвимость через вложенный архив, когда можно добиться выполнения кода через сборочные сценарии в основном архиве.

Выявившие уязвимость исследователи предложили несколько гипотетических сценариев атак, позволяющих обойти проверки безопасности и добиться выполнения кода через замену файлов конфигурации или вмешательство в сборочный процесс. Подразумевается, что присланный архив сможет пройти автоматизированную проверку сканером безопасности и ручной аудит, в ходе которого проверяющий не обратит внимание на странный вложенный архив с другими файлами, после чего при распаковке при помощи Rust-библиотек из архива будет извлечено иное содержимое, чем ожидалось.

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI, который пройдёт проверку на основе анализа содержимого основного архива, содержащего легитимный файл pyproject.toml. При обработке данного пакета при помощи утилиты uv легитимный pyproject.toml будет заменён на вредоносный вариант из вложенного архива, содержащий команды, которые будут выполнены при сборке на компьютере разработчика или в системе непрерывной интеграции. Аналогично, можно организовать перезапись файлов контейнера при извлечении образа контейнера при помощи инструментария testcontainers.

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

★★★★★

Проверено: dataman ()
Последнее исправление: dataman (всего исправлений: 2)

Уязвимость устранена в выпусках tokio-tar 0.5.6 и uv 0.9.5

Оперативно. Там, где в других языках ради безопасности приходится делать закат солнца вручную, в Rust достаточно убрать парочку unsafe-блоков.

kaldeon
()

классический ustar и расширенный PAX

А как на таких архивах ведут себя реализации tar, поддерживающие только «классику»?

unC0Rr ★★★★★
()

Пример кода для создания подобных архивов размещён на GitHub.

На C++, неожиданно. :)

dataman ★★★★★
()

Сегодня праздник у дефчат - сегодня будут танцы? :-)))

vtVitus ★★★★★
()

вот это поворот… оказывается-то уязвимости еще и в логике могут присутствовать.

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

$ ./repro_generator

PAX Size Override Bug Reproduction Generator
============================================

Generating compact PAX bug reproduction...
Added PAX header with: 13 size=1024

Added blob.bin with octal size=0 but PAX size=1024
Blob content starts with fake tar header for 'INNER_FILE'
Added marker.txt - correct readers should extract this
Saved pax_bug_compact.tar (5632 bytes)

Expected behavior:
- Correct readers: normal.txt -> blob.bin (1024 bytes) -> marker.txt
- Buggy readers:   normal.txt -> blob.bin (0 bytes) -> INNER_FILE (from blob content) -> marker.txt
The bug occurs when readers:
1. Process PAX 'x' header but don't apply size override
2. See blob.bin with octal size=0
3. Skip 0 bytes instead of PAX-specified 1024 bytes
4. Land in blob.bin content and mistake it for next tar header
5. Start extracting 'INNER_FILE' instead of 'marker.txt'

GNU tar 1.35 и bsdtar из libarchive-git справились:

$ ls -l
total 1364
-rw-r--r-- 1 dataman dataman    1024 Feb 14  2009 blob.bin
-rw-rw-r-- 1 dataman dataman   30285 Oct 22 11:10 build.ninja
-rw-rw-r-- 1 dataman dataman   15071 Oct 22 11:10 CMakeCache.txt
drwxrwxr-x 1 dataman dataman     336 Oct 22 11:10 CMakeFiles
-rw-rw-r-- 1 dataman dataman    2217 Oct 22 11:10 cmake_install.cmake
-rw-r--r-- 1 dataman dataman       7 Feb 14  2009 marker.txt
-rw-r--r-- 1 dataman dataman       6 Feb 14  2009 normal.txt
drwxrwxr-x 1 dataman dataman       8 Oct 22 11:10 output
-rw-rw-r-- 1 dataman dataman    5632 Oct 22 11:23 pax_bug_compact.tar
-rwxrwxr-x 1 dataman dataman   35848 Oct 22 11:10 repro_generator
drwxrwxr-x 1 dataman dataman      70 Oct 22 11:13 rust-target
-rwxrwxr-x 2 dataman dataman 1174048 Oct 22 11:13 tar-bug-detector
-rwxrwxr-x 1 dataman dataman   56040 Oct 22 11:10 tarwalk
-rwxrwxr-x 1 dataman dataman   51688 Oct 22 11:10 tarwalk_bad
dataman ★★★★★
()

Видимо, на Rust не принято писать unit тесты.

Вот смотрю я на код Rust и вижу бесконечные .unwrap() Это так задумано? Такой крутой дизайн языка. Даже if err != nil красивее смотрится.

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

Так и задумано. Если ты забудешь написать красивый if err != nil, твой код будет работать над кривым значением res. Растовский unwrap забыть поставить не получится.

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

Я за ней не уследил
В том моя вина
Но как классно
Переписана она!

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

Видимо, на Rust не принято писать unit тесты.

В расте есть встроенная система юнит тестов, весьма продвинутая. И вообще test driven подход к разработке весьма распространён.

Вот смотрю я на код Rust и вижу бесконечные .unwrap() Это так задумано?

Да. Это механизм обработки ошибок такой.

Даже if err != nil красивее смотрится.

Да никто тебе не мешает писать if err..., только здоровые на голову люди этим не занимаются.

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

Вот смотрю я на код Rust и вижу бесконечные .unwrap() Это так задумано?

unwrap ассертит, что значение не может быть ошибкой. В твоём языке же принято писать ассерты?

quantum-troll ★★★★★
()

Например, атакующий может загрузить модифицированный архив в репозиторий PyPI

Стоп-стоп… т.е. кто-то угонит аккаунт мейнтейнера, и заложит там какую-то перезапись? Но он может любой бэкдор туда положить, или я чего-то не понял? Таки при чём тут раст?

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

Таки при чём тут раст?

«В любой непонятной ситуации смотри где-то поблизости Rust»

alash
()

ну вообще ничего прям ужас-ужасного не случилось.

всё самое плохое с растом уже случилось: это поросячий синтаксис.

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

в коде на rust не может быть уязвимостей

C чего ты это взял?

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

Безопасность, говорили они…

Они говорили «безопаснее за счёт исключения таких-то классов ошибок при таких-то условиях» - но ты как обычно слушал жопой и ей же думал.

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

безопаснее за счёт исключения таких-то классов ошибок при таких-то условиях

Евангелисты часто не конкретезируют, какие именно классы ошибок rust позволяет избежать

mittorn ★★★★★
()

Солнце перешло из созвездия льва в созвездие рака, вслед за неделей ИИ астрологи объявили неделю раста на лорчике

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

Уязвимость в том, что растишки не умеют работать с tar. До этого они уже обделались с dd. Что ещё там всплывет, когда раст станет чуть более популярным, чем кобол?

bread
()

Тут многие поциенты совсем не вдупляют разницы между безопасностью и безопасным управлением памятью. А тут вот ещё, из раст документации:

Rust’s memory safety guarantees make it difficult, but not impossible, to accidentally create memory that is never cleaned up (known as a memory leak). Preventing memory leaks entirely is not one of Rust’s guarantees, meaning memory leaks are memory safe in Rust.

О как! Но кому эта документация нахрен нужна, когда можно услышать звон, не понять где он, но экстраполировать на далеко идущие выводы.

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

растоманы обычно не очень внимательно читают документацию. Несколько лет назад одни приколисты пихнули DefaultHash в сетевой протокол, а о том, что это siphash13 с добавленным \xff в конец строк можно узнать только долго изучая сорцы стдлибы, разгребая макросы и абстракции

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

не конкретезируют, какие именно классы ошибок rust позволяет избежать

Какой ужас! Неужели… неужели для понимания технических деталей придётся читать документацию?! Кошмар!

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

но ведь волшебный раст должен магически сделать всё безопасным! Какая ещё документация???

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

растоманы обычно не очень внимательно читают документацию

А причём здесь Rust? Разрабы в целом не особо внимательно читают документацию. И админы. И мейнтейнеры. Чтение вообще это не настолько распространённый навык как кажется. Это не специфично для какого бы то ни было языка или технологии.

zabbal ★★★★★
()
Р Е Ш Е Т О
Е Ш Е Т О Р
Ш Е Т О Р Е
Е Т О Р Е Ш
Т О Р Е Ш Е
О Р Е Ш Е Т
Smacker ★★★★★
()

Внезапно оказалось, что безопасность, это не только написать на Rust, но ещё и подумать над архитектурой, да? Ну кто бы мог подумать.

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

Это ты слышал звон, чудик. При чем тут утечки памяти?

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

Не понимая, что все остальные ошибки работы с памятью - это тоже ошибки в логике. Что вся эта лабуда про «раст защищает от целых классов ошибок» - это полная чушь, потому что никаких «классов ошибок» в принципе нет.

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

потому что никаких «классов ошибок» в принципе нет.

Да. И ошибок никаких нет. Тебя тоже вылечат.

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

<trolling mode> Просто на плюсах принято включать голову. А сторонники Rust вероятно считают, что язык всё сделает за них…</trolling mode>

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

А причём здесь Rust? Разрабы в целом не особо внимательно читают документацию. И админы. И мейнтейнеры. Чтение вообще это не настолько распространённый навык как кажется. Это не специфично для какого бы то ни было языка или технологии.

Надеюсь хирурги читают… Извините…

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

Это адепты волшебного раста себе выдумали и пихают после этого раст повсюду

Лор-inception: хейтеры раста выдумали, что адепты волшебного раста себе выдумали и пихают после этого раст повсюду

inb4: растфанбои выдумали, что хейтеры раста выдумали, что адепты волшебного раста себе выдумали и пихают после этого раст повсюду

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

Ну я бы не стал так категорично говорить хоть и считаю Раст высером нракомнов. Дело в другом.

То что они в dd обосрались это результат желания хоть тушкой хоть чучелком свой гомосексуализм протащить в массы. Они поэтому и начали переписывать то, что легче всего, не требует переделки и при этом массово используется. Это желание навязать свою ориентацию. Активизм по сути. Поэтому они и дальше будут переписывать то что уже работает

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

Вариант то, что люди просто учаться и поэтому они взяли писать что-то простое ты не рассматриваешь? Или вариант то, что у людей есть просто хобби и они пишут что-то незамысловатое просто для удовольствия ты тоже не рассматриваешь?

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

Есть разница между просто существующим хобби проектом и штуками, которые пихают в ядро или которыми заменяют coreutils. Если эта библиотека используется каким-нибудь uutils для работы с таром - то это уже не совсем хобби. К тому же cargo позволяет буквально в одну строчку какую-нибудь хобби-библиотеку притащитть в уже не вовсем хобби проект

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

Так я не говорю конкретно про uutils, как и в сообщении, на которое я отвечал, человек которому я отвечал, жалуется что все переписывают на раст, причем то, что переписать проще всего.

Я вот сейчас на раст пишу аналог htop и fetch, для того чтобы попробовать язык и узнать лично. Или я все таки занимаюсь пропагандой раста и «пытаюсь протащить гомосексуализм в массы» (цитата из сообщения на которое я отвечал)

А по поводу библиотек: https://www.opennet.ru/opennews/art.shtml?num=63437

По словам Ника, библиотека libxml2 не обладает уровнем качества, пригодным для использования в браузерах и операционных системах. Тем не менее, крупные компании, такие как Apple, Google и Microsoft, стали использовать libxml2 в своих операционных системах и продуктах. Подобные действия названы безответственными, а проводимая работа - попытками избавиться от симптомов, а не устранить причину проблем. По мнению Ника для проекта было бы лучше, если упомянутые компании прекратили использование libxml2.

snake266 ★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.