https://opennet.ru/openforum/vsluhforumID3/96832.html Выявление опасной уязвимости (http://www.opennet.ru/opennews/art.shtml?num=40093) в реализациях алгоритмов распаковки LZO и LZ4 подстегнуло проведение дополнительного аудита кода и анализа возможных проблем. В результате была обнаружена ещё одна потенциальная уязвимость (https://code.google.com/p/lz4/issues/detail?id=134&can=1) - библиотека LZ4 в некоторых ситуациях осуществляет выделение блоков памяти по старшим адресам (выше адреса 0x80000000), что может привести к проблемам на 32-разрядных архитектурах. Хотя автор исследования отмечает, что практическое использование данной уязвимости затруднено, проблема оперативно исправлена в новой ревизии библиотеки (коммит r119). <br><br><br>URL: http://fastcompression.blogspot.com/2014/07/pointer-overflow-vs-rce-analysis-of-lz4.html<br>Новость: http://www.opennet.ru/opennews/art.shtml?num=40191<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#20 Mon, 14 Jul 2014 09:14:09 GMT Опаньки! <br>Это ж замечательный текст. "Lorem ipsum dolor sit amet ...: нервно курит в сторонке. <br>В мемориз однозначно!!!<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#19 Mon, 14 Jul 2014 06:42:47 GMT мда, как то трудно читается по утро. Днем попробую<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#18 Mon, 14 Jul 2014 01:23:29 GMT Павлин, что ты сам съел, выпил или выкурил, открой секрет? Больно уж круто тебя прет.<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#17 Sun, 13 Jul 2014 23:56:49 GMT &gt; Насколько я понимаю, там все равно условий выше крыши. <br>&gt; Только ARM, только в ядре (потому что надо писать в адрес 0x0), <br>&gt; блок должен находиться в памяти дальше определенного адреса...<br><br>В вертушке против мордника шли в одни ноги. Но в тягун пРОсто стал натягивать и устроил отрыв. Я уселся на колесо. Ему хорошо: раздельник пластмассовый, лежак с манетками, капля, трубки, спереди лопасти, сзади диск, навеска верхняя. У меня же недавно сломался шип на туфлях, а дуся с чайника еще не приехала, поставил яйцерезки с байка. Ну и сижу я в его мешке пассажиром. А старый вгшник переключился с каденса на сковородку и стал ломать кардан как раз в тот момент, когда у меня контакт отстегнулся, и скинул меня. Да и куда мне? На чугуне, баране и мягких колесах, когда цепь, скотина, закусывает и скачет по кассете из-за замка от девятки на десятке. И вообще, он после сушки, а я даже не вейтвиннер!<br>Я конечно попытался за ним полидировать, включив края, но капнул и вернулся в мамку. Тошним понемногу. Раскладной на ригиде https://opennet.ru/openforum/vsluhforumID3/96832.html#16 Sun, 13 Jul 2014 19:07:52 GMT Наверное учитываешь. Если не пишешь код из предположения, что 32-х разрядные системы не выделяют память с адресами выше 0x80000000. В ретроспективе предположение необоснованное, но для человека выросшего на x86 вполне естественное, хоть и ошибочное.<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#15 Sun, 13 Jul 2014 18:37:42 GMT &gt; Ты меня не понял. Мне претит не проверка указателя на факт выделения <br>&gt; системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов <br>&gt; просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить <br>&gt; себя за яйцо.<br><br>Ну, если я тебя понял, самое неприятное в этом то, что проблемы совершенно непредсказуемы заранее, потому что невозможно знать особенности функционирования всех платформ. Но одну-две платформы я могу ведь знать во всех их особенностях на всех уровнях, начиная с таких нюансов, как количество регистров процессора и назначение каждого из них, системы команд, продолжая моделью распределения памяти, которую использует ядро/libc, и заканчивая всякими особенностями функционирования основных библиотек и используемого компилятора. А значит описанные проблемы на известных мне платформах -- не проблемы вовсе. Что же при этом творится на других платформах -- это пускай отслеживают те, кто занимается поддержкой тех платформ.<br><br>&gt; Ты готов в своей программе отслеж https://opennet.ru/openforum/vsluhforumID3/96832.html#14 Sun, 13 Jul 2014 16:39:49 GMT Предлагаю сделку. Ты покажешь место в патче, вводящем такую проверку, либо выложишь видео на YouTube, где кусаешь себя за яйцо. Идёт?<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#13 Sun, 13 Jul 2014 16:06:15 GMT Ты меня не понял. Мне претит не проверка указателя на факт выделения системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить себя за яйцо. Ты готов в своей программе отслеживать, чтобы результат целочисленного деления не делился нацело на 11, а если таки делится, то повторять деление. И всё это лишь потому, что на серии HJ4 процессоров TYNJUX-2 это может привести к чему-то там?<br> https://opennet.ru/openforum/vsluhforumID3/96832.html#12 Sun, 13 Jul 2014 15:14:47 GMT Я полагаю, что проблема не в системе, которая где-то не там выделила память, а в тех аргументах, которые библиотека засунула в mmap. malloc из libc вряд ли на такое способен.<br>