Несколько новых уязвимостей в локальных программах и библиотеках:

-  В системной Си-библиотеке Glibc найдена уязвимость (http://secunia.com/advisories/43492/), вызванная ошибкой в реализации функции "fnmatch() ([http://www.opennet.me/man.shtml?topic=fnmatch)", которая может привести к повреждению стека при передаче на вход функции специально оформленного имени файла. Уязвимости подвержены  использующие данную функцию приложения, например, браузер Chrome (http://code.google.com/p/chromium/issues/detail?id=48733). Проблема устранена в Glibc 2.12.2;
-  В распределенной файловой системе OpenAFS 1.4.14 (http://www.openafs.org/) устранено две уязвимости (http://secunia.com/advisories/43407/): первая позволяет инициировать крах Linux-ядра, а вторая потенциально дает возможность организовать выполнение кода злоумышленника на RX-сервере, при отправке специально закодированных ASN1-значений;

-  В модуле аутентификации libpam-pgsql найдена уязвимость (http://secunia.com/advisories/43471/)...

URL:
Новость: http://www.opennet.me/opennews/art.shtml?num=29818

• Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,Demo, 10:25 , 07-Мрт-11
  • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,Аноним, 11:16 , 07-Мрт-11
• Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,Аноним, 10:27 , 07-Мрт-11
• Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,crypt, 10:57 , 07-Мрт-11
  • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,iZEN, 13:47 , 07-Мрт-11
    • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,dimss, 14:01 , 07-Мрт-11
      • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,коксюзер, 14:42 , 07-Мрт-11
        • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,dimss, 18:12 , 07-Мрт-11
          • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,коксюзер, 18:15 , 07-Мрт-11
          • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,iZEN, 19:54 , 07-Мрт-11
    • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,Ytch, 16:00 , 07-Мрт-11
      • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,iZEN, 16:08 , 07-Мрт-11
        • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,коксюзер, 16:22 , 07-Мрт-11
        • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,коксюзер, 19:50 , 07-Мрт-11
          • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,linux_must_die, 20:37 , 07-Мрт-11
            • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,коксюзер, 23:05 , 07-Мрт-11
    • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,СуперАноним, 22:06 , 07-Мрт-11
    • Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, ...,Аноним, 23:14 , 08-Мрт-11

> Проблема вызвана использованием для
> преобразования строки с IP-адресом функции
>sprintf("%d.%d.%d.%d") вместо inet_ntop;

Ой, умора. Программеру премию Дарвина за вычисление (-1) в степени n посредством цикла.

Не надо над этим смеяться! Эта новость так мою самооценку повысила, а вы своим комментарием всё испортили...

> Проблема вызвана использованием для преобразования строки с IP-адресом вместо
> inet_ntop функции sprintf("%d.%d.%d.%d") с однобайтовыми аргументами;

Зачетная дыра, в своем коде сейчас почти такую же нашел :-)

> Несколько уязвимостей в Linux-ядре:

Надо бы указывать с какой по какую версию.

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

Переполнение буферов — это родимое пятно C/C++ и с этим ничего нельзя поделать. Не на Аде же всё переписывать.

Почему бы и не на Аде, раз такие дела?..

> Почему бы и не на Аде, раз такие дела?..

Ну так на Аде же Контроля нет. Он же только в C/C++ - полный и окончательный контроль.

О каком контроле речь? :)

> О каком контроле речь? :)

Спросите у апологетов этих языков.

> О каком контроле речь? :)

О восходе и закате Солнца вручную же.

>Не на Аде же всё переписывать.

Что случилось? Все, затаив дыхание, ждали про java, а тут такое... Неужели решил "соскочить"?

>>Не на Аде же всё переписывать.
> Что случилось? Все, затаив дыхание, ждали про java, а тут такое... Неужели решил "соскочить"?

Платформа Java имеет изъян: сама JVM написана на C++.
В Ada компилятор свой собственный и нет никакого рантайма, физически отделённого от программы.

> Платформа Java имеет изъян: сама JVM написана на C++.

http://labs.oracle.com/projects/maxine/

> Не волнуйся, дружок, переполнение буфера в том или ином виде есть во
> всех практически применяемых языках.

Ложь и провокация.

а теперь давай аргументы

> а теперь давай аргументы

Пусть лжец и провокатор для начала их даст. ;)

>Не на Аде же всё переписывать

Ну уж точно не на жабе :))

> Переполнение буферов — это родимое пятно C/C++

Ошибки в программах - родимое пятно тех кто их делает. Проще обвинить во всем компилятор, интерпретатор, Столлмана, Торвальдса или кого-нибудь еще. Лишь бы только не признаваться себе что лопухнулся. Логика идиота и труса. Вот только с таким подходом ваши программы будут с ошибками на любом языке. Потому что язык не будет думать за вас. А если вдруг станет и сможет это делать нормально - ну так программистов можно будет уволить за ненадобностью.