LINUX.ORG.RU

Уязвимость в архиваторе GNU tar

 ,


1

1

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

Таким образом, можно заменить ключи SSH или файл .bashrc, а при выполнении от привилегированного пользователя возможно заместить системные файлы или получить права root.

>>> Технические детали атаки

>>> Багтрекер Debian



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

Если даже в tar такое, то через мою связку ВинРАР-ВинЗИП-7ЗИП мою винду уже раз сто поимели!

// Я знаю что все они знают архивы друг друга. Я просто при установке галочками так сделал, чтобы каждый архиватор открывал только свои архивы.

ZenitharChampion ★★★★★
()

Ладно там openssh, а ведь старый tar много где есть, ведь от tar такого не ждешь.

GNU tar maintainer didn't consider this to be an issue. As a result mitigation in upstream GNU tar appears unlikely

Весело

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

Если в России не приходится платить ни за что из этого, Тоталь Коммандер не удобнее ли был бы?

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

GNU tar maintainer didn't consider this to be an issue. As a result mitigation in upstream GNU tar appears unlikely

Весело

Но ведь он прав по сути. То, что tar может перезаписывать любые файлы в целевой директории при распаковке - это нормальное поведение для архиватора. С тем же успехом можно считать возможность исполнения любого кода уязвимостью в /bin/sh.

Deleted
()

при выполнении от привилегированного пользователя возможно ... получить права root

У них там написано, что они, мол, запускают tar от рута и таким образом умудряются переписать системные файлы. Серьёзно? Вот эта новости, никогда бы не подумал что так можна.

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

Суть-то в чем? Там ".." в пути, или пути абсолютные?

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

Deleted
()

опасносте

при выполнении от привилегированного пользователя возможно заместить системные файлы или получить права root

/root # id
uid=0(root) gid=0(root) groups=0(root)
/root # su -
/root # id
uid=0(root) gid=0(root) groups=0(root)

В su тоже дыра!

anonymous
()

На уязвимость не тянет. Просто имена с .. внутри будут распкованы всегда, что неприятно, но требуется большая кривизна рук, чтобы это превратить в уязвимость...

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

но при этом именно в ту директорию, которую указал юзер.

Прикол как раз в том, что указанный юзером каталог (каталог из архива, да) может не совпадать с тем, куда всё действительно распаковалось.

AX ★★★★★
()

ждем rpm'ок с исправлениями, а то не хочется иметь такую дыру на домашнем убунту: меня сестра постоянно пытается взломать со своего блэкберри

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

меня сестра постоянно пытается взломать со своего блэкберри

это не похоже на правду

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

Т.е. галочками сделал, чтобы вместо одной дырявой программы было три?

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

Рукожопость (или жопорукость) Патрика спасает шлаку от уязвимости! :)

Пацаны все мигрируем на Слаку! Это система для истинных хакеров.

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

Я считаю, нет (может, не прав).

Если я прошу tar -f archive.tar -x the-dir-from-archive, то я ожидаю, что он создаст/запишет/перезапишет ./the-dir-from-archive.

А не кучу всего другого в ./.

sasha1024
()

Это и недавная история с ядром это всё карма Поттеринга, разумеется.

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

Но зачем? Не удобнее ли использовать 1 программу для всех форматов архивов? Просто интересно узнать, в чём конкретный профит.

Вроде как по скорости они все примерно одинаковые, а степень сжатия в первую очередь зависит от формата.

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

по идее tar не должен подниматься выше корневого каталога, указанного в -C или выше текущей директории.

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

Спасибо, вот уж даже и не догадывался о таком. Постепенно узнаёшь всё больше неочевидных нюансов об используемой системе.

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

Там 2 tar-а.
1ый - «бытовой» - для пользователя действительно 1.29 (или там какая последняя будет) - /bin/tar
2ый - «служебный» - для пакетного менеджера, 1.13 - /bin/tar-1.13
Последней пользуется пакетный менеджер для всех операций с пакетами, ибо в версиях по новее сломали совместимость форматов. Как следствие, пакетный менеджер поперхался на пакетах созданыз криворучками. В итоге Патри возит 2 версии. Т.е. кривым пакетом не сломаешь систему.
Но никто не мешает пользоваться 1.13 в быту тоже ;)

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

ибо в версиях по новее сломали совместимость форматов

Иди шлакбилд читать.

anonymous
()

в видне95 была уязвимость: с шареной папки можно было cd .. и получишь доступ к диске ц. лол

anonymous
()

Описание неправильное.

The attacker can create a crafted tar archive that, if extracted by the victim, replaces files and directories the victim has access to in the target directory, regardless of the path name(s) specified on the command line.

Мой перевод:

Атакующий может создать особый архив tar, который, будучи распакованным жертвой, заменяет файлы и директории в директории назначения (если есть доступ) не принимая во внимание имя/имена, заданные в командной строке.

Т.е. если вы достаёте избранные файлы из архива прямо в ~ или / то вас подстерегают сюрпризы в ~/.bashrc и /etc/cron.d/daily даже если вы думаете, что эти файлы не приказывали распаковывать.

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

Затем что в России мне не приходится платить ни за что из этого

Зачем нужен WinZIP все равно не очень понятно, т.к. у оффтопика же есть встроенная поддержка «сжатых папок»...

X-Pilot ★★★★★
()

а при выполнении от привилегированного пользователя возможно ... получить права root.

А это вообще удар ниже пояса.

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

Неизвестный архив может распаковаться неизвестно куда? Вот это решето!

Скорее, «телепорт» ;)

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

по идее tar не должен подниматься выше корневого каталога, указанного в -C или выше текущей директории.

Он и не поднимается. tar -xf archive.tar -C /home/user/unpacked etc/sudoers.d Предполагается что в результате будет /home/user/unpacked/etc/sudoers.d/<файлы из ахрива>

Но если в archive.tar будут имена etc/sudoers.d/../shadow etc/sudoers.d/../etc/shadow

то получим распакованные /home/user/unpacked/shadow /home/user/unpacked/etc/shadow

anonymous
()

Ну вот

Стоило только PVS-Studio появиться под линукс, так сразу пошло добро.

anonymous
()

Караул! В tar'е уязвимость! Бегу ставить WinRAR!

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

Аналогично. А вот если можно добавить побольше .. и в конечном итоге перезаписать, например, /etc/shadow(при условии что распаковываем далеко не в /) - вот тогда да, дыра!

Pinkbyte ★★★★★
()

По ходу дела тут народ ваще не понял о чём баг.

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

2. Заменить таким образом системные файлы можно только по большой дурости.

То есть это баг, но безопасноть тут притянута за уши, скорее неудобство в использовании.

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

нет, он соблюдается.

Просто если ты хочешь распаковать файлы *.txt а там еще файл ../wtf.bin, он тоже распакуется (../ будет выпилено). То есть просто такие файлы не подпадают под фильтр.

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