The OpenNET Project / Index page

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

Уязвимость в e2fsck, проявляющаяся при обработке специально оформленных каталогов

09.01.2020 22:53

В утилите e2fsck, поставляемой в составе пакета e2fsprogs, выявлена уязвимость (CVE-2019-5188), позволяющая добиться выполнения кода злоумышленника при выполнении проверки файловой системы, содержащей специальным образом оформленные каталоги. Наличие уязвимости подтверждено в выпусках с 1.43.3 по 1.45.4. Уязвимость устранена в обновлении e2fsck 1.45.5. В дистрибутивах проблема пока остаётся неисправленной (Debian, Arch Linux, SUSE/openSUSE, Ubuntu, RHEL).

Уязвимость вызвана ошибкой в функция mutate_name() из файла rehash.c, применяемой при перестроении связанных с каталогом хэш-таблиц, обеспечивающих сопоставление с каталогом всех находящихся в нём файлов. Повреждение связанной с каталогом структуры hash_entry может привести к записи данных атакующего в область вне выделенного буфера. В случае выявления в хэш-таблице привязки к каталогу нескольких файлов с одинаковым именем, утилита e2fsck переименовывает повторяющиеся файлы с добавлением к имени ~0, ~1 и т.п. Для временного хранения нового имени при подобном переименовании в стеке выделяется буфер, размером 256 байт.

Размер копируемых данных определяется выражением "entry->name_len & 0xff", но значение entry->name_len загружается из структуры на диске, а не вычисляется на основе фактического размера имени. Если размер равен нулю, то индекс массива принимает значение -1 и создаются условия для целочисленного переполнения через нижнюю границу буфера (integer underflow) и перезаписи других данных в стеке значением "~0". Для 64-разрядных систем эксплуатация уязвимости оценивается как маловероятная и требующая отсутствия ограничений на размер стека (ulimit -s unlimited). Для 32-разрядных систем эксплуатация считается возможной, но результат сильно зависит от того, как был собран исполняемый файл компилятором.

