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

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

"Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от opennews (ok) on 09-Май-14, 00:23
Специалисты из компании Red Hat подняли (https://securityblog.redhat.com/2014/05/07/defeating-memory-.../) заслуживающий внимания вопрос интеграции средств защиты от проведения атак, основанных на корреляции времени выполнения операции и степени совпадения данных, сравниваемых функцией memcmp. Используемая по умолчанию в Glibc реализация memcmp подвержена проблеме, которая позволяет предсказать значение сравниваемых данных. Например, если  memcmp используется при  сравнении ключа шифрования c входными данными, то атакующий может байт за байтом подобрать значение с которым осуществляется сравнение. Техника атаки основана на том, что memcmp завершает выполнение после первого несовпадения, т.е. атакующий может передать случайный набор данных и изменять значение первого байта, отслеживая время выполнения операции. Устойчивое увеличение времени будет сигнализировать об успешности подбора первого байта, после чего можно начать подбирать второй байт и т.д. В качестве решения проблемы предлагается перейти на использование реализации функции memcmp, время выполнения которой явно не зависит от степени совпадения строки (например, можно сравнивать элементы в случайном порядке или сравнивать блоки в несколько байт). Включение по умолчанию подобного варианта функции в Glibc рассматривается как маловероятное (с позиции производительности, текущий вариант memcmp предпочтительней), поэтому как наиболее реалистичный вариант рассматривается возможность задействования защищённой версии memcpm при сборке  Glibc с опцией "-D_FORTIFY_SOURCE=2". URL: https://securityblog.redhat.com/2014/05/07/defeating-memory-.../ Новость: http://www.opennet.dev/opennews/art.shtml?num=39730
Ответить | Правка | Cообщить модератору

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

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

1. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от Пиу (ok) on 09-Май-14, 00:23
и насколько реально этим воспользоваться?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	3. "Техника предсказания содержимого буфера на основе анализа вр..."	+3 +/–
	Сообщение от Аноним (??) on 09-Май-14, 00:30
	Это ещё что, высший пилотаж - восстановление данные по шуму конденцаторов компьютера (http://www.opennet.dev/opennews/art.shtml?num=38689)
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	5. "Техника предсказания содержимого буфера на основе анализа вр..."	+5 +/–
	Сообщение от Аноним (??) on 09-Май-14, 00:50
	> и насколько реально этим воспользоваться? В ряде случаев - вполне. К криптографическим примитивам одно из требований - чтобы время выполнения не зависело от ключа/пароля/etc. Иначе можно будет последовательно подобрать. И одно дело если ты будешь подбирать 20-символьный пароль как 26^20 и другое - как 26 * 20 :). Есть некоторая "небольшая" разница в сложности подбора. Первое ты загнешься подбирать, а вот 520 попыток в хучшем случае - это уже звучит как заявка на победу, не так ли?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	8. "Техника предсказания содержимого буфера на основе анализа вр..."	+4 +/–
	Сообщение от Аноним (??) on 09-Май-14, 02:15
	520*N всё-таки, потому что чтобы точно оценить разницу времени исполнения учитывая параллельно выполняющиеся задачи и другие факторы нужно много больше 1 попытки. Но таки да, сложность всё равно деградирует с экспоненциальной до линейной.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	46. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 14:47
	> 520*N всё-таки, Ну да, как-то так. Кстати не в тему, но по общей логике очень похоже на взлом WPS. Там, конечно, бестолковость в протоколе, но - именно такого плана.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	99. "Техника предсказания содержимого буфера на основе анализа вр..."	–2 +/–
	Сообщение от Аноним (??) on 10-Май-14, 12:46
	нудк, обфускации в линуксе - практически не было(две наивные вещи были, по-дефолту и все). все из-за лобби и троллинга Линуса против "маструбирующих на безопасность" всех и вся, работу которых он либо не силен оценить, либо у него свой(или тех от кого он зависит)интерес против.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Техника предсказания содержимого буфера на основе анализа вр..."	+6 +/–
Сообщение от asavah (ok) on 09-Май-14, 00:25
ожидать релиза новой версии libastral.so ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Техника предсказания содержимого буфера на основе анализа вр..."	+12 +/–
Сообщение от Аноним (??) on 09-Май-14, 00:48
> будет сигнализировать об успешности подбора первого байта На третий день Зоркий Глаз заметил что у сарая нет стены. В смысле, все кто хоть немного интересовался криптографией - уже давно в курсе что memcmp() использовать для вещей типа проверки паролей и прочего - не айс. Как раз вот поэтому вот. А редхат сказочно откапитанил, да :).
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	11. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 02:48
	> - не айс. Как раз вот поэтому вот. А редхат сказочно > откапитанил, да :). редхат предложил с опцией "-D_FORTIFY_SOURCE=2" делать memcmp более защищённым,  и в чём капитанство ?
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	21. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 09:01
	Не капитанство, а слоупочество. Даже в дебиане это уже в стейбле по умолчанию, а в генте ещё лет 5 назад было.
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	41. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 13:39
	И что в Debian? Защищённый memcmp? Вы ничего не попутали?
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	47. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 14:50
	> И что в Debian? Защищённый memcmp? Вы ничего не попутали? Капитанство и слоупочество - в том что кому оно было надо - уже много лет знали что memcmp в криптографии использовать *НЕЛЬЗЯ*. По именно этим причинам. И даже если в каком-то редхате это починят - кроме него есть туева хуча платформ где это не так, поэтому любой уважающий себя криптографический софт сам делает свою функцию сравнения которая всегда завершается за фиксированное время. Ну то-есть делается сравнение вообще целиком всего input, независимо ни от чего, при несовпадении взводится флаг, при возврате отдается состояние этого флага - или совпало, или нет. Это менее оптимально по скорости но более стойко к атакам на времянки типа упомянутых.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	76. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 18:48
	>редхат предложил с опцией "-D_FORTIFY_SOURCE=2" делать memcmp более защищённым,  и в чём капитанство ? В том что защищенность покупается хоооорошим просадом в скорости ... А очрованные на всю шляпу РХ-ники предлагают юзать этот слоупок для всех тонн софта... Вместо того чтобы написать свою реализацию для криптодел ... Но юзать для гвоздей молоток а для шурупов - отвёртку - это не по RH-ному :)
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

6. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от Xasd (ok) on 09-Май-14, 01:21
> Например, если memcmp используется при сравнении ключа шифрования c входными данными, то атакующий может байт за байтом подобрать значение с которым осуществляется сравнение. а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp? кто именно (и кого?) заставляет ключи сравнивать именно через memcmp?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Техника предсказания содержимого буфера на основе анализа вр..."	–3 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 02:58
	> а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp? да йопт int memcmp(void *x, void *z, size_t n) {         struct timespec request, remain;         unsigned char a, b;         int count = 0;         request.tv_sec  = 0;         request.tv_nsec = 0;         for (; n--; x++, z++) {                 a = *(unsigned char *)x;                 b = *(unsigned char *)z;                 srand(time(NULL));                 request.tv_nsec += rand() % 1000000;                 clock_nanosleep(CLOCK_REALTIME, 0,&request, &remain);                 if (a != b) {                         return (a - b);                 }         }         return 0; } > кто именно (и кого?) заставляет ключи сравнивать именно через memcmp? В новости есть ссылка https://securityblog.redhat.com/2014/05/07/defeating-memory-.../ >> ... For a concrete example, the following piece of code from OpenVPN > >  /* Compare locally computed HMAC with packet HMAC */ >      if (memcmp (local_hmac, BPTR (buf), hmac_len)) >         CRYPT_ERROR ("packet HMAC authentication failed"); .
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	33. "Техника предсказания содержимого буфера на основе анализа вр..."	+2 +/–
	Сообщение от irinat (ok) on 09-Май-14, 12:20
	> clock_nanosleep Что, компьютеры стали слишком быстрыми? http://ru.thedailywtf.com/Articles/Uskoryayuschij-cikl.aspx
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	61. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Xasd (ok) on 09-Май-14, 15:48
	надеюсь за правду эти "ускоряющие циклы" ни кому в голову не придёт вставлять
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	63. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 15:53
	> надеюсь за правду эти "ускоряющие циклы" ни кому в голову не придёт > вставлять за правду — вряд ли. а за деньги — запросто.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	48. "Техника предсказания содержимого буфера на основе анализа вр..."	+4 +/–
	Сообщение от Аноним (??) on 09-Май-14, 14:53
	> да йопт Что это за буита, павлин? А просто сравнить весь input целиком и взвести флаг если не совпало, а потом вернуть флаг - это слишком просто, да? Хрена себе у благородного дона художества. Иди дельтаплан построй - хочу посмотреть что у тебя с таким подходом получится :).
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	56. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 15:05
	> Что это за буита, павлин? А просто сравнить весь input целиком и > взвести флаг если не совпало, а потом вернуть флаг - это > слишком просто, да? да. намекну: нужно как минимум два цикла.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	84. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 19:20
	> да. намекну: нужно как минимум два цикла. А зачем? Гоняем цикл, прописываем в нем флаг. Тезис о том что присвоение флагу одного значения занимает больше или меньше значения чем другого - конечно имеет право на жизнь, но это мы уже лезем глубоко в недра оптимизаторов компилятора и придется асмовые портяны смотреть. Если это реально беспокоит, можно сделать единственную рандомную задержку при возврате, а-ля каркуша, например. Чисто технически, загрузка в регистр проца что 7 что 10 (допустим, 7 означает что все пока совпадает, а 10 - что не совпало) занимает сама по себе одинаковое время (по крайней мере, причин почему бы это было не так - изначально нет). Еще - может, ты от cache hit/cache miss хотел защититься? В случае обычного сравнения это вроде пофигу, т.к. время возврата не несет полезной информации о причинах почему оно такое, в отличие от оригинального memcmp, время выполнения которого пропорционально позиции на которой началось несовпадение, что можно померять. Бывают брейнфакнутые случаи, типа scrypt, у которого известный недостаток - характер доступа к памяти зависит от пароля и в результате cache hit/cache miss потенциально теряет информацию о исходном ключе. Но в случае просто сравнения - нельзя ли пояснить млдель угрозы от которой делается защита?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	90. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 19:27
	вот чтобы не лезть глубоко и получить более-менее амортизированное время без копания в асме, проще всего сделать два цикла с двумя флажками.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	91. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 19:27
	p.s. с одним циклом можно *попытаться* точнее определить, какой именно байт не совпал, если чо.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	103. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Xaionaro (ok) on 12-Май-14, 09:50
	> А просто сравнить весь input целиком и взвести флаг если не совпало, а потом вернуть флаг - это слишком просто, да? К сожалению, современные процессы работают очень хитро. И лично я не уверен, что при таком алгоритме нельзя будет повторить такого рода атаку. Например, вполне ненулевая вероятность, что timing будет отличаться из-за работы кеш-а. Нужно изучать этот вопрос внимательнее. А вообще, мне не нравится идея усилять memcpy в FORTIFY. Я его с какого-то времени начал использовать почти везде, а у меня нет нигде кода, требующего защищённого memcpy. А даже если был бы, я бы использовал отдельную реализацию (не вижу смысла тормозить весь код из-за этого).
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	31. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от irinat (ok) on 09-Май-14, 12:15
	> а нельзя например при сравнивании ключей -- использовать другую функцию нежели memcmp? В openssl есть для этого CRYPTO_memcmp(), например. Но бывает так, что авторы кода по недосмотру используют memcmp. Вот от них и пытаются защищаться. Где-то проскакивала информация, что в DRM у консоли Wii использовалась strcmp вместо memcmp. Вот это был фейл.
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	49. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 14:55
	> Где-то проскакивала информация, что в DRM у консоли Wii использовалась strcmp вместо > memcmp. Вот это был фейл. А у Сони вообще рандом был не рандомным нифига, что позволило народу посчитать приватный ключ из-за особенности применяемого алгоритма на основе эллиптических кривых :). Читать факин мануалы на применяемые алгоритмы торгаши и DRMщики и их cpaныe наймиты не любят :).
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	78. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 18:55
	> В openssl есть для этого CRYPTO_memcmp(), например. Но бывает так, что авторы > кода по недосмотру используют memcmp. Вот от них и пытаются защищаться. Irinat - ты мужчина? Если так давай ко мы тебя кастрируем, чтоб ты кого не снасильничал. Ничего личного - просто "от них и пытаются защищаться" же. Ещё раз - в криптософте поведение стандартной memcmp() вызывает проблему (а в остальном софте - вызывает восторг :) ... значит и надо криптописателей снабдить медленной но в этом смысле надёжной финкцией, а всем остальным оставьте БЫСТРУЮ!
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

