The OpenNET Project / Index page

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

Обнаружена еще одна уязвимость в 32-битной версии библиотеки LZ4

13.07.2014 06:33

Выявление опасной уязвимости в реализациях алгоритмов распаковки LZO и LZ4 подстегнуло проведение дополнительного аудита кода и анализа возможных проблем. В результате была обнаружена ещё одна потенциальная уязвимость - библиотека LZ4 в некоторых ситуациях осуществляет выделение блоков памяти по старшим адресам (выше адреса 0x80000000), что может привести к проблемам на 32-разрядных архитектурах (пока проблему удалось повторить только на архитектуре ARM). Хотя автор исследования отмечает, что практическое использование данной уязвимости затруднено, проблема оперативно исправлена в новой ревизии библиотеки (коммит r119).

  1. Главная ссылка к новости (http://fastcompression.blogspo...)
  2. OpenNews: Опасная уязвимость в реализациях LZO/LZ4, затрагивающая ядро Linux, FFmpeg, OpenVPN и другие проекты
Автор новости: Аноним
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/40191-lz4
Ключевые слова: lz4
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (17) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Доктор Звездулькин (?), 08:21, 13/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Насколько я понимаю, там все равно условий выше крыши. Только ARM, только в ядре (потому что надо писать в адрес 0x0), блок должен находиться в памяти дальше определенного адреса...

    Однако это хорошо, пусть дальше копают, может, еще чего-нибудь найдут и устранят.

     
     
  • 2.8, Аноним (-), 16:26, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну да, сложная в эксплуатации хрень, но лучше заапдейтиться.
     
  • 2.17, pavlinux (ok), 03:56, 14/07/2014 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Насколько я понимаю, там все равно условий выше крыши.
    > Только ARM, только в ядре (потому что надо писать в адрес 0x0),
    > блок должен находиться в памяти дальше определенного адреса...

    В вертушке против мордника шли в одни ноги. Но в тягун пРОсто стал натягивать и устроил отрыв. Я уселся на колесо. Ему хорошо: раздельник пластмассовый, лежак с манетками, капля, трубки, спереди лопасти, сзади диск, навеска верхняя. У меня же недавно сломался шип на туфлях, а дуся с чайника еще не приехала, поставил яйцерезки с байка. Ну и сижу я в его мешке пассажиром. А старый вгшник переключился с каденса на сковородку и стал ломать кардан как раз в тот момент, когда у меня контакт отстегнулся, и скинул меня. Да и куда мне? На чугуне, баране и мягких колесах, когда цепь, скотина, закусывает и скачет по кассете из-за замка от девятки на десятке. И вообще, он после сушки, а я даже не вейтвиннер!
    Я конечно попытался за ним полидировать, включив края, но капнул и вернулся в мамку. Тошним понемногу. Раскладной на ригиде заголодал и закинулся гелем. Борода то теперь железный, но почему-то матрасит на найнере со штанами. Кое как выстроили поезд, работаем.
    Тем временем одинокий пелотон перед торчком закололся и долго возился с соском. Мог бы получить гороховую или желтую, но мы его добрали, я как раз на смене был. Все бы хорошо, но в финишных разборках на расколбасе сдуру устроили завал - двое рогами зацепились. Повезло, что отделались гнутым петухом, ободранным пером и сломанным пистолетом. Ничего, на оранжевом много чего дербанят. Кстати горилла никому не нужна?
    Знатный бревет получился. Тем кто в отсосе приехал, привезли 5 минут. Ибо нефиг на группу на сосисах соваться.

     
     
  • 3.18, Аноним (-), 05:23, 14/07/2014 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Павлин, что ты сам съел, выпил или выкурил, открой секрет? Больно уж круто тебя прет.
     
  • 3.19, gni (ok), 10:42, 14/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    мда, как то трудно читается по утро. Днем попробую
     
  • 3.20, Злой анонимус (?), 13:14, 14/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Опаньки!
    Это ж замечательный текст.  "Lorem ipsum dolor sit amet ...: нервно курит в сторонке.
    В мемориз однозначно!!!
     

  • 1.2, A.Stahl (ok), 10:16, 13/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Как хорошо, что я не участвую в разработке каких-либо очень распространённых библиотек.
    Я бы не захотел и всячески сопротивлялся таким костылям, как проверка адреса, по которому система выделила память. Что может быть унылей, чем пихать платформозависимые проверки в платформонезависимый по своей сути код.
     
     
  • 2.5, Аноним (-), 12:16, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Как хорошо, что ты не участвуешь в разработке каких-либо очень распространённых библиотек. Потому что ты некомпетентен и не умеешь читать код.
     
  • 2.12, Ordu (ok), 19:14, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Я полагаю, что проблема не в системе, которая где-то не там выделила память, а в тех аргументах, которые библиотека засунула в mmap. malloc из libc вряд ли на такое способен.
     
     
  • 3.13, A.Stahl (ok), 20:06, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ты меня не понял. Мне претит не проверка указателя на факт выделения системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить себя за яйцо. Ты готов в своей программе отслеживать, чтобы результат целочисленного деления не делился нацело на 11, а если таки делится, то повторять деление. И всё это лишь потому, что на серии HJ4 процессоров TYNJUX-2 это может привести к чему-то там?
     
     
  • 4.14, Аноним (-), 20:39, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Предлагаю сделку. Ты покажешь место в патче, вводящем такую проверку, либо выложишь видео на YouTube, где кусаешь себя за яйцо. Идёт?
     
  • 4.15, Ordu (ok), 22:37, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, если я тебя понял, самое неприятное в этом то, что проблемы совершенно непре... большой текст свёрнут, показать
     

  • 1.3, Аноним (-), 10:51, 13/07/2014 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    интересно, это какие такие проблемы могут возникнуть, если адреса выше 0x80000000?
     
     
  • 2.4, AlexAT (ok), 12:10, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Старший бит используется как знак числа. Если адрес предполагается всегда положительным, и с адресами ведутся какие-либо математические операции, допускающие знаковое переполнение и клэмпинг, например - результат может оказаться неожиданным.
     
     
  • 3.7, Аноним (-), 15:38, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    если ты программист, ты наверно учитываешь эту ситуацию? по прежнему не вижу проблем с адресами выше 80000000
     
     
  • 4.16, Ordu (ok), 23:07, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное учитываешь. Если не пишешь код из предположения, что 32-х разрядные системы не выделяют память с адресами выше 0x80000000. В ретроспективе предположение необоснованное, но для человека выросшего на x86 вполне естественное, хоть и ошибочное.
     
  • 2.6, Аноним (-), 12:24, 13/07/2014 [^] [^^] [^^^] [ответить]  
  • +/
    signed int32 overflow
     

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



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

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