форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
Сообщение от opennews on 13-Июл-14, 08:21
Выявление опасной уязвимости (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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+1 +/–
Сообщение от Доктор Звездулькин on 13-Июл-14, 08:21
Насколько я понимаю, там все равно условий выше крыши. Только ARM, только в ядре (потому что надо писать в адрес 0x0), блок должен находиться в памяти дальше определенного адреса... Однако это хорошо, пусть дальше копают, может, еще чего-нибудь найдут и устранят.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	8. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Аноним (??) on 13-Июл-14, 16:26
	Ну да, сложная в эксплуатации хрень, но лучше заапдейтиться.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	17. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	–2 +/–
	Сообщение от pavlinux (ok) on 14-Июл-14, 03:56
	> Насколько я понимаю, там все равно условий выше крыши. > Только ARM, только в ядре (потому что надо писать в адрес 0x0), > блок должен находиться в памяти дальше определенного адреса... В вертушке против мордника шли в одни ноги. Но в тягун пРОсто стал натягивать и устроил отрыв. Я уселся на колесо. Ему хорошо: раздельник пластмассовый, лежак с манетками, капля, трубки, спереди лопасти, сзади диск, навеска верхняя. У меня же недавно сломался шип на туфлях, а дуся с чайника еще не приехала, поставил яйцерезки с байка. Ну и сижу я в его мешке пассажиром. А старый вгшник переключился с каденса на сковородку и стал ломать кардан как раз в тот момент, когда у меня контакт отстегнулся, и скинул меня. Да и куда мне? На чугуне, баране и мягких колесах, когда цепь, скотина, закусывает и скачет по кассете из-за замка от девятки на десятке. И вообще, он после сушки, а я даже не вейтвиннер! Я конечно попытался за ним полидировать, включив края, но капнул и вернулся в мамку. Тошним понемногу. Раскладной на ригиде заголодал и закинулся гелем. Борода то теперь железный, но почему-то матрасит на найнере со штанами. Кое как выстроили поезд, работаем. Тем временем одинокий пелотон перед торчком закололся и долго возился с соском. Мог бы получить гороховую или желтую, но мы его добрали, я как раз на смене был. Все бы хорошо, но в финишных разборках на расколбасе сдуру устроили завал - двое рогами зацепились. Повезло, что отделались гнутым петухом, ободранным пером и сломанным пистолетом. Ничего, на оранжевом много чего дербанят. Кстати горилла никому не нужна? Знатный бревет получился. Тем кто в отсосе приехал, привезли 5 минут. Ибо нефиг на группу на сосисах соваться.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	18. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+2 +/–
	Сообщение от Аноним (??) on 14-Июл-14, 05:23
	Павлин, что ты сам съел, выпил или выкурил, открой секрет? Больно уж круто тебя прет.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	19. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от gni (ok) on 14-Июл-14, 10:42
	мда, как то трудно читается по утро. Днем попробую
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Злой анонимус on 14-Июл-14, 13:14
	Опаньки! Это ж замечательный текст.  "Lorem ipsum dolor sit amet ...: нервно курит в сторонке. В мемориз однозначно!!!
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

2. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	–2 +/–
Сообщение от A.Stahl (ok) on 13-Июл-14, 10:16
Как хорошо, что я не участвую в разработке каких-либо очень распространённых библиотек. Я бы не захотел и всячески сопротивлялся таким костылям, как проверка адреса, по которому система выделила память. Что может быть унылей, чем пихать платформозависимые проверки в платформонезависимый по своей сути код.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	5. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+1 +/–
	Сообщение от Аноним (??) on 13-Июл-14, 12:16
	Как хорошо, что ты не участвуешь в разработке каких-либо очень распространённых библиотек. Потому что ты некомпетентен и не умеешь читать код.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	12. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Ordu (ok) on 13-Июл-14, 19:14
	Я полагаю, что проблема не в системе, которая где-то не там выделила память, а в тех аргументах, которые библиотека засунула в mmap. malloc из libc вряд ли на такое способен.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	13. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	–1 +/–
	Сообщение от A.Stahl (ok) on 13-Июл-14, 20:06
	Ты меня не понял. Мне претит не проверка указателя на факт выделения системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить себя за яйцо. Ты готов в своей программе отслеживать, чтобы результат целочисленного деления не делился нацело на 11, а если таки делится, то повторять деление. И всё это лишь потому, что на серии HJ4 процессоров TYNJUX-2 это может привести к чему-то там?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+3 +/–
	Сообщение от Аноним (??) on 13-Июл-14, 20:39
	Предлагаю сделку. Ты покажешь место в патче, вводящем такую проверку, либо выложишь видео на YouTube, где кусаешь себя за яйцо. Идёт?
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Ordu (ok) on 13-Июл-14, 22:37
	> Ты меня не понял. Мне претит не проверка указателя на факт выделения > системой памяти, а проверка указателя на пересечение с каким-то диапазоном адресов > просто так, поскольку где-то кто-то как-то на некоторых процессорах может укусить > себя за яйцо. Ну, если я тебя понял, самое неприятное в этом то, что проблемы совершенно непредсказуемы заранее, потому что невозможно знать особенности функционирования всех платформ. Но одну-две платформы я могу ведь знать во всех их особенностях на всех уровнях, начиная с таких нюансов, как количество регистров процессора и назначение каждого из них, системы команд, продолжая моделью распределения памяти, которую использует ядро/libc, и заканчивая всякими особенностями функционирования основных библиотек и используемого компилятора. А значит описанные проблемы на известных мне платформах -- не проблемы вовсе. Что же при этом творится на других платформах -- это пускай отслеживают те, кто занимается поддержкой тех платформ. > Ты готов в своей программе отслеживать, чтобы результат > целочисленного деления не делился нацело на 11, а если таки делится, > то повторять деление. И всё это лишь потому, что на серии > HJ4 процессоров TYNJUX-2 это может привести к чему-то там? Я занимался подобным. Не потому что на каких-то там процессорах, что-то идёт не так, а потому что имела место быть довольно заморочная математика в целых числах, требовался чёткий контроль за округлением, в некоторых ситуациях были уместны assert(reminder==0), в некоторых ситациях случаи reminder!=0 приходилось обрабатывать особо. И не скажу, что это так уж сложно -- да, пришлось освежить в памяти курс теории чисел, прослушанный в ВУЗе, но это ведь не проблема. В общем, подводя итог сказанному, не могу сказать что необходимость каждый вызов оператора / дополнять вызовом оператора % (или использовать div_t и div), была бы такой уж ужасной необходимостью, которая может оттолкнуть меня от написания кода. В некотором смысле это даже полезно, потому что заставляет держать в голове более точную модель работы кода.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

3. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
Сообщение от Аноним (??) on 13-Июл-14, 10:51
интересно, это какие такие проблемы могут возникнуть, если адреса выше 0x80000000?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	–1 +/–
	Сообщение от AlexAT (ok) on 13-Июл-14, 12:10
	Старший бит используется как знак числа. Если адрес предполагается всегда положительным, и с адресами ведутся какие-либо математические операции, допускающие знаковое переполнение и клэмпинг, например - результат может оказаться неожиданным.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	7. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Аноним (??) on 13-Июл-14, 15:38
	если ты программист, ты наверно учитываешь эту ситуацию? по прежнему не вижу проблем с адресами выше 80000000
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	16. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Ordu (ok) on 13-Июл-14, 23:07
	Наверное учитываешь. Если не пишешь код из предположения, что 32-х разрядные системы не выделяют память с адресами выше 0x80000000. В ретроспективе предположение необоснованное, но для человека выросшего на x86 вполне естественное, хоть и ошибочное.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	6. "Обнаружена еще одна уязвимость в 32-битной версии библиотеки..."	+/–
	Сообщение от Аноним (??) on 13-Июл-14, 12:24
	signed int32 overflow
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема