The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Уязвимости в Glibc, OpenAFS, libpam-pgsql, LibTIFF, FFmpeg, Pango и Linux-ядре

07.03.2011 08:57

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

  • В системной Си-библиотеке Glibc найдена уязвимость, вызванная ошибкой в реализации функции "fnmatch()", которая может привести к повреждению стека при передаче на вход функции специально оформленного имени файла. Уязвимости подвержены использующие данную функцию приложения, например, браузер Chrome. Проблема устранена в Glibc 2.12.2;
  • В распределенной файловой системе OpenAFS 1.4.14 устранено две уязвимости: первая позволяет инициировать крах Linux-ядра, а вторая потенциально дает возможность организовать выполнение кода злоумышленника на RX-сервере, при отправке специально закодированных ASN1-значений;
  • В модуле аутентификации libpam-pgsql найдена уязвимость, позволяющая инициировать переполнение буфера при соединении к использующему модуль приложению с IPv4-адреса, содержащего октет больше 127 (например, IP 10.199.1.1 модуль воспринимает как 10.-57.1.1). Проблема вызвана использованием для преобразования строки с IP-адресом вместо inet_ntop функции sprintf("%d.%d.%d.%d") с однобайтовыми аргументами;
  • В библиотеке LibTIFF найдена уязвимость, позволяющая организовать выполнение кода в использующем библиотеку приложении, при обработке в нём специально оформленного TIFF-файла;
  • В декодере формата Vorbis из состава пакета FFmpeg найдена уязвимость, которая может привести к выполнению кода злоумышленника при обработке специально скомпонованных Vorbis-файлов;
  • В библиотеке Pango найдена уязвимость, которая может привести к переполнению буфера при обработке определенного вида данных. В частности, данная проблема может быть эксплуатирована при открытии определенным образом оформленной web-страницы в Firefox.
  • Несколько уязвимостей в Linux-ядре:
    • Некорректная установка прав доступа на некоторые файлы в директории /proc/{pid}/ после запуска SUID-программы позволяет локальному пользователю получить дополнительную информацию о процессе или изменить некоторые параметры (например, установить свой coredump_filter);
    • Возможность разыменования NULL-указателя при взаимодействии с DNS-резолвером;
    • Наличие доступных на запись областей в sysfs и procfs, что в конечном итоге позволяет изменить значения определенных аппаратных регистров, записать свои данные в NVRAM, или загрузить свою прошивку;
    • Некорректная инициализация определенных структур в функции "sco_sock_getsockopt_old()" (net/bluetooth/sco.c) перед их копированием в пространство пользователя может привести к утечке старого содержимого стека ядра. Аналогичные проблемы зафиксированы в функциях "bnep_sock_ioctl()" (net/bluetooth/bnep/sock.c) и "do_replace()" (net/bridge/netfilter/ebtables.c), но для их эксплуатации необходимо наличие привилегий CAP_NET_ADMIN.


Лицензия: CC-BY
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/29818-security
Ключевые слова: security, Glibc, OpenAFS, LibTIFF, FFmpeg, Pango, kernel
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (18) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Demo (??), 10:25, 07/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проблема вызвана использованием для
    > преобразования строки с IP-адресом функции
    >sprintf("%d.%d.%d.%d") вместо inet_ntop;

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

     
     
  • 2.4, Аноним (-), 11:16, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не надо над этим смеяться! Эта новость так мою самооценку повысила, а вы своим комментарием всё испортили...
     

  • 1.2, Аноним (-), 10:27, 07/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Проблема вызвана использованием для преобразования строки с IP-адресом вместо
    > inet_ntop функции sprintf("%d.%d.%d.%d") с однобайтовыми аргументами;

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

     
  • 1.3, crypt (??), 10:57, 07/03/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    > Несколько уязвимостей в Linux-ядре:

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

     
     
  • 2.6, iZEN (ok), 13:47, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Все версии, даже те, что используются в домашних роутерах и медиаплеерах. :))

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

     
     
  • 3.7, dimss (?), 14:01, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Почему бы и не на Аде, раз такие дела?..
     
     
  • 4.10, коксюзер (?), 14:42, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Почему бы и не на Аде, раз такие дела?..

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

     
     
  • 5.14, dimss (?), 18:12, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    О каком контроле речь? :)
     
     
  • 6.15, коксюзер (?), 18:15, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > О каком контроле речь? :)

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

     
  • 6.19, iZEN (ok), 19:54, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > О каком контроле речь? :)

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

     
  • 3.11, Ytch (?), 16:00, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Не на Аде же всё переписывать.

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

     
     
  • 4.12, iZEN (ok), 16:08, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >>Не на Аде же всё переписывать.
    > Что случилось? Все, затаив дыхание, ждали про java, а тут такое... Неужели решил "соскочить"?

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


     
     
  • 5.13, коксюзер (?), 16:22, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Платформа Java имеет изъян: сама JVM написана на C++.

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

     
  • 5.18, коксюзер (?), 19:50, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Не волнуйся, дружок, переполнение буфера в том или ином виде есть во
    > всех практически применяемых языках.

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

     
     
  • 6.20, linux_must_die (ok), 20:37, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    а теперь давай аргументы
     
     
  • 7.22, коксюзер (?), 23:05, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > а теперь давай аргументы

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

     
  • 3.21, СуперАноним (?), 22:06, 07/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >Не на Аде же всё переписывать

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

     
  • 3.25, Аноним (-), 23:14, 08/03/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Переполнение буферов — это родимое пятно C/C++

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

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру