The OpenNET Project / Index page

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

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

13.11.2018 08:55

В библиотеке 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
Тип: Проблемы безопасности
Короткая ссылка: https://opennet.ru/49600-gettext
Ключевые слова: gettext
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (30) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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 файл без доступа в /usr?

    .po для людей, для программ .gmo, их из .po получают.
    И если вы в /usr писать можете, то у вас уже есть права root,
    нафига вам уязвимость?

     
     
  • 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 +/
    Сейчас выдвинут тезис, что ручное управление памятью нужно "осилить". Тезис будет сопровождаться упоминанием о неких "макаках", которым "осиляторство" не под силу. Но то, что этот тезис появится под новостью о gettext, будет подразумевать, что авторы gettext - неисиляторы и макаки. Спрашивается, зачем тогда нам операционная система GNU, если его писали неосиляторы и макаки?

    Но если этот тезис выдвинут не будет (в виду неприятных выводов), то это будет означать, что си действительно такой неудачный, что даже "осиляторы" и "немакаки" напишут в нем уязвимый код. Но из этого последует другой вывод -- что следует пользоваться другими языками, где нет ручного управления памятью.

     
     
  • 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 +/
    То есть споры о единственно верном подходе к программированию — удел балаболов и пустомель, в своём развитии ушедших не дальше чёрно-белой картины мира, свойственной подростковому возрасту. Судя по комментариям к новостям на подобную тематику, взрослые люди на опеннет встречаются крайне редко. Меня это печалит.
     
     
  • 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:
    Текст:



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

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