обнаружены уязвимости zlib

опять !? :(

"Шо, опять?" (c) мультик "Жил был пес"

ура товарищи

Мне здесь http://securityfocus.com/archive/1/313093 фраза понравилась:

""RK and I both considered just completely dropping the vulnerable codepaths; environments where zlib would have to fall back to these codepaths honestly just don't deserve breathing rights.""

Радует, что "" ... it works as it should on Linux==2.4.18/glibc>=2.2.5 ...""

Так взломать систему - очень охота посмотерть на настоящий оверфлоу

Так как взломать систему - очень охота посмотерть на настоящий оверфлоу?

Берешь кувалду , берешь сервер . Ломаешь . Делов то ..

мда это может только там 'Linux==2.4.18/glibc>=2.2.5' оно
и работает ?
if((kernel==2.2.22 || kernel==2.4.17) && glibc==2.2.3){not_work();}
:-)

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

проверял на RedHat 7.2 - работает за милую душу

http://securityfocus.com/archive/1/312919/2003-02-23/2003-03-01/2

Да, вдогонку - у меня ядро 2.4.19 я эта - anonymous (*) (2003-02-26 17:28:55.304)

да базар то не про прогу, она там уже лежит zlib.c
называется, а про версии ядра + какя glibc была.

2terry

Базар тогда вообще про патч. Более точная цитата:

The patch went through two revisions to get to this level of completeness; it works as it should on Linux==2.4.18/glibc>=2.2.5 but has not been tested on other platforms.

Вы на эксполойт посмотрите, а потом про версии ядра и либц рассуждайте.

Там классический вариант bufferoverflow в gzprintf() используется и запуск шелла. При чем тут версии??

(да, кстати, на glibc-2.2.4 тоже работает) :)

kernel 2.4.18 glibc 2.2.5 zlib 1.1.3 не работает. ;) а причина проста - OWL патч на ядро -> неисполняемый стэк. как бы недоброжелатели не ругали ASPLinux.... приятно когда прям "из коробки" вот так

да видел я тот код, но почему на том что перечислил
неработает а owl нету.

linux-2.4.19 glibc-2.3.1 работает

Что-то не понятно каков результат работы эксплоита Ну запустился шелл, ну и что? Все равно этот шелл с правами моими, а не рута... Объясните бестолковому...

у всех такое все новое.
а может он вообще только на 2.4.* работает :-)
хотя на 2.4.17 + glibc-2.2.3 не заработал.
а код я видел в asm, все правильно, но не работает.

"Что-то не понятно каков результат работы эксплоита Ну запустился шелл, ну и что? Все равно этот шелл с правами моими, а не рута... Объясните бестолковому..."

Ну вот как раз тебя в результате и взломали. Кому рут-то нужен? То есть, иногда и нужен бывает, сеть там загадить и вообще, но иногда достаточно вполне конкретного пользователя поиметь. Можно наконец, и подождать, когда рут напорется.

И че? Одна видимость...

[walrus@home Documents]$ emacs expl.c
[walrus@home Documents]$ ./expl
[>] exploiting...
[>] xret = 0xbffff630
sh-2.05b$ whoami
walrus
sh-2.05b$ cat /etc/shadow
cat: /etc/shadow: Permission denied
sh-2.05b$

2walrus (*) (2003-02-26 20:14:12.237):

а ты попробуй в sh выполнить rm -rf ~/. Результат будет, гарантирую!

>а ты попробуй в sh выполнить rm -rf ~/. Результат будет, гарантирую! Ну,а если я напишу на С прграммулину, которая будет удалять данные того юзера из-под которого запущена? #include <stdio.h> #include <errno.h> int main (int argc, char** argv) { if (argc>1) if (remove(argv[1])==0) { fprintf(stdout,"File '%s' removed successfully!\n",argv[1]); return 0; } else { fprintf(stderr,"Error %d. Cannot delete file '%s'!\n",errno,argv[1]); return 1; } else { fprintf(stderr,"Not enought parameters\n"); return 1; } }

touch test_file.txt chmod 400 test_file.txt -r-------- ./test_rm test_file.txt File 'test_file.txt' removed successfully! Для пущей важности создайте юзера, туда положите прогу и запустите из-под юзера и увидите что будет...

Ну и нафиг мне шелл запускать или какие-то баги в zlib искать??

2anonymous (*) (2003-02-26 23:16:24.952):

а вот от простого текстового файла, который ты решил просмотреть в своем любимом Emacs, ты ведь такой подлянки не ожидаешь. Честно говоря у меня на домашней машине только flash от стороннего производителя :-). А так все программы из дистрибутива. Это какая-никакая гарантия того, что они ничего у меня не портят намеренно... Т.е. чтобы что-либо у меня стереть мне нужно подсунуть именно exploit такого сорта. Или "правильный" mp3-шник. Иначе - никак. Поверьте - мне все равно, будут только мои файлы стерты или вся система целиком - workstation он и есть workstation. :-)

Так может кто-нить толоково объяснить в чем опасность данного эксплойта? Чем приведенный экзамлп отличается от execve("/bin/sh",... Где вред-то?

> Где вред-то?

Теоретически удаленный юзер может получить шелл через сетевой
сервис, который использует zlib. Например, через apache+mod_gzip. Только вот сделать это на практике где-то
на грани невозможного.

[user@vlad temp]$ gcc -o zlib zlib.c -lz [user@vlad temp]$ ./zlib [>] exploiting... [>] xret = 0xbffff650 sh-2.05b$ exit exit [user@vlad temp]$

Ядро 2.4.20, все остальное - с дистрибутива MAndrake 9.0 Не взломалась? Или что не так? Кстати, а на других операционках - Солярисе, например, эта штука будет работать?

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

2anonymous (*) (2003-02-27 10:20:40.973)
Условно говоря у тебя заломалось. В конце ты получил шелл.

[user@vlad temp]$ gcc -o zlib zlib.c -lz
[user@vlad temp]$ ./zlib
[>] exploiting...
[>] xret = 0xbffff650
sh-2.05b$ exit
exit
[user@vlad temp]$
[user@vlad temp]$

Ядро 2.4.20, все остальное - с дистрибутива MAndrake 9.0 Не взломалась? Или что не так? Кстати, а на других
операционках - Солярисе, например, эта штука будет работать?

Ну, насколько я понимаю, типа в результате ошибочной операции запустили shell :-))

А кто мешал его просто так запустить? Все равно тот setuid(0) setgid(0) не сработали. Под взломом следует понимать что-то типа повышение привилегий или возможность выполнять произвольный код там где раньше низзя было.

Если есть возможность запузырить такое дело через сеть и получить доступ туда, куда до сих пор доступа не было - это взлом.

Я не прав?

>Если есть возможность запузырить такое дело через сеть и получить доступ >туда, куда до сих пор доступа не было - это взлом.

так такая возможность существует, правда пока только теоретически

получение шелла из проги которая для этого не предназначена это уже 100% взлом. тем кто этого не понимает представьте что на проге висел setuid. в крайнем случае без всяких suid и вашего согласия можно потереть ваши файлы.

>получение шелла из проги которая для этого не предназначена А эксплоитный код, который шелл запустил(используя уязвимость), как в эту прогу попал?

Таким образом вот тот код на Сях, который я там выше написал или код, который просто стартонет шелл может попасть туда таким же образом и уязвимость тут будет вовсе ни при чем. И очень даже распрекраснейшим образом выполнит функцию remove(ююю) с привилегиями setuid, если таковы имеются у проги. Зачем для этого уязвимость?

Вот если б я, простой смертный юзер, написав прогу, которая исп-ет уязвимость, смогу получить доступ к чужим данным(типа /etc/shadow) - вот это уже хуже.

2anonymous (*) (2003-02-27 18:32:27.994)

грубое объяснение, для тупых:
ты используешь какую-нибудь прогу использующую zlib,
например архиватор, тебе по почте приходит "архив", ты его
открываешь, прога у тебя валится в корку и исполняет некий код
(например rm -rf /),
НЕУЖЕЛИ ЭТО ТАК СЛОЖНО ПОНЯТЬ ???

помните летом была найдена уязвимость в ghostview (во всех разновиднастях: gv,kghostview,ggv ......), ещё в bagtraq кто-то послал
псевдо pdf'ник, который открываешь в 'gv', 'gv' падает в корку и исполняет код, который
в /tmp создаёт (или удаляет, не помню уже) какие-то файлы,
так вот, вместо создания файлов там могло стоять 'rm -rf /'

Все проще - вот например где-то так. Целимся в некоторого конеретного юзера имеющего sudo. Задача - поймать его пароль. Из этого - получить рута.
Сперва делаем прожку которая внешне ведет себя как sudo, и из под себя ее вызывает чтобы делать настоящую работу. А то подозрительно будет - пароль спросила и ничего не сделала. Потом прячем ее куда-нить куда есть права на запись, изменяем пути чтобы путь к ней просматривался раньше каталога в котором настоящий sudo лежит. Это например как-раз-то и можно организовать используюя эту свежую дыру в zlib. Если все было сделано достаточно аккуратно - при первом же вызове ловится пароль и после этого машинка полностью под контролем. Если юзер не параноик - то скорее всего его пароль может подойти и в другие точки. Типа - пробили его workstation и с тем же паролем потом зашли на сервер и там без проблем получили рута через sudo.
Многие ли каждый раз проверяют вручную или специализированными инструментами неизменность своих переменных окружения, путей, всей файловой системы в конце концов ?
А таких вариантов просто море. Главное - наличие дыры и немного фантазии - хорошо проработать план атаки.
А говорите что не опасно ...
WBR, Burzumie

>например архиватор, тебе по почте приходит "архив", ты его >открываешь, прога у тебя валится в корку и исполняет некий код Вот это я еще могу понять. Есть возможность из-вне внедрить и выполнить код.

a sudo - не sudo - это уже вторично. Нужно, как минимум, сделать так, что эти пути сможно было подменить, т.е. получить управление в нужный момент и с нужными правами. А сделать это можно только подсунув юзеру что-то чтоб он выполнил это из-под себя.

Это не эксплойт, и ничего он не сломает. Это демонстрация дырки в конкретной библиотеке. Показано, что при типичном использовании этой библиотеки (в других программах - хоть браузер, хоть фтп-сервер) специально подобранные данные могут вызвать buffer overflow.

Поэтому рассуждения выше вызывают только смех. "И что мне делать с этим шеллом?". Ничего, раз не понял, откуда он взялся. Смех. Ха :)

> anonymous (*) (2003-02-28 00:45:57.362)

>Это не эксплойт, и ничего он не сломает. Это демонстрация дырки в конкретной библиотеке. Показано, что при типичном
>использовании этой библиотеки (в других программах - хоть браузер, хоть фтп-сервер) специально подобранные данные
>могут вызвать buffer overflow.

Значит, переполнение буфера можно вызвать? А этим переполнением можно воспользоваться, 
чтобы получить права root? Или это просто ошибка, которая кидает программу в core?

про переполнения буфера читать тут:
http://void.ru/content/1042

> Это не эксплойт, и ничего он не сломает.

