Опасная уязвимость в glibc

Раз-троение личности, мало ли :)

>Интересно, а можно ли завалить Апач на хостинге с помощью этой уязвимости? Там ведь mod_php как либа идет и при сегфолте должен вылететь и апач.

На своём собственном хостинге валить себя глупо, а на мультиязерном виртуальном хостинге Апач не используется. Ну упадёт у тебя один php-fcgi процесс, ну перезапустит его спулер. Делов-то...

>Раз-троение личности, мало ли :)

А! Ну, это - другой разговор! :)

> молча закрывается, ничего не выводя
ulimit -c unlimited

Я не знаю что за системы вы юзаете, но у меня ничего не отвалилось, хотя подождать пришлось:
[root@spider ~]# time php -r 'money_format("%.1073741821i",1);'

real 1m10.456s
user 0m17.477s
sys 0m13.203s
[root@spider ~]#

>и позволяет выполнить произвольный код с правами вызвавшего эту функцию приложения

Ужас-то какой.

>Где же наш любимый Ulrich Drepper?

Он должен объяснить что это не баг - надо просто пользоваться функцией правильно, те у кого не падает пользуюстя ею правильно, а у кого падает - вызывают ее с неправильными аргументами?

>Он должен объяснить что это не баг - надо просто пользоваться функцией правильно, те у кого не падает пользуюстя ею правильно, а у кого падает - вызывают ее с неправильными аргументами?

Нет оно должно работать правильно. Не жрать память и ресурсы.

$ php -r 'money_format("%.1073741821i",1);'
Ошибка сегментирования
$ pacman -Q glibc
glibc 2.10.1-4

>Уайтспэйс прозрачнее.

Уайтспейс как раз-таки не идеален.
Например, обсуждаемая уязвимость. Ведь glibc написан именно на whitespace (весь видимый код там для отвода глаз) ;)

> Нет оно должно работать правильно. Не жрать память и ресурсы.
Очевидно, ты некомпетентен. Функция работает в точности так, как описано в отраслевых стандартах. Заплати Дрепперу, если хочешь подробных объяснений. И, самое главное, STOP REOPENING!

>>Уайтспэйс прозрачнее.

>Уайтспейс как раз-таки не идеален.

Но он - прозрачен. Это самый прозрачный из популярных языков.

>Но он - прозрачен. Это самый прозрачный из популярных языков.

Не спорю.

В Arch:

$ gcc -o gl gl.h
$ chmod +x gl
$ ./gl
bash: ./gl: не могу запустить бинарный файл

Файл gl.h:
#include <monetary.h>
#include <stdio.h>

int main(int argc, char **argv)
{
char buf[1024];
if (0 < strfmon(buf, sizeof(buf), "%.1073741821i",1) ) {
printf("conversion result: %s", buf);
}
return (0);
}

Сентябрь дыр на моём ЛОРе!!! О_л!!!

ТОЛСТО же!!!

>$ gcc -o gl gl.h
$ chmod +x gl
$ ./gl
bash: ./gl: не могу запустить бинарный файл

Куда мир катиться?!

Имхо, если у вас это валит систему, выкиньте свой дистр! )

извЕните:

$gcc -o gl gl.c
$ ./gl
Ошибка сегментирования

Занятно , в Debian Sid нет сегфолтов на примерах для c и php.

ну и где патчи ? могли бы уже и сделать что-нибудь ;)

> php -r 'money_format("%.1073741821i",1);'

Вешает систему намертво :(

notebook ~ # equery l glibc
* Searching for glibc ...
[IP-] [ ~] sys-libs/glibc-2.10.1 (2.2)

notebook ~ # uname -a
Linux notebook 2.6.31-gentoo #3 SMP Fri Sep 18 22:27:02 MSD 2009 x86_64 AMD Turion(tm) 64 X2 Mobile Technology TL-60 AuthenticAMD GNU/Linux

>> молча закрывается, ничего не выводя
>ulimit -c unlimited

Анахуа? :)

zitzy@DESKTOP:~$ cat bug.c
#include <monetary.h>
#include <stdio.h>

int main(int argc, char **argv)
{
char buf[1024];
if (0 < strfmon(buf, sizeof(buf), "%.1073741821i",1) ) {
printf("conversion result: %s", buf);
}

printf("ы?\n");
return (0);
}
zitzy@DESKTOP:~$ ./bug
ы?

> Анахуа? :)
Очевидно, чтобы закрывался, что-то выводя.

crypton ~ # php -r 'money_format("%.1073741821i",1);' Ошибка сегментирования crypton ~ # uname -a Linux crypton 2.6.30-gentoo-r6 #1 SMP Fri Sep 4 20:46:50 Local time zone must be set--see zic m i686 Intel(R) Pentium(R) 4 CPU 2.80GHz GenuineIntel GNU/Linux crypton ~ # emerge -pv glibc [ebuild R ] sys-libs/glibc-2.10.1 USE="gd glibc-omitfp nls -debug (-hardened) (-multilib) -profile (-selinux) -vanilla" 0 kB

Ни PHP, ни прога на сях ничего не валят. Но и не работают. GLIBC 2.9_p20081201-r2

>+1, просто висит и думает. Имхо, проблема, наверное, не в глибце, а в х86, ибо на amd64 не пашет :)

Debian Sid AMD64. Выжрало весь проц.

glibc-2.9_p20081201-r2 сжирает память и проц

А почему белочка полиняла?

Это летний вариант.

*NIX опасносте?! :( и патчей еще нет?

>#include <monetary.h>
>#include <stdio.h>

>int main(int argc, char **argv)
>{
> char buf[1024];

> if (0 < strfmon(buf, sizeof(buf), "%.1073741821i",(double) 1) ) {
> printf("conversion result: %s", buf);
> }

> return 0;
>}


$ ./a.out
Segmentation fault

> Интересно, а можно ли завалить Апач на хостинге с помощью этой уязвимости? Там ведь mod_php как либа идет и при сегфолте должен вылететь и апач.

lihttpd так завалить точно нельзя, а апач не проверял, у меня его не стоит

А я нашёл ещё одну, гораздо более страшную уязвимость в glibc! Вот сматрите:

#include <stdio.h>

int main(int argc, char **argv)
{
	printf(argv[1], 123);
	return 0;
}

$ ./a.out %d
123
[2009.09.21 12:02:56] ivan@ivan-laptop ~/temp/printf
$ ./a.out %s
Ошибка сегментирования

> РЕШЕТО! что и требовалось доказать - в GNU world не могут даже нормальную glibc написать.

Половина правды здесь есть, но на мой взгляд всё портит заплесневелый Си и его брат-уродец Сипипи - языки настолько опасные и кривые, что даже средней руки профессионалу нужно быть крайне внимательным, чтобы не на факапить. Куда выгоднее смотрится применение D, но это чёртовы миллионы строк кода, которые надо переписывать. Опять же, нет никакого желания толкать дальше труп пингвина - и несъедобно, и пользы никакой.

>>В переводе на Си это будет так?

>>#include <monetary.h> >>#include <stdio.h>

>> int main(int argc, char **argv) >> { >> char buf[1024]; >> if (0 < strfmon(buf, sizeof(buf), "%.1073741821i",1) ) { >> printf("conversion result: %s", buf); >> } >> return (0); >> }

>>Данный код на моём компе (x86_64) просто зависает:

>У меня segfault.

Это нормальное повидение защищённой системы. Процесс вызвавший переполнения должна быть убит.

Сие зависит от архитектуры проца и обций сборки и линковки самой проги (CFLAGS="-fPIE -fstack-protector-all" LDFLAGS="-Wl,-z,now -Wl,-z,relro") для защиты от вчех подобных багов.

Segmentation fault

>Половина правды здесь есть, но на мой взгляд всё портит заплесневелый Си и его брат-уродец Сипипи - языки настолько опасные и кривые, что даже средней руки профессионалу нужно быть крайне внимательным, чтобы не на факапить. Куда выгоднее смотрится применение D, но это чёртовы миллионы строк кода, которые надо переписывать. Опять же, нет никакого желания толкать дальше труп пингвина - и несъедобно, и пользы никакой.

О, вон оно, оказывается, как. Давайте еще все перепишем на .net. И пользы много, и съедобнее, небось, да?

Ну где же патч?

Такое ощущение, что у всех крыша поехала, хотя были ссылки на редхатовский баг с объяснением. Никакой серьюрити уязвимости тут нет! И функция действительно работает так, как должна "по отраслевым стандартам". Вот будет еще один "stop reopening bug", дураки будут над Деппером потешаться, а он над вами, что думать не пытаетесь..

В этом абсолютно идиотском вызове вы просто требуете выдать вам число с точностью 1073741821 после запятой, заполняя все знаки. То же самое можно и в printf и тд сделать, здесь только одно отличие - память за вас в glibc должна выделяться. А оно как бы не очень рассчитано на такие выделения внутри. На x86 из-за архитектурных ограничений оно мгновенно падает на выделении такого числа байт (я не знаю, из какой области оно выделяет память, но видимо это не обычный malloc, код лень смотреть). На x86_64 такое выделение как бы прокатывает, но жутко тормозит. Потому что если какой-то идиот САМ попросил внутреннюю функцию glibc выдать ему саллоцированную строку на 1073741821 байт, то он ССЗБ. Какое, на хрен, переполнение? Ну плохо, что glibc не проверяет сверхбольшие аллокации не выдает ошибку, ну исправили это уже.. К самой ситуации отношения не имеет.