The OpenNET Project / Index page

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

13.11.2018 08:55  Уязвимость в gettext, позволяющая выполнить код при обработке po-файлов

В библиотеке gettext, применяемой для создания многоязычных приложений, выявлена опасная уязвимость (CVE-2018-18751), которая может использоваться для организации выполнения произвольного кода при обработке специально оформленных сообщений в po-файлах. Проблема вызвана двойным освобождением блока памяти (double free) в функции default_add_message, определённой в файле read-catalog.c. В сети уже доступны варианты po-файлов, эксплуатирующие уязвимость.

Проблема проявляется только в актуальном выпуске gettext 0.19.8. В кодовой базе gettext проблема была устранена ещё в сентябре 2016 года, без акцента на наличие возможной уязвимости, но данное изменение пока не вошло в состав релиза (последний выпуск gettext 0.19.8 датирован июнем 2016 года) и новая версия с исправлением ещё не доступна. Уязвимость устранена в Ubuntu и Fedora, но остаётся неисправленной в Debian и RHEL 7. RHEL 5, RHEL 6, SUSE и openSUSE проблеме не подвержены так как используют старые версии gettext без файла "read-catalog.c".

  1. Главная ссылка к новости (https://usn.ubuntu.com/3815-1/...)
  2. OpenNews: Компания Google добавила в Translator Toolkit поддержку GNU gettext
  3. OpenNews: Уязвимость в SMT/Hyper-Threading, позволяющая определить ключи шифрования чужих процессов
  4. OpenNews: Уязвимости в Bluetooth-чипах TI, позволяющие удалённо выполнить код
  5. OpenNews: Выпуск сервера потокового вещания Icecast 2.4.4 с устранением уязвимостей
  6. OpenNews: Уязвимость в VirtualBox, позволяющая выполнить код на стороне хост-системы
Лицензия: CC-BY
Тип: Проблемы безопасности
Ключевые слова: gettext
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, Аноним (-), 09:14, 13/11/2018 [ответить] [показать ветку] [···]    [к модератору]
  • –8 +/
    Вот вам и языки с ручным управлением памятью.

    *садится и ждет еду*

     
     
  • 2.2, ползкрокодил (?), 09:58, 13/11/2018 [^] [ответить]    [к модератору]
  • +5 +/
    Ну а толку? Если есть доступ испортить po-файлы, то можно и исполняемые пошатать как угодно.
     
     
  • 3.3, Ordu (ok), 10:15, 13/11/2018 [^] [ответить]    [к модератору]
  • +/
    А разве нельзя подложить свой po файл без доступа в /usr?
     
     
  • 4.8, Аноним (8), 11:00, 13/11/2018 [^] [ответить]     [к модератору]
  • +1 +/
    po для людей, для программ gmo, их из po получают И если вы в usr писать мо... весь текст скрыт [показать]
     
     
  • 5.14, Аноним (14), 13:04, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Там указано "без доступа в /usr"
     
  • 3.24, ig0r (??), 10:59, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    А если ты написал программу, можно подумать ты будешь ревьюить .po файлы в PR если они для незнакомого тебе языка.
     
     
  • 4.32, ползкрокодил (?), 18:22, 28/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Можно даже отревьюить, а потом окажется, что какая-то последовательность иероглифов крашит макось.
     
  • 2.5, Аноним (5), 10:32, 13/11/2018 [^] [ответить]     [к модератору]  
  • +2 +/
    Сейчас выдвинут тезис, что ручное управление памятью нужно осилить Тезис буде... весь текст скрыт [показать]
     
     
  • 3.6, Аноним (6), 10:41, 13/11/2018 [^] [ответить]    [к модератору]  
  • +3 +/
    Что-то твой опус напоминает анекдот про Петьку и логику.
     
     
  • 4.7, Акакжев (?), 10:53, 13/11/2018 [^] [ответить]    [к модератору]  
  • +7 +/
    Скорее, про Петьку и нюанс.
     
  • 3.10, captcha 20168 (?), 11:06, 13/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    > следует пользоваться другими языками, где нет ручного управления памятью

    безбожно неэффективный код

     
     
  • 4.20, Аноним (20), 18:16, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Предрассудки. Ручное управление памятью тоже требует ресурсов, а порой и медленнее GC, который может отрабатывать в отдельном потоке и даже устранять фрагментацию
     
     
  • 5.29, Annoynymous (ok), 22:18, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Помнится, в Java был многпоточны
     
  • 5.30, Annoynymous (ok), 22:19, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Помнится, в Java был многопоточный GC.
     
     
  • 6.31, Аноним (31), 00:03, 15/11/2018 [^] [ответить]    [к модератору]  
  • +1 +/
    Уж каких там только GC не было, а все равно тормозит.
     
  • 3.17, Аноним (17), 14:14, 13/11/2018 [^] [ответить]     [к модератору]  
  • +4 +/
    Всё правильно изложил Да, так оно и есть - с памятью надо обращаться аккуратно ... весь текст скрыт [показать]
     
     
  • 4.21, Аноним (20), 18:18, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Вот только эксплуатировать уязвимость в интерпретаторе намного сложнее, чем в прикладном коде
     
     
  • 5.22, Аноним (20), 18:19, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Сорри это к 2.11 было
     
  • 3.25, IRASoldier (?), 14:17, 14/11/2018 [^] [ответить]    [к модератору]  
  • –1 +/
    >операционная система GNU

    Нет такой операционной системы.

     
     
  • 4.27, девелоперкодошлеп (?), 14:39, 14/11/2018 [^] [ответить]    [к модератору]  
  • +/
    как это нету, вон, gnu hurd, вчера только в эмуляторе ее запускал.

    хотя, конечно, когда доломают все эмуляторы, еще как-то умеющие 32-бита, будут проблемы.

     
  • 2.11, beck (??), 11:11, 13/11/2018 [^] [ответить]    [к модератору]  
  • +4 +/
    В языках с автоматическим управлением памятью управление памятью написано на тех же языках с ручным управлением памятью. И это конец рекурсии, так сказать.

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

     
     
  • 3.19, Аноним (19), 16:19, 13/11/2018 [^] [ответить]     [к модератору]  
  • +4 +/
    То есть споры о единственно верном подходе к программированию 8212 удел балаб... весь текст скрыт [показать]
     
     
  • 4.23, beck (??), 18:51, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    Совершенно согласен.
     
  • 2.18, Аноним (18), 16:02, 13/11/2018 [^] [ответить]    [к модератору]  
  • +/
    А в языках с ручным управлением памяти давно существует Borrow Checker для защиты от таких ошибок.
     
  • 1.4, Alex_K (??), 10:18, 13/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Ведь ничего не понятно в том, что написали про подверженные проблеме версии.
     
     
  • 2.9, ddd788 (?), 11:00, 13/11/2018 [^] [ответить]    [к модератору]  
  • +2 +/
    Что там непонятного? Последняя версия выпущена в 2016 году - она и подвержена. Не подверждены дистрибутивы, которые используют более древнюю версию.
     
     
  • 3.12, Аноним (12), 11:25, 13/11/2018 [^] [ответить]     [к модератору]  
  • +3 +/
    Судя по написанному, также не подвержены дистрибутивы, собирающие себе свеженьки... весь текст скрыт [показать]
     
  • 1.13, Аноним (13), 11:50, 13/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • –1 +/
    Где мой фаззинг, а? Привыкли тестировать мультимедию, привыкайте фаззить пошки.
     
  • 1.16, Аноним (16), 14:00, 13/11/2018 [ответить] [показать ветку] [···]    [к модератору]  
  • +4 +/
    Напоминает большинство новостей о якобы уязвимостях Linux типа - нужны 3 команды, чтобы сломать то-то и то-то ... Первая команда - sudo ... Бред.
     

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


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