В утилите GNU tar выявлена (http://seclists.org/fulldisclosure/2016/Oct/96) уязвимость (CVE-2016-6321 (https://security-tracker.debian.org/tracker/CVE-2016-6321)), позволяющая при раскрытии архива осуществить запись за пределы целевого каталога, заданного в командной строке. Например, запустив распаковку одного файла, может быть переписан другой файл или осуществлено раскрытие файлов в обход заданным маскам и исключениям.Подготовив специальным образом архив атакующий может добиться записи сторонних файлов при распаковке, например, подменить ключ входа по SSH или сценарии автозапуска bash при распаковке в домашнюю директорию. В случае если архив распаковывается пользователем root возможно организовать перезапись системных файлов и получить полномочия суперпользователя (например, переписав crontab). Интересно, что информация о проблеме была отправлена сопровождающему GNU tar ещё в марте, но он не посчитал указанную проблему уязвимостью, поэтому проблема на момент публикации эксплоита остаётся неисправленной.
Уязвимость связана с некорректным вырезанием символов ".." из путей в архиве - при наличии ".." перед распаковкой осуществляется удаление части пути, предшествующей "..", но проверка соответствия маскам осуществляется по исходному варианту. Например, подготовив архив с файлом "etc/motd/../etc/shadow", атакующий может переписать etc/shadow в случае попытки раскрытия файла etc/motd (tar удалит "etc/motd/../", но оставит "etc/shadow", который будет обработан относительно корня целевой директории, несмотря на то, что явно инициирована распаковка только etc/motd). Условием успешного проведения атаки является необходимость соответствия части присутствующего в архиве пути с задаваемой при распаковке целевой директорией, т.е. часть до символов ".." должна совпадать с заданной для распаковки директорией или соответствовать заданной через опцию "--wildcards" маске распаковки. Данное ограничение сужает область применения атаки системами с предсказуемыми путями распаковки, например, приложениями распаковывающими архивы в заранее известные директории.
URL: http://seclists.org/fulldisclosure/2016/Oct/96
Новость: http://www.opennet.ru/opennews/art.shtml?num=45383
Необходимо срочно включить tar в systemd! GNU не справляется.
sandbox?
Сначала emacs и qt, фреймворки должны быть интегрированы.
> Сначала emacs и qt, фреймворки должны быть интегрированы.LibreOffice в качестве pid(1) должен быть хорош!!
> LibreOffice в качестве pid(1) должен быть хорош!!Ты там потише, а то нокия уже доперла однажды до прелоада браузера сразу после старта системы. Здорово же если браузер вываливается на экран сразу как ты клацнул ярлык. А то что он трскал цать мегов даже если ты им не пользовался... ннннну... красота^W п0нт^W UX требует жертв, да?
О, ну хоть по этому поводу нет отдельного сайта. Пока что.
> информация о проблеме была отправлена сопровождающему GNU tar ещё в марте, но он не посчитал указанную проблему уязвимостью, поэтому проблема на момент публикации эксплоита остаётся неисправленной.Этому весьма уважаемому и несомненно высоко компетентному человеку запретить кодить пожизненно.
> Этому весьма уважаемому и несомненно высоко компетентному человеку запретить кодить пожизненно.Может не помочь. Проекту с числом авторов больше одного мэйнтейнеру совершенно не обязательно писать код для внесения багов.
Ты бы хоть разобрался в этой "уязвимости", манагер.
"Попробуйте сменить мишку или компьютер" (c)
http://www.linux.org.ru/news/multimedia/12957216?cid=12972509
>> информация о проблеме была отправлена сопровождающему GNU tar ещё в марте, но он не посчитал указанную проблему уязвимостью, поэтому проблема на момент публикации эксплоита остаётся неисправленной.
> Этому весьма уважаемому и несомненно высоко компетентному человеку запретить кодить пожизненно.Решение есть! Возьми его на работу -- и сразу начинай говорить, чего да как делать.
А busybox?
> позволяющая при раскрытии архива осуществить запись за пределы целевого каталога, заданного в командной строкеЭта "уязвимость" НЕ ПОЗВОЛЯЕТ осуществить запись за пределы целевого каталога. Она позволяет при частичной распаковке архива извлечь файлы, не указанные в командной строке. Например, если вы извлекаете каталог "foo" из архива в /home, то может быть перезаписан не только /home/foo, но и /home/bar, хотя пользователь этого не заказывал. Но за пределы /home (например, в /etc) ничего записать не получится.
Если это и можно считать уязвимостью, то лишь минорной.
Выходит в тексте новости враньё.
Открытого вранья нет, так как под "целевого каталога, заданного в командной строке" в команде "tar -C / -xvf archive.tar etc/motd" можно понимать как "/" так и "etc". Так что скорее небольшая манипуляция с целью сделать из представителя семейства Muscidae представителя семейства Elephantidae.
Условный пример:
Вы открываете архив и смотрите до второго уровня что в нём только файлы конкретных настроек:
superService/conf/....
superService/startup/....
superService/startup/....естественно вы по все каталоги "до конца дерева" не просматриваете.
А при распаковке в /etc там оказывается
superService/conf/default/../../../systemservice.confкак то так :)
что-то подсказывает, что автор прав - смотреть надо что делаешь.
rm -rf / usr
достали уже... rm -rf / не работает, т.к. по дефолту "--preserve-root do not remove '/' (default)"
В FreeBSD работает. Достали уже школьники.
Что работает? Ты удали все, а потом посмотри что осталось. Я могу даже дать тебе доступ, чтобы ты потренировался ядро у FreeBSD снести. При определенной настройке попытки твои не увенчаются успехом.
Давай, терминал уже открыл.
Ок. Отправил логин/пароль на почту.
Снес
теперь посмотри что осталось.
>что-то подсказывает, что автор прав - смотреть надо что делаешь.Прав или не прав, а судя по их "This type of scenario has been successfully exploited in the real world to gain a remote code execution as root in different environments" скрипты с такими вот командами действительно имеют место быть.
И вообще авторы tar поступили странно… Почему именно весь кусок перед '..'? Почему не после? Или просто выкидывать один '..' или заменять на какой-нибудь '$$'…
Я нашел куда более страшную "уязвимость" в tar. Если сказать ему просто распаковать специально подготовленный архив целиком, что делается в подавляющем большинстве случаев, то он это сделает! В результате атакующий может добиться записи файлов в сторонние каталоги при распаковке, например, подменить ключ входа по SSH или сценарии автозапуска bash. В случае если архив распаковывается пользователем root возможно организовать перезапись системных файлов и получить полномочия суперпользователя (например, переписав crontab). В общем всё то же самое, повлияет на тех же самых балбесов, что распаковывают чужие tar архивы от рута в корень или от пользователя напрямую в хомяк, только с операцией на порядки более частой.
> (например, переписав crontab). В общем всё то же самое, повлияет на
> тех же самых балбесов, что распаковывают чужие tar архивы от рута
> в корень или от пользователя напрямую в хомяк, только с операцией
> на порядки более частой.А зачем это делать? в корень-то
Как зачем? Чтобы "уязвимость" заработала. Ты бы еще спросил зачем это делать с чужими архивами."Здравствуйте, я молдавский вирус. По причине ужасной бедности моего создателя и низкого уровня развития технологий в нашей стране я не способен причинить какой-либо вред Вашему компьютеру. Поэтому очень прошу Вас, пожалуйста, сами сотрите какой-нибудь важный для Вас файл, а потом разошлите меня по почте другим адресатам. Заранее благодарю за понимание и сотрудничество."
Что несешь? Ты каждый раз, скачивая CMS (вордпрес, джумла) ты отрываешь архив, и изучаешь, нет ли там ".."?
он не распаковывает в корень
вин
> вордпрес и джумлаахаха, ну да, каждый раз, а потом извлекаю по 1 элементу из корня архива в корень системы, а потом по-одному переношу куда надо, или даже нет, прям корень шарю по хттп, мне ведь нравится тупить отделяя системные файлы от прочено говна, иногда прям /usr/lib распаковываю, ведь это так весело.
> Например, подготовив архив с файлом "etc/motd/../etc/shadow", атакующий может переписать /etc/shadowМожет переписать etc/shadow
но никак не /etc/shadow
Вот именно. Если пройти по ссылке, то в этом примере для срабатывания "уязвимости" используется следующая команда:
# tar -C / -xvf archive.tar etc/motd
> Вот именно. Если пройти по ссылке, то в этом примере для срабатывания
> "уязвимости" используется следующая команда:
> # tar -C / -xvf archive.tar etc/motdТ.е. по вашему нормально, что вы запускайте "cat tar-poc.tar | tar xv etc/motd" чтобы переписать один файл etc/motd, а он вместо этого переписывает вам совсем другой файл etc/shadow?
Без проблем, просто нужно скомбинировать
etc/motd/../etc/shadow
etc/motd/../../etc/shadow
etc/motd/../../../etc/shadow
etc/motd/../../../../etc/shadow
и т.д.
Вот мы и переписали /etc/shadow
оно так не работает
>просто нужно скомбинироватьвеликий комбинатор обосрался
> Может переписать etc/shadowОтносительно /. В том то и уязвимость, что при указании tar раскрывать в /etc он раскроет не в /etc/etc/shadow, а в /etc/shadow.
> что при указании tar раскрывать в /etcЭто 3.14здец!
Как гвоздик в розетку сувать - если в ноль (или тапки сухие) то и не 2.71бнет.
Как уже говорили смотреть надо, что распаковываешь.
И еще зря / убрается из путей при созданеии архива :)
по-моему даже на уровень moderate не тянет
Хрень какая-то. Кто из под рута распаковывает архивы? Фото на доску почета.
С остальным справится SELinux и abrt.
Вбздуны
Вообще-то распаковка из под рута это норма. А ты бекап распаковываешь от пользователя, а потом для каждого файла рутом правишь владельца? А для распаковки архивов с содержимым для самого рута создаешь отдельного пользователя, распаковываешь под ним, а потом переносишь в /root?
Проблема не в том, из под какого пользователя, а в том, куда именно распаковывать.
плюсую!!!
Проблема не "куда именно распаковывать", а "что именно распаковывать".
А какое может быть решение проблемы "в имени файла есть /../"?
например
etc/motd/../etc/shadow
etc/motd/../vmlinuzКуда такие файлы должны быть распакованы?
В файл указанный в маске для распаковки?
Что делать с масками --wildcards "m*"
?
Считать имя повреждённым и вообще не распаковывать такие файлы?
Воу, воу, осади мысли-скакуны.Тот кто распаковывает указывает что он хочет распаковать в маске для распаковки.
То что программа делает с именами файлов _перед_ распаковкой это распаковывающему совсем неинтересно.Если короче - маска применяется _после_ всех манипуляций с именем файла.
это не уязвимость, - это фича! ;)