Вот когда по Вам пройдутся шипастыми ботинками в виде какого-то вреда (получение root'а - это еще цветочки) и Вы даже не сможете понять откуда это произошло и что это такое вообще было, думаю, что Ваше мнение о $subj'е несколько изменится.
Мне довелось раз устранять последствия взлома с получением рута. Там было попроще и кряцкеру не пришлось долго фантазировать - bind-8.2.0 на какой-то очень старенькой RH запущеный под рутом и самое обычное переполнение буфера в нем. Был пойман в процессе сборки rootkit'а (это вообще чудом - просто повезло), тут же выяснен откуда, ему большой бан и "телега" его провайдеру. И потом больше суток на выяснение что же он еще успел натворить (про tripwire для той машинки просто забыли, поэтому пришлось в руки md5, компакт с дистром и очень много терпения).
Никому не пожелаю проходить через такое - весьма мрачное занятие.
WBR, Burzumie

2Burzumie >Типа - пробили его workstation и с тем же паролем потом зашли на сервер и там без проблем получили рута через sudo.

А можно поподробнее как "без проблем" получить права рута через sudo ?

Насколько я помню, sudo как раз нужно, чтобы работать без

прав рута.

Саныч

Саныч, что-то не пойму я тебя. То вроде бы нормальный мужик - здравые вещи говоришь, то вдруг несешь такую ересь, что читать стыдно. sudo позволяет выполнять действия от рута (и не только от рута), без знания пароля рута. Разницу между "пароль рута" и "права рута" видно хорошо? sudo умеет еще много чего, в том числе задавать некоторые ограничения на то, что, кому, с чьими правами можно делать.

2Саныч:
Я имел в виду - пароли и там и там одинаковые и на обоих есть sudo. Ну очень частая ситуация. Зная в одном месте - автоматически имеем доступ в остальные.
Burzumie

Вариант работы на
комп: SunBlade 100
архитектура: UltraSparc IIe
система: Aurora Linux 1.0 (на основе RedHat 7.3)
ядро: 2.4.20 (самосборка, Stack Overflow отключен)
glibc: glibc64-2.2.5-42
glibc-2.2.5-42

результат работы:
[alan@admin alan]$ ./zlib
[>] exploiting...
[>] xret = 0xeffff950
Bus error
[alan@admin alan]$

шелл какой был, такой и остался, ничего нового :-))

2sco-killer (*) (2003-02-28 19:43:40.997)

ты придурок или только притворяешься?
char shell[]=
"\x90\x90\x90\x90\x90\x90\x90\x90"
"\x31\xc0\x31\xdb\xb0\x17\xcd\x80"
"\xb0\x2e\xcd\x80\xeb\x15\x5b\x31"
"\xc0\x88\x43\x07\x89\x5b\x08\x89"
"\x43\x0c\x8d\x4b\x08\x31\xd2\xb0"
"\x0b\xcd\x80\xe8\xe6\xff\xff\xff"
"/bin/sh";

видишь этот код? ты думаешь он сможет исполнится на любой архитектуре?

2anonymous (*) (2003-02-28 21:54:48.061)
>ты придурок или только притворяешься?
А че ты обзываешься? Я что, не понимаю, что бинарный код работает только на определенной архитектуре? А ты вот, например или шуток не понимаешь, или смайлика не заметил, хотя из там аж 2 штуки :-))

ДрУги, я не понимаю, в чем замес? :-) Большинство проблем (большинство, но не все) решаются с помощью OWL или grsec, и никакие buffer/stack overflow не страшны. Если сервер мордой в интернет смотрит, то наложение таких патчей - первое, что надо сделать, IMHO.
P.S. Кстати, кто еще смог поставить Linux на SunBlade 100 и миксер нормально прикрутить, а то у этой Blяdи :-) dma отключать надо (ide=nodma), иначе IDE не работает, блин :-), и звук на максимальной громкости, стекла вылетают :-).
P.P.S. В форумах и доках по Linux&SPARC рекомендуют отключить встроенный динамик (физически), и усе :-).
P.P.P.S. На "боевых" Oracle серверах этот (да и другие) эксплоиты не работают, segfault, как обычно :-) (дистр VA 6.2.4, ядро 2.2.18-pre21+OWL, i386, конечно :-)).

> Большинство проблем (большинство, но не все) решаются с помощью OWL или grsec

А я знаю еще более чудное средство - решать проблему по законам
Шариатского суда. Написал кривую софтину, типа zlib, отрубили
правую руку... и т.д. ;)

2anonymous (*) (2003-03-03 04:24:14.684)
>Написал кривую софтину, типа zlib, отрубили
правую руку... и т.д. ;)
Ага, а он левой рукой (или ногой печатать будет) :-), или протез сделает, в общем процесс бесконечный :-)