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

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

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

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

Весело

Новость так плохо написана, что пришлось сходить по ссылке. Там тоже не очень.

Решето уже было?))

чтобы каждый архиватор открывал только свои архивы

Для чего это нужно?

разделяй и властвуй, мухахахахаха

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

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

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

Весело

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

tl:tr

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

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

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

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

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

опасносте

при выполнении от привилегированного пользователя возможно заместить системные файлы или получить права 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 тоже дыра!

Vulnerable versions: GNU tar 1.14 to 1.29 (inclusive)

Патрик таскает 1.13 для менеджера пактетов

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

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

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

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

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

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

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

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

На 14.2 tar 1.29-й версии. Или ты про что?

У тебя их два, старый используется «пакетным менеджером».

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

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

Чё, там как раз всё понятно.

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

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

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

У тебя их два, старый используется «пакетным менеджером».

Эммм, пальцем ткните плиз

/sbin/installpkg:91:TAR=tar-1.13

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

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

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

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

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

http://mirror.yandex.ru/slackware/slackware-14.2/source/a/tar/

Шлакобилд сам прочитаешь, не маленький. На нужное место в pkgчегототам уже выше указали.

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

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

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

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

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

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 даже если вы думаете, что эти файлы не приказывали распаковывать.

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

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

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

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

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

Затем что архиватор от производителя лучше же.

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

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

Спасибо!

по идее 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

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

Ну вот

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

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

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

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

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

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

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

а я так понял, баг в том, что при определённых условиях пункт 1 не соблюдается

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

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