Для совершения атаки злоумышленнику необходимо определённым образом повредить данные в разделе с ФС ext2, ext3 или ext4. Так как данная операция требует наличия привилегий суперпользователя, уязвимость представляет угрозу при проверке утилитой e2fsck внешних накопителей или полученных извне образов ФС.

  1. Главная ссылка к новости (https://blog.talosintelligence...)
  2. OpenNews: В ядре Linux выявлены ошибки, приводящие к зависанию процессов и повреждению разделов EXT4
  3. OpenNews: В Ext4 исправлена ошибка, которая потенциально могла привести к разрушению данных
  4. OpenNews: Выпущен патч для исправления ошибки в ext4, которая могла привести к повреждению ФС
  5. OpenNews: Уязвимость в ядре Linux, позволяющая поднять привилегии через eCryptfs
  6. OpenNews: Критическая уязвимость в OverlayFS, позволяющая поднять свои привилегии в Ubuntu
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/52162-e2fsprogs
Ключевые слова: e2fsprogs, ext4
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:48, 09/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > значение entry->name_len загружается из структуры на диске, а не вычисляется на основе фактического размера имени

    И здесь каждый пук проверять и перепроверять приходится. Да что ж за жизнь такая-то...
    *ушёл топиться*

     
     
  • 2.10, Аноним (10), 07:43, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Блин, если атакующий тебе подсунул Специально Оформленную Файловую Систему - там уже и топиться не обязательно, атакующий сам тебя утопит в любой удобный ему момент. Заменит парочку SUID'ных файлов на свои - и порядок.
     
     
  • 3.16, evkogan (?), 09:22, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вам ни разу не приносили чужие диски починить/вынуть что можно?
     
     
  • 4.19, Аноним (-), 10:55, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Приносили. Я под такое readonly live сессию с флехи на отдельном компе подымаю. По многим причинам.
     
     
  • 5.27, Аноим (?), 18:53, 13/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А домашним интернетом пользуетесь? Или только мобильным?
     

  • 1.2, Аноним (-), 00:36, 10/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    chkdsk.exe: нет сырцов - нет проблем!
     
     
  • 2.4, Аноним (4), 01:32, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Эта chkdsk.exe наверно намбер ван по ссыкотности утилита. Она каждый раз норовит перемешать мне все файлы, удалить каталоги, обезличить и поместить файлы в found (причём, зачастую это битые файлы, которые были удалены когда-то). Это в 10, в 7 она просто разваливала фс на невосстановимое месиво. А уж если у тебя там диск посыпался, то ты приплыл. Всё-таки я рад, что нашёл в себе мотивацию съехать с альтернативных ос на линукс.

    Мне тут давеча fsck на ext4 500гб нашёл. После хардресета, угу (с кнопочки). Но вроде ничего не потерялось и не побилось. Не ставьте нвидиевский блоб 440, от него слишком много спецэффектов, в иксах так точно. С 435 всё норм.

     
     
  • 3.8, Аноним (8), 07:18, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Согласен. Скопировать данные с таких дисков, испорченных Windows, удается, подключив их к системе на Linux. Затем форматирование и возвращение данных обратно. Windows, если она была на таких дисках, приходится переставлять.
     
  • 3.14, Твоямамка (?), 08:49, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Поставил блоб 440, все норм, что я делаю не так?
     
     
  • 4.17, Аноним (4), 09:28, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Поставил блоб 440, все норм, что я делаю не так?

    OpenGL приложения запускал? А vulkan? Я так больше недели работал, пока не обнаружил, что оно рандомно зависает и срёт гигабайтами логов с ошибками.

     
  • 4.18, Vanych (?), 10:33, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты не поблагодарил. Вот это ты не так делаешь.
    В виду своей ограниченности возомнив себя "умным", да еще с "прямыми руками", умноженное на ничем не обоснованное самомнение и возведенное в невоспитанность.
    Не факт, что данные проблемы будут воспроизведены у тебя - зависит от много.
    У человека есть идентифицированные проблемы, он поделился по случаю, "кто предупрежден, тот вооружен".
     
  • 2.11, Аноним (10), 07:45, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > chkdsk.exe: нет сырцов - нет проблем!

    И половину файлухи при случае сносит. Нет файлов - нет проблем.

     

  • 1.3, Аноним (3), 00:48, 10/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Размер копируемых данных определяется выражением "entry->name_len & 0xff", но значение entry->name_len загружается из структуры на диске, а не вычисляется на основе фактического размера имени. Если размер равен нулю, то индекс массива принимает значение -1

    & это умножение же, если 0 умножить на 0xff будет 0, откуда -1 то?

     
     
  • 2.5, Аноним (5), 01:43, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Очень просто: "размер копируемых данных" определяется этим выражением, но "индекс массива" принимает значение -1. "Размер копируемых данных" и "индекс массива" - это разные вещи. Индекс вычисляется из размера по формуле, которая в новости не приведена. Пройдите по ссылке и почитайте оригинал.
     
     
  • 3.13, Аноним (10), 07:49, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Програмер просто не учел, что недружелюбная среда может подсунуть ему в этом поле 0 если это "специально оформленная" ФС. Из этого успешно вычитают единицу. И получают ... определенно, совсем не то.
     
  • 2.9, Аноним (9), 07:40, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    После for (i = l-1; i > 0; i--) { переменная i остаётся равной -1, а затем перед записью в массив условие истинным воспринимается условие if ((i == (int)l - 1)
     
  • 2.12, Аноним (10), 07:46, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > & это умножение же

    С каких пор? Это побитовый AND с 0xff (который 8 битов выставленных в единицы, остальное нули).

     
     
  • 3.23, KonstantinB (??), 15:39, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Оно же конъюнкция, оно же логическое умножение.
     

  • 1.6, Главный Ананим (ok), 02:35, 10/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот так то. А где растовцы, сечас уже должны били набежать с воплями -  "это всё ваш небезопасный код на си виноват, в расте всё намного лучше!"
     
     
  • 2.7, вопящие растовцы (?), 02:49, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +8 +/
    это всё ваш небезопасный код на си виноват, в расте всё намного лучше!
     
     
  • 3.15, Твоямамка (?), 08:52, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    И че дальше, надеюсь ты уже все переписал и собраал и вот вот нам свой болгенос предоставиш
     
  • 3.20, Аноним (-), 10:57, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А чего, раст за програмера думает и вот прям за ним все логические ошибки исправляет? Да ну ладно? :)
     
     
  • 4.21, Аноним (21), 11:44, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Но ведь так хочется, чтобы ЯП исправлял за програмера все ошибки!
     
     
  • 5.22, Аноним (-), 12:10, 10/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Но ведь так хочется, чтобы ЯП исправлял за програмера все ошибки!

    Ну тогда он и зарплату вместо програмера наверное должен получать. А програмера вообще уволить, зачем он такой? Пусть вон на стройке пашет. Хотя 3D принтеры и там достанут...

     

  • 1.24, Аноним (24), 22:19, 10/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В Slackware current уязвимость воспроизвести так и не удалось.
     
  • 1.25, хз.кто (?), 06:00, 11/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Чего-то не понял, раньше не было нулевых файлов??
     
     
  • 2.26, Аноним (-), 10:32, 11/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Там дело не в нулевых файлах а в том что код в программе верил джентльменам с диском на слово про размер имени файла. А вот это зря.
     

  • 1.28, Аноним (28), 14:25, 16/01/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > повредить данные в разделе с ФС ext2, ext3 или ext4.

    Это дерьмофс давно нужно забыть.

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



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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