7. "Техника предсказания содержимого буфера на основе анализа вр..."	–1 +/–
Сообщение от Аноним (??) on 09-Май-14, 02:03
Интересно, а специалистам из редхата не приходило в голову, что подобная атака требует больше вычислительных ресурсов, чем простой подбор ключа?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	13. "Техника предсказания содержимого буфера на основе анализа вр..."	+4 +/–
	Сообщение от Аноним (??) on 09-Май-14, 03:00
	> Интересно, а специалистам из редхата не приходило в голову, что подобная атака > требует больше вычислительных ресурсов, чем простой подбор ключа? Думаю нет, посколько они образованные люди в отличие от вас и разницу между O(2^N) и (N) видят.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	50. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 14:55
	> требует больше вычислительных ресурсов, чем простой подбор ключа? Щаз. Вон WPS почти так и разломали - последовательно подбирая цифры по одной :).
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	66. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Xasd (ok) on 09-Май-14, 17:04
	ну вообще -- при взломе WPS нет необходимости анализировать время. там просто две группы цифр. каждую из этих двух групп -- подбираем отдельно (сначало первую потом вторую). кстате взлом WPS работает только в том случае если WiFi-точка отвечает разными ответами взависимости от того в какой из двух групп ошибка (многие современные WiFi-точки так уже не делают).
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	79. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 19:03
	> ну вообще -- при взломе WPS нет необходимости анализировать время. Да, однако логика последовательного подбора по цифрам - как раз в духе этого самого. > каждую из этих двух групп -- подбираем отдельно (сначало первую потом вторую). Насколько я помню, одну подбирают целиком, вторую по отдельным цифрам, что как раз очень даже ололо. > современные WiFi-точки так уже не делают). Ну да, конечно, известный бэкдор - это не айс!
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	102. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от I11a on 10-Май-14, 18:07
	Там 8 десятичных разрядов, первая группа из 4 разрядов проверяется отдельно от второй. Однако 8-й разряд последовательности - есть функция от первых семи, т. о. во второй группе надо перебирать лишь три разряда. Итого 11000 вариантов для полного перебора, а в среднем - 5500, что совсем плохо. Почему WPS придумали именно таким - для меня большая загадка. Да, потом разработчики оборудования понадобавляли всяких костылей для усложнения атаки, но от этого не стало сильно лучше.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

9. "Техника предсказания содержимого буфера на основе анализа вр..."	–2 +/–
Сообщение от pavlinux (ok) on 09-Май-14, 02:16
> Устойчивое увеличение времени При условии, что время компьютера устойчиво, а то это как секс в гамаке - попадёшь-непопадёшь.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Техника предсказания содержимого буфера на основе анализа вр..."	+2 +/–
	Сообщение от Аноним (??) on 09-Май-14, 14:56
	> При условии, что время компьютера устойчиво, а то это как секс в > гамаке - попадёшь-непопадёшь. А можно просто туда-суда пару тысяч раз, потом уже статистика - залетела/не залетела :).
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Техника предсказания содержимого буфера на основе анализа вр..."	+7 +/–
Сообщение от Аноним (??) on 09-Май-14, 02:29
> Включение по умолчанию подобного варианта функции в Glibc рассматривается как маловероятное (с позиции производительности, текущий вариант memcmp предпочтительней), поэтому как наиболее реалистичный вариант рассматривается возможность задействования защищённой версии memcpm при сборке Glibc с опцией "-D_FORTIFY_SOURCE=2". что-то в redhat понабрали каких-то тупых наркоманов, каждая новость хлеще другой. Вместо того, чтобы сделать отдельную ф-ю специально предназначенную для криптографии и аутентификации, они решили притащить эти костыли в библиотеку общего назначения. Идиоты.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Техника предсказания содержимого буфера на основе анализа вр..."	–1 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 04:28
	> они решили притащить эти костыли в библиотеку общего назначения. Идиоты. Девиз онанимных оналитегов: Новость не читай - коммент пиши!!! https://sourceware.org/ml/libc-alpha/2014-01/msg00763.html Ща конечно заплачет "- этого нет русской новости,..." :`( Неидиот, английский-то знаешь? Упрощу задачу, для твоего IQ можешь перевести последние три слова. > We implemented the first approach, based on BSWAP, on top of the GNU C library > implementation of memcmp that is targeted at the current line of x86 CPUs which > have fast unaligned loads. It turned out that the cost was mostly negative. For > example, sorting a random permutation of /usr/share/dict/words using qsort was > about ten per cent faster than before .
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	80. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 19:05
	>> они решили притащить эти костыли в библиотеку общего назначения. Идиоты. > Девиз онанимных оналитегов: Новость не читай - коммент пиши!!! А то ! :) > https://sourceware.org/ml/libc-alpha/2014-01/msg00763.html > Ща конечно заплачет "- этого нет русской новости,..." :`( А ещё тот кусок овсокода который ты запостил - тоже не о том что по ссылке :) В общем понятно. У меня из нормальных остался только один аргумент против. То что они предложили - только для Ынтелей\(амд?) работает. На армах к примеру она так и будет опасной. Но юзать будут то что в мэйнстриме, а мэйнстрим 99,999% на ...
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

14. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от pavlinux (ok) on 09-Май-14, 04:25
> Техника атаки основана на том, что memcmp завершает выполнение после первого несовпадения Да нивапрос, будем проверять ВСЁ!!! int memcmp_s(void *x, void *y, size_t n) {         unsigned char a, b;         unsigned char ret;         for (ret = 0; n--; x++, y++) {                 a = *(unsigned char *)x;                 b = *(unsigned char *)y;                 if (a != b && ret == 0) {                         ret = (a - b);                 }         }         return (ret != 0 ? ret : 0); } > т.е. атакующий может передать случайный набор данных и изменять значение > первого байта, отслеживая время выполнения операции.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	16. "Техника предсказания содержимого буфера на основе анализа вр..."	+2 +/–
	Сообщение от Аноним (??) on 09-Май-14, 05:19
	> >  return (ret != 0 ? ret : 0); > Я, конечно не мастер, и вообще мне страшно писать на такие сайты для взрослых, но что делает эта строка? проверяет равен ли ret нулю, если не равен возвращает ret иначе ноль? Может сократить до return ret . Или мы ret не очень доверям???
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Техника предсказания содержимого буфера на основе анализа вр..."	–3 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 05:28
	> Или мы ret не очень доверям??? Выбирай по-вкусу: 1. Преждевременная оптимизация залог ошибок! 2. Программирование "сверху-вниз". 3. Это идея, а не код. Домашнее задание по оптимизации:          Сделать туже логику, но без переменной ret;   Всех С Днём Победы!!!!
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	24. "Техника предсказания содержимого буфера на основе..."	–1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 09:21
	> Домашнее задание по оптимизации: >          Сделать туже логику, > но без переменной ret; угу. потому что сейчас там ошибка.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	71. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Led (ok) on 09-Май-14, 17:53
	>> Или мы ret не очень доверям??? > Выбирай по-вкусу: > 1. Преждевременная оптимизация залог ошибок! > 2. Программирование "сверху-вниз". > 3. Это идея, а не код. 4. Говнокод
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	74. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 18:27
	> 4. Говнокод судя по тому, как он этот говнокод защищает, не желая признавать ошибки — это не просто говнокод, это выстраданый ночами кусок кода; лучшее, на что павлуша способен, видимо. надеюсь, мне никогда не придётся увидеть худшее.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	75. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от Led (ok) on 09-Май-14, 18:43
	>> 4. Говнокод > судя по тому, как он этот говнокод защищает, не желая признавать ошибки > — это не просто говнокод, это выстраданый ночами кусок кода; лучшее, > на что павлуша способен, видимо. надеюсь, мне никогда не придётся увидеть > худшее. Ты что, первый раз такое от него увидел? павлуша всегда был говнокодером - ничем он не удивил и в этот раз.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	77. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 18:52
	по-моему, раньше он свою чушь так яростно не защищал. или я внимания не обращал, или напился на праздник.
	Ответить | Правка | ^ к родителю #75 | Наверх | Cообщить модератору

	32. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от irinat (ok) on 09-Май-14, 12:18
	> Может сократить до return ret return !!ret;
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	34. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 12:21
	>> Может сократить до return ret > return !!ret; снова ошибка. man memcmp.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	35. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от irinat (ok) on 09-Май-14, 12:36
	>>> Может сократить до return ret >> return !!ret; > снова ошибка. man memcmp. Неа, ошибки нет. return ret можно заменить на return !!ret, если хочется редуцировать именно до 0 или 1, и это абсолютно корректно. Это демонстрация трюка на случай, если кто-то про него не знает. Участвовать в соревнованиях по переписыванию memcmp или других библиотечных функций я не собираюсь. Для занятий на досуге есть другие, более интересные и более нужные мне задачи.
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 12:38
	функция называется memcmp_s(). функция ЯВНО пытается (хоть и неправильно) возвращать именно то, что возвращает memcmp(). твой код поломал её ещё больше. но «ошибки нет», ага.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	37. "Техника предсказания содержимого буфера на основе..."	+3 +/–
	Сообщение от irinat (ok) on 09-Май-14, 13:06
	> твой код поломал её ещё больше. но «ошибки нет», ага. Обрати внимание на то, что ret объявлен как unsigned char. Может всё-таки обратишь своё стремление искать ошибки в более конструктивное русло? В мире куча open source проектов, которые не отказались бы от ещё одной пары глаз, просматривающих код на предмет багов. А искать ошибки в наколенных поделиях на форумах это, знаешь ли, как-то мелко.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 13:20
	>> твой код поломал её ещё больше. но «ошибки нет», ага. > Обрати внимание на то, что ret объявлен как unsigned char. обрати внимание на то, что про уже наличествующую до тебя ошибку я сказал раньше. > Может всё-таки обратишь своё стремление искать ошибки в более конструктивное русло? спасибо, без твоего ценного указания я и не догадывался, как можно применить моё умение видеть ошибки. но ты открыл мне глаза!
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	43. "Техника предсказания содержимого буфера на основе..."	–1 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 14:08
	Фишка в том, что возвращаемый результат сохраняется один раз, но проверяются все байты. if (a != b && ret == 0) {               ret = (a - b); а не какого цвета ret И эта, оба, хвать здипить покажите ваш код!
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	44. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 14:18
	> Фишка в том, что возвращаемый результат сохраняется один раз, но проверяются все > байты. фишка в том, что у тебя неправильно возвращает результат: по спекам должно возвращать отрицательное в соответствующем случае, а у тебя никогда отрицательного результата не будет. это раз. два: время исполнения всё равно зависит от значений, хоть и не так сильно. три: утекают данные о точной разности. ну, и всякие мелочи типа const, __restricted и ты пы. так что фишка в том, что показанная фигня не особо лучше memcmp(), да ещё и с ошибками. > И эта, оба, хвать здипить покажите ваш код! зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	54. "Техника предсказания содержимого буфера на основе..."	–1 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 15:02
	> два: время исполнения всё равно зависит от значений, хоть и не так сильно. Да ты чо???!!! if ( 55 != 47 ) будет отличатся от if ( 56 != 48 ) ??? :) >> И эта, оба, хвать здипить покажите ваш код! > зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь. хвать здипить покажите ваш код! маны я и без тебя наизусть знаю
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	59. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 15:08
	>> два: время исполнения всё равно зависит от значений, хоть и не так сильно. > Да ты чо???!!! а ты подумай про неполное вычисление условий и про записи в память, гыгы. и про то, что это неплохо бы амортизировать хотя бы двумя циклами. > хвать здипить покажите ваш код! зачем? тебя же тоже никто за руку не тянул, ты сам свою лапшу сюда вывалил. вот и обтекай теперь. > маны я и без тебя наизусть знаю тем не менее, в реализации облажался.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	64. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от irinat (ok) on 09-Май-14, 16:27
	> покажите ваш код! int memcmp_s(const void *s1, const void *s2, size_t n) {     return CRYPTO_memcmp(s1, s2, n); }
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	70. "Техника предсказания содержимого буфера на основе..."	–3 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 17:21
	>> покажите ваш код! > int > memcmp_s(const void *s1, const void *s2, size_t n) > { >     return CRYPTO_memcmp(s1, s2, n); > } Пля, толант.
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	73. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 18:25
	> Пля, толант. его код — в отличие от твоего — без ошибок.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	86. "Техника предсказания содержимого буфера на основе..."	–2 +/–
	Сообщение от Аноним (??) on 09-Май-14, 19:24
	> его код — в отличие от твоего — без ошибок. Глядя на авторов openssl я бы на него 100 баксов не поставил...
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	88. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 19:26
	>> его код — в отличие от твоего — без ошибок. > Глядя на авторов openssl я бы на него 100 баксов не поставил... а это уже совсем других людей ошибка. нельзя же считать, что ошибка именно в коде, который использует некие библиотечные функции, если в самих функциях ошибки.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	82. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 19:17
	>> покажите ваш код! >     return CRYPTO_memcmp(s1, s2, n); Ха-за :) Но - таки - ДА!
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	105. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от Xaionaro (ok) on 12-Май-14, 10:10
	>> покажите ваш код! > int > memcmp_s(const void *s1, const void *s2, size_t n) > { >     return CRYPTO_memcmp(s1, s2, n); > } Можно сделать static inline, чтобы уменьшить на одну обёртку. А ещё подумать на тему всяких "restrict"-ов. :)
	Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

	28. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Anonymouse on 09-Май-14, 10:12
	Достаточно угадать длину ключа и последний байт.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	58. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Anonymouse on 09-Май-14, 15:08
	>Достаточно угадать длину ключа и последний байт. Посмотрел на код еще раз, отменяетсяю
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	104. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Xaionaro (ok) on 12-Май-14, 10:04
	>> Техника атаки основана на том, что memcmp завершает выполнение после первого несовпадения > Да нивапрос, будем проверять ВСЁ!!!        if (a != b && ret == 0) {           ret = (a - b);     } Разное время выполнения в зависимости от того, "ret == 0" или нет. По сути ровно та же атака в силе, просто заметить увеличение/уменьшение времени выполнения становится сложнее. Чисто математически задача немного сложнее ведь, что все так пренебрежительно к ней относятся? :(
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	106. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 30-Май-14, 06:57
	> Чисто математически задача немного сложнее ведь, что все так пренебрежительно к ней > относятся? :( понекропостим: на самом деле именно memcmp() в криптографии нафиг не упёрся, нужен memequ(). то есть, тупо флажок «равно/не равно», причём точно в виде ноля и единицы, например. вот тут задача уже резко упрощается и решается буквально в две строки. а кто продолжает использовать memcmp() там, где надо memequ(), тот идиот, и к криптографии его подпускать вообще нельзя.
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

20. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от DV (ok) on 09-Май-14, 07:49
Странный подход. Так-то взломщик может неким путём подменить библиотеку с оной функцией на самописную и спокойно ломать ключ. Надо не на реализации конкретной функции в системе полагаться, а разрабатывать надёжные алгоритмы защиты, не допускающие подобного рода анализов. Обновлять memcmp -- это просто сооружать костыль. Задача системных функций -- выполнить свою работу как можно быстрее при как можно меньшем объёме памяти. С тем же успехом можно в Уголовный Кодекс принять закон, запрещающий анализ времени выполнения memcmp.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 09:08
	>взломщик может неким путём подменить библиотеку с оной функцией на самописную и спокойно ломать ключ Ну, как-бы, взломщик не сможет перезапустить демоны, проверящие ключи со своей LD_PRELOAD_PATH=..., не имя при этом рутовых прав.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	53. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 15:01
	а это и не обязательно делать. Достаточно пропатчить plt таблицу, не очень сложная операция
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	57. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 15:06
	> а это и не обязательно делать. Достаточно пропатчить plt таблицу, не очень > сложная операция правда, сделать это весьма проблематично, если у тебя рута нет, но когда такие мелочи смущали благородных донов?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	25. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 09:22
	если у человека уже есть рутовый доступ, то поздно пить боржоми. но часто это вовсе не так.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	100. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 10-Май-14, 12:48
	> Странный подход. Так-то взломщик может неким путём подменить библиотеку с оной функцией > на самописную и спокойно ломать ключ. Надо не на реализации конкретной > функции в системе полагаться, а разрабатывать надёжные алгоритмы защиты, не допускающие > подобного рода анализов. Обновлять memcmp -- это просто сооружать костыль. Задача > системных функций -- выполнить свою работу как можно быстрее при как > можно меньшем объёме памяти. С тем же успехом можно в Уголовный > Кодекс принять закон, запрещающий анализ времени выполнения memcmp. контроль целостности системы, с включенной реалтайм-частью - ведь никто не запрещает ставить ? Но НЕТУ этого на 99% серваков, тем не менее.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

23. "Техника предсказания содержимого буфера на основе анализа вр..."	–1 +/–
Сообщение от Аноним (??) on 09-Май-14, 09:11
>рассматривается возможность задействования защищённой версии memcpm при сборке Glibc с опцией "-D_FORTIFY_SOURCE=2" А не лучше ли использовать выбор времени исполнения варианта memcmp, например, установкой какой-либо глобальной переменной?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	26. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от zed_0xff on 09-Май-14, 09:42
	в любой непонятной ситуации - х*ячь глобальную переменную!!!111
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	27. "Техника предсказания содержимого буфера на основе..."	–1 +/–
	Сообщение от arisu (ok) on 09-Май-14, 10:07
	> в любой непонятной ситуации - х*ячь глобальную переменную!!!111 всегда так делаю, брат жив!
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	30. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 10:55
	>> в любой непонятной ситуации - х*ячь глобальную переменную!!!111 > всегда так делаю, брат жив! Пишешь с холодильника? :D
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	52. "Техника предсказания содержимого буфера на основе..."	–1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 14:58
	> Пишешь с холодильника? :D Ты там этого, потише. Уже есть холодильники с ведроидом, так что вы уже довыпендривались, фаготы.
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	65. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от anonymous (??) on 09-Май-14, 17:01
	>> в любой непонятной ситуации - х*ячь глобальную переменную!!!111 > всегда так делаю, брат жив! А как же этот, multi-threading?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	67. "Техника предсказания содержимого буфера на основе..."	+/–
	Сообщение от arisu (ok) on 09-Май-14, 17:11
	> А как же этот, multi-threading? а нас в ПТУ такому не учили.
	Ответить | Правка | ^ к родителю #65 | Наверх | Cообщить модератору

	83. "Техника предсказания содержимого буфера на основе..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 19:19
	>> А как же этот, multi-threading? > а нас в ПТУ такому не учили. Зато научили скакать :)
	Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

39. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
Сообщение от Аноним (??) on 09-Май-14, 13:22
Чтобы добиться устойчивого среднестатистического увеличения времени при нынешних скоростях процессоров и задержек сети - необходимо вбивать один и тот же пароль как минимум 1000 раз. Задержка сети - миллисекунды, задержка memcmp - наносекунды, полученные результаты все равно будут в рамках погрешности.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Техника предсказания содержимого буфера на основе анализа вр..."	+4 +/–
Сообщение от Нанобот (ok) on 09-Май-14, 13:37
вообще-то memcmp предназначена для сравнения данных. безопасность там не предусмотрена by design. если кому нужна безопасность, разумнее сделать что-то типа memcmp_slow_but_secure_fapfap и использовать её (но только не пихать её во все дыры чисто из принципа, а использовать её в тех местах, где это действительно нужно, а во всех остальных местах использовать memcmp)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
Сообщение от umbr (ok) on 09-Май-14, 13:45
Так они придут к тому, что каждый вызов любой функции будет сопровождаться цифровой подписью.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "Техника предсказания содержимого буфера на основе анализа вр..."	–3 +/–
	Сообщение от pavlinux (ok) on 09-Май-14, 14:24
	> Так они придут к тому, что каждый вызов любой функции будет сопровождаться > цифровой подписью. В правильных системах это, почти, так и есть. Не подпись, но аппаратный ключ. По крайней мере на всякие exec/open. А ещё есть VAX/Open/VMS там похожее by design
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

	55. "Техника предсказания содержимого буфера на основе анализа вр..."	+1 +/–
	Сообщение от Аноним (??) on 09-Май-14, 15:02
	прекрати бредить, обезъянка
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	68. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Xasd (ok) on 09-Май-14, 17:16
	> В правильных системах это, почти, так и есть. Не подпись, но аппаратный ключ. иногда мне так и хочется процитировать какую-нибудь фразу из очередного американского кино про суперсекретных агентов... типа: "IP-адрес зашифрован через RSA.. о боже! мне потребуется не менее 30 минут чтобы взломать его!"
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

	85. "Техника предсказания содержимого буфера на основе анализа вр..."	+/–
	Сообщение от Аноним (??) on 09-Май-14, 19:21
	> есть VAX/Open/VMS там похожее by design Это ты о чём? Чета не распарсил ....
	Ответить | Правка | ^ к родителю #45 | Наверх | Cообщить модератору

98. "Техника предсказания содержимого буфера на основе анализа вр..."	+2 +/–
Сообщение от bircoph (ok) on 10-Май-14, 10:13
Почему бы не оставить memcmp в покое и не добавить memcmp_crypto? Не вижу смысла терять производительность в тех приложениях и частях приложений, где нет необходимости защищать буфер.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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