Выявление опасной уязвимости (http://www.opennet.me/opennews/art.shtml?num=40093) в реализациях алгоритмов распаковки LZO и LZ4 подстегнуло проведение дополнительного аудита кода и анализа возможных проблем. В результате была обнаружена ещё одна потенциальная уязвимость (https://code.google.com/p/lz4/issues/detail?id=134&can=1) - библиотека LZ4 в некоторых ситуациях осуществляет выделение блоков памяти по старшим адресам (выше адреса 0x80000000), что может привести к проблемам на 32-разрядных архитектурах. Хотя автор исследования отмечает, что практическое использование данной уязвимости затруднено, проблема оперативно исправлена в новой ревизии библиотеки (коммит r119).
URL: http://fastcompression.blogspot.com/2014/07/pointer-overflow...
Новость: http://www.opennet.me/opennews/art.shtml?num=40191
Насколько я понимаю, там все равно условий выше крыши. Только ARM, только в ядре (потому что надо писать в адрес 0x0), блок должен находиться в памяти дальше определенного адреса...Однако это хорошо, пусть дальше копают, может, еще чего-нибудь найдут и устранят.
Ну да, сложная в эксплуатации хрень, но лучше заапдейтиться.
> Насколько я понимаю, там все равно условий выше крыши.
> Только ARM, только в ядре (потому что надо писать в адрес 0x0),
> блок должен находиться в памяти дальше определенного адреса...В вертушке против мордника шли в одни ноги. Но в тягун пРОсто стал натягивать и устроил отрыв. Я уселся на колесо. Ему хорошо: раздельник пластмассовый, лежак с манетками, капля, трубки, спереди лопасти, сзади диск, навеска верхняя. У меня же недавно сломался шип на туфлях, а дуся с чайника еще не приехала, поставил яйцерезки с байка. Ну и сижу я в его мешке пассажиром. А старый вгшник переключился с каденса на сковородку и стал ломать кардан как раз в тот момент, когда у меня контакт отстегнулся, и скинул меня. Да и куда мне? На чугуне, баране и мягких колесах, когда цепь, скотина, закусывает и скачет по кассете из-за замка от девятки на десятке. И вообще, он после сушки, а я даже не вейтвиннер!
Я конечно попытался за ним полидировать, включив края, но капнул и вернулся в мамку. Тошним понемногу. Раскладной на ригиде заголодал и закинулся гелем. Борода то теперь железный, но почему-то матрасит на найнере со штанами. Кое как выстроили поезд, работаем.
Тем временем одинокий пелотон перед торчком закололся и долго возился с соском. Мог бы получить гороховую или желтую, но мы его добрали, я как раз на смене был. Все бы хорошо, но в финишных разборках на расколбасе сдуру устроили завал - двое рогами зацепились. Повезло, что отделались гнутым петухом, ободранным пером и сломанным пистолетом. Ничего, на оранжевом много чего дербанят. Кстати горилла никому не нужна?
Знатный бревет получился. Тем кто в отсосе приехал, привезли 5 минут. Ибо нефиг на группу на сосисах соваться.
Павлин, что ты сам съел, выпил или выкурил, открой секрет? Больно уж круто тебя прет.
мда, как то трудно читается по утро. Днем попробую
Опаньки!
Это ж замечательный текст. "Lorem ipsum dolor sit amet ...: нервно курит в сторонке.
В мемориз однозначно!!!
Как хорошо, что я не участвую в разработке каких-либо очень распространённых библиотек.
Я бы не захотел и всячески сопротивлялся таким костылям, как проверка адреса, по которому система выделила память. Что может быть унылей, чем пихать платформозависимые проверки в платформонезависимый по своей сути код.
Как хорошо, что ты не участвуешь в разработке каких-либо очень распространённых библиотек. Потому что ты некомпетентен и не умеешь читать код.
Я полагаю, что проблема не в системе, которая где-то не там выделила память, а в тех аргументах, которые библиотека засунула в mmap. malloc из libc вряд ли на такое способен.
Ты меня не понял. Мне претит не проверка указателя на факт выделения системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить себя за яйцо. Ты готов в своей программе отслеживать, чтобы результат целочисленного деления не делился нацело на 11, а если таки делится, то повторять деление. И всё это лишь потому, что на серии HJ4 процессоров TYNJUX-2 это может привести к чему-то там?
Предлагаю сделку. Ты покажешь место в патче, вводящем такую проверку, либо выложишь видео на YouTube, где кусаешь себя за яйцо. Идёт?
> Ты меня не понял. Мне претит не проверка указателя на факт выделения
> системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов
> просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить
> себя за яйцо.Ну, если я тебя понял, самое неприятное в этом то, что проблемы совершенно непредсказуемы заранее, потому что невозможно знать особенности функционирования всех платформ. Но одну-две платформы я могу ведь знать во всех их особенностях на всех уровнях, начиная с таких нюансов, как количество регистров процессора и назначение каждого из них, системы команд, продолжая моделью распределения памяти, которую использует ядро/libc, и заканчивая всякими особенностями функционирования основных библиотек и используемого компилятора. А значит описанные проблемы на известных мне платформах -- не проблемы вовсе. Что же при этом творится на других платформах -- это пускай отслеживают те, кто занимается поддержкой тех платформ.
> Ты готов в своей программе отслеживать, чтобы результат
> целочисленного деления не делился нацело на 11, а если таки делится,
> то повторять деление. И всё это лишь потому, что на серии
> HJ4 процессоров TYNJUX-2 это может привести к чему-то там?Я занимался подобным. Не потому что на каких-то там процессорах, что-то идёт не так, а потому что имела место быть довольно заморочная математика в целых числах, требовался чёткий контроль за округлением, в некоторых ситуациях были уместны assert(reminder==0), в некоторых ситациях случаи reminder!=0 приходилось обрабатывать особо. И не скажу, что это так уж сложно -- да, пришлось освежить в памяти курс теории чисел, прослушанный в ВУЗе, но это ведь не проблема.
В общем, подводя итог сказанному, не могу сказать что необходимость каждый вызов оператора / дополнять вызовом оператора % (или использовать div_t и div), была бы такой уж ужасной необходимостью, которая может оттолкнуть меня от написания кода. В некотором смысле это даже полезно, потому что заставляет держать в голове более точную модель работы кода.
интересно, это какие такие проблемы могут возникнуть, если адреса выше 0x80000000?
Старший бит используется как знак числа. Если адрес предполагается всегда положительным, и с адресами ведутся какие-либо математические операции, допускающие знаковое переполнение и клэмпинг, например - результат может оказаться неожиданным.
если ты программист, ты наверно учитываешь эту ситуацию? по прежнему не вижу проблем с адресами выше 80000000
Наверное учитываешь. Если не пишешь код из предположения, что 32-х разрядные системы не выделяют память с адресами выше 0x80000000. В ретроспективе предположение необоснованное, но для человека выросшего на x86 вполне естественное, хоть и ошибочное.
signed int32 overflow