LINUX.ORG.RU

Небезопасная работа с временными файлами во многих opensource программах


0

0

Уязвимости этого типа обнаружены в следующих продуктах: gettext, GNU Ghostscript, glibc, GNU Groff, gzip, MIT kerberos5 , lvm, mysql, netatalk, openssl, perl, libc6, postgresql. Большинство ошибок было обнаружено в течение последних месяцев, но обновления от вендоров появились только сейчас.

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

★★★☆

Проверено: Demetrio ()

И вы еще спрашиваете причем тут SELinux...

macavity
()

вот и доверяй этому ПО теперь

anonymous
()

вообще-то про сабж я уже ОЧЕНЬ давно читал:)))

anonymous
()

Ну а что ищё можно ожидать от программ, которые “пишутся чиста для фан”? О какой безопасности будет думать студент, ковыряя в носу и торопясь сваять очередную нетленку на Цы и стать новым Линусом Торвальдсом?

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

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

anonymous
()

>обновления от вендоров появились только сейчас.

Какой наглый 3,14здеж! Сложно, что-ли посмотреть на даты уведомлений от вендоров? Например, Trustix Secure Linux (про других не знаю - не пользуюсь) обновил ВСЕ перечисленные уязвимости еще 29/09/04.

Шуму то сколько! То, что M$ полтора месяца не закрывал опубликованную и эксплуатируемую дырку IFRAME, ни кого не возбуждает. Мол, так и должно быть, все - пучком.

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

>Я смотрю, в fedora только у nettalk проблема.

Так апдейт был 4 дня назад...

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

> народ обьясните а в чём тут небезопасность то?
в зависимости от прав доступа и (не)везения:
- стирание произвольного\некоторого файла
- редактирование произвольного\некоторого файла
- чтение произвольного\некоторого файла

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

Посмотрел дырки в gzexe(ака дырка в gzip) и в catchsegv(ака дырка в glibc). Неприятно, конечно (тем, что злой хацкер может испортить системные файлы), но я до этого и не знал о существовании таких программулин. :)

Murr ★★
()
Ответ на: ... от x97Rang

что-то я не врубаюсь, что помешало ПОСЛЕ ПЕРВОЙ ЖЕ найденной temp file race кондишны делать все дистрибы с вот такими tmp

tmp/root tmp/user1 tmp/user325

с соответствующими пермишнами

?!

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

Блин...

cd /

chmod -R +rwx

rm -rf

или еще баще:

iptables -F INPUT

iptables -F OUTPUT

iptables -X

iptables -p ACCEPT

iptables save

И потом заявить - да ваш Линукс - сплошная дыра!

anonymous
()

По идее, это всё можно одним модулем пофиксить - завести файловую систему "ptempfs", например, в которой пользователи - невладельцы каталогов будут видить в каталогах только те файлы, которые они создали и на которые имеют права на чтение-запись. По аналогии с сессионными временными таблицами в MSSQL.

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

> То, что M$ полтора месяца не закрывал опубликованную и эксплуатируемую дырку IFRAME

Бля, а debploit вообще ПОЛГОДА работал :)

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

Некоторые проги (например MC) перестают нормально работать

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

да, это не из той песни ... :) пора отдохнуть .. я уж про выполнение думаю

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

Я вот под HP-UX ещё в 98 году писал, а про Ваши temp file race кондишны только в этом году в инете прочитал. Я всё-таки считаю, что для /tmp надо делать специальную файловую систему с поддержкой сеансовых временных файлов. Это очень полезно будет, IMHO. Почему так сразу не сделали?

MS
()

Вот поэтому и есть такая весчь как pam_mktemp.

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

Софт написанный нормальными людьми в /tmp не пишет. Он пишет в $TMP. Параноики могут удалить /tmp и вставить TMP=$HOME/tmp в /etc/environment

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

А зачем нужен /tmp???
Вот, вот, друзья, подумайте над этим.

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

Непонятно зачем перечислять одно и тоже два раза.

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

>(не)Уважаемый - рекомендую ознакомиться с вопросом прежде, чем п*рдеть >в лужу.

сколько злости! И гланое в таком матерном слове и всего одна звездочка. Вас рвет при слове "пердеть"?

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

> Софт написанный нормальными людьми в /tmp не пишет. Он пишет в $TMP. Параноики могут удалить /tmp и вставить TMP=$HOME/tmp в /etc/environment

Не TMP, а TMPDIR.

Кроме того, создавать директорию для временных файлов в $HOME глупо, ее можно создать в /tmp.

faustus
()

Задрало уже, ей богу. У этой messageпомойки есть технически грамотный модератор? Месяц назад была та же пьянка - один деятель не понял про что речь, другой криво перевёл, третий опубликовал.

Для тех, до кого медленно доходит: инсталляционные скрипты в пакетах некоторых дистрибутивов написаны не очень чисто. Потому как никто не парился. Некоторые производители "trusted" дистрибутивов вместо игр на тему специальных прав на инсталляцию решили почистить гнутый софт на предмет make install. Если Вы *УЖЕ* поставили пакет и Вас за этот краткий миг никто не откракал - то и нефиг дёргаться, всё что можно уже отвалилось.

Мать... Ну хоть подумать немного: нафига к примеру gettext при работе временный файл?! Другое дело это что у него вообще в 35 Mb исходниках понаписано. Но никаких tmp файлов в самом gettext (.../gettext-runtime/src нет :-)

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

Debian - слишком обобщенное понятие, в каком дистрибутиве glibc глючит? Potato? :) Или может woody с r3, Sarge или Sid? И что, патчик еще не выпустили? Странно как-то. Неужели в debian glibc настолько другой, чем в fedore core? :)

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

>Для тех, до кого медленно доходит: инсталляционные скрипты в пакетах некоторых дистрибутивов написаны не очень чисто

Походу gzexe и catchsegv - это инсталляционные скрипты.
Вот чего не знал - того не знал. :)

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

Из перечисленных багов Debian affected only by three: lvm, postgres и gzip. Причем пофиксены они 29 октября, 3 и 8 ноября. Уже месяц...

Оперативная новость, сказать нечего 8)))))

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

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

Дырка тама была в том, что скрипт не проверял "а вдруг мне в /tmp какая-то зараза уже подложила тот файл, который я только что хотел создать".

Для влезания в дырку на машине должно быть локальный пользователь, который сидючи в засаде (видимо за соседним терминалом) смотрит на то, как первый запускает gzexe и именно в тот момент порожает подставные файлы в /tmp чтобы первый обломился...

Из исходного сообщения создаётся впечатление, что есть страшная дыра в gzip, теперь файлами .gz пользоваться нельзя, всё пропало, срочно переходим на bzip etc. Такая полуправда хуже чем явная ложь.

Это примерно то же самое, что сказать: "Это под окном ваш голодный грязненький орущий ребёночек бегал? Нету больше у вас голодного грязненьгкого орущего ребёночка". И забыть сказать, что на самом деле ребёночка просто забесплатно помыли, накормили и успокоили.

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

>anonymous (*) (09.12.2004 18:08:15)

Я читал, в чем проблема с catchsegv и gzexe.

Меня смутило утверждение о том, что дескать проблема имеет место только с _установкой_ glibc и gzip, поэтому я и прокомментировал соотв. утверждение.

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

... ну, подсматривать из-за плеча - это труднее, чем
написать прогу, которая пореверяет наличие gzexe
(что-то типа 'ps -ef | grep gzexe > qq.txt') ...

Марк

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