LINUX.ORG.RU

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

 ,


0

0

В библиотеке glibc была обнаружена уязвимость (целочисленное переполнение).

Эта уязвимость присутствует в функции strfmon (форматирование числа как денежной суммы) и позволяет выполнить произвольный код с правами вызвавшего эту функцию приложения, либо аварийно завершить его работу.

Пример уязвимого кода на PHP (вызывает ошибку сегментирования):

php -r 'money_format("%.1073741821i",1);'
PHP-функция money_format реализована на базе strfmon, поэтому подвержена данной уязвимости. Таким образом, описанная уязвимость может быть использована даже удаленным злоумышленником.

Уязвимости подвержены все версии glibc вплоть до 2.10.1. В настоящее время информация о багфиксах отсутствует.

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

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


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

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

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

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

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

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

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

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

nnz ★★★★
() автор топика

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

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

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

k0l0b0k ★★
()

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

k0l0b0k ★★
()

Линупс опасносте!!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 ~ # 
vasily_pupkin ★★★★★
()

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

#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 ()
poige
()
Ответ на: комментарий от nnz

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

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

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

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

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

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

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

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

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

redgremlin ★★★★★
()

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

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

keinas
()

Подробности "от и до":
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?

gh0stwizard ★★★★★
()

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

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

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

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

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

anonymous
()

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

Woffice
()

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

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

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

anonymous
()

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

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

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

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

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

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

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

+1,

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

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

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

+ много

Bioreactor ★★★★★
()

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

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

[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

anonymous
()

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

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

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

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

legolegs ★★★★★
()

А вот в 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 в полный путь

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

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

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

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

anonymous
()

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

oc
()

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

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

Red_Lion
()

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

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

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

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

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

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

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

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

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

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