forum.opennet.ru - "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." (82)

"Уязвимость в реализации функции memcpy для ARMv7 из состава ..."

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

"Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+/–
Сообщение от opennews (ok), 21-Май-20, 23:29
Исследователи безопасности из компании Cisco раскрыли детали уязвимости (CVE-2020-6096) в реализации предоставляемой в Glibc функции memcpy() для 32-разрядной платформы ARMv7. Проблема вызвана некорректной обработкой отрицательных значений параметра, определяющего размер копируемой области. Вызов memcpy() на системах ARMv7 с отрицательным размером приводит к некорректному сравнению значений и записи в области вне границ указанного буфера из-за использования ассемблерных оптимизаций, манипулирующих знаковыми 32-разрядными целыми числами... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53003
Ответить \| Правка \| Cообщить модератору

Оглавление

Наблюдаю в комментах непонимание, поэтому краткая справка для далёких от машинно, Ordu (ok), 10:33 , 22-Май-20, (41) +23

Гм Современное поколение программистов не знает что такое прямой, обратный и до, CAE (ok), 12:20 , 22-Май-20, (51) +6

эй потише там, смузихлеб вейпер тимлид (?), 12:41 , 22-Май-20, (52) +9
Программист - слишком громкое название для вебмакаки, там из образования книжка , Аноним (80), 05:13 , 24-Май-20, (80)
Ох уж эта русскоязычная терминология Конечно, современные программисты ее не зн, Аноним (86), 01:49 , 25-Май-20, (86)

Вообще-то никогда не равен, если x - отрицательное , Аноним (53), 13:54 , 22-Май-20, (53) +7

А, простите, перепутал операцию Да, имелось в виду - -x , Ordu (ok), 14:29 , 22-Май-20, (58) +1

Объяснил так объяснил Для далёких Попробую показать на пальцах для остальных, PnD (??), 14:26 , 22-Май-20, (56) +5

Даёшь троечную систему счисление , Аноним (72), 09:37 , 23-Май-20, (72) +1

Такая даже была на заре развития компьютеров, но популярности не снискала, тольк, Аноним (-), 05:23 , 24-Май-20, (81)

Второе дополнение Обычно, это называется просто дополнительный код числа и , BSA (?), 15:33 , 23-Май-20, (74)

да он только вчера книжку прочитал, ещё не все термины запомнил, вероятно, имело, Аноним (84), 07:00 , 24-Май-20, (84)

С древних времён у меня вызывало недоумение кто и зачем всякие memcpy определ, InuYasha (?), 17:12 , 23-Май-20, (77)

На самом деле кабздец - вообще не там Проблема в том что когда делается математ, Аноним (-), 05:28 , 24-Май-20, (82)

Всем В debug-версии И ещё горы ASSERT-ов и логов Отладил - и можно в релиз, г, InuYasha (?), 11:11 , 24-Май-20, (85)
нужна аппаратная поддержка корректноститипа условный ассемблер add Ax,Bx слож, Аноним (90), 09:34 , 27-Май-20, (90)

звучит страшновато, native76 (ok), 23:29 , 21-Май-20, (1) –1

Хорошо звучит Можно будет рутовать ARMv7 устройства, а затем обновлять глибси , BSDun (?), 23:38 , 21-Май-20, (2) +11

Всякую встроенку которая никогда не обновится теперь можно ломать , Аноним (10), 00:21 , 22-Май-20, (10) +4

Во всякой встроенке скорее всего будет другая libc , Аноним (17), 00:57 , 22-Май-20, (17) +3

Вот, кстати, да, про другие либы что-нибудь пишут типа uClibc ng , sabretoothedhamster (?), 15:06 , 28-Май-20, (91)

Welchia 2 0, Аноним (60), 17:49 , 22-Май-20, (60)
Надо только сначала найти ARMv7 устройство с более чем 2гб памяти , погроммист (?), 00:29 , 23-Май-20, (68) +2

Если у тебя в memcpy приходит контролируемое удалённым пользователем значение , Ivan_83 (ok), 00:58 , 22-Май-20, (18) +2

Вы Чукчи Писатели уже раздражать начинаете Черным по бежевому написано же , sfdsf (?), 08:58 , 22-Май-20, (32) +7
Во времена мамонтов были процессоры в которых беззнаковая арифметика была реализ, Аноним (34), 09:23 , 22-Май-20, (34) –3

То ли ещё было во времена грекоримлян , Анон123 (?), 14:07 , 22-Май-20, (54)

в memcpy, внезапно, частенько приходят данные пользователя - и длинна их контрол, пох. (?), 11:51 , 22-Май-20, (47) +1

Что-то непонятное на скриншоте Вроде речь идёт о системе, основанной на GLibc, , Аноним (3), 23:47 , 21-Май-20, (3) +2

Что тут непонятно, запустили netcat на винде для атаки на внешний хост по сети , Аноним (5), 23:54 , 21-Май-20, (5) +3
на скриншоте показано подключение к сокету, который уже был открыт после экслоит, Sw00p aka Jerom (?), 23:55 , 21-Май-20, (6)
Взлом системы с уже открытым портом, на котором уже висит рут-шелл с помощью ван, Аноним (38), 10:11 , 22-Май-20, (38)

Кул стори, бро , териванов (?), 21:01 , 22-Май-20, (67) +1

Стоит отметить, что и Android проблема тоже не затрагивает ввиду использования b, Аноним (4), 23:53 , 21-Май-20, (4)

А какая связь bionic и glibc GNU libc Это совершенно разные libc , Аноним (5), 23:56 , 21-Май-20, (7)

ой, прочитал не затрагивает как затрагивает , Аноним (5), 23:58 , 21-Май-20, (8)

Не знает тот, кто не прочитал статью, а строчит комменты , gogo (?), 00:30 , 22-Май-20, (11) +2
а жаль , vitalif (ok), 00:43 , 22-Май-20, (14) +2
Скрыто модератором, Аноним (15), 00:57 , 22-Май-20, (15) –8

Скрыто модератором, Аноним (21), 01:40 , 22-Май-20, (21) –1

Скрыто модератором, Аноним (35), 09:36 , 22-Май-20, (35) +4

Скрыто модератором, Аноним (21), 10:14 , 22-Май-20, (40) –2
Скрыто модератором, Школьник (ok), 14:16 , 22-Май-20, (55) –1
Скрыто модератором, с (?), 15:30 , 22-Май-20, (59) –3
А чем Макось и её пользователи лучше Тоже закрытая хрень И кому до того какое , Аноним (3), 18:40 , 22-Май-20, (62) +1

Ну вот, а Google винили в NIH-синдроме Не даром они и boring ssl сделали, и мно, Anonn (?), 10:47 , 23-Май-20, (73)

Совершенно непонятная новость У memcpy аргумент имеет тип size_t как он в безан, Аноним (24), 03:42 , 22-Май-20, (24) –4

В коде использовались ассемблерные вставки с инструкциями для работы со знаковым, Аноним (5), 08:24 , 22-Май-20, (29) +1

Нет там вставок, функция целиком на ассемблере написана , Аноним (30), 08:50 , 22-Май-20, (30) –2

а еще у математиков бывают пустые множества, прикинь какая боль, Жека Воробьев (?), 14:27 , 22-Май-20, (57) +2

Боль - это пытаться объяснить вебмакаке как работает рид-соломон , Аноним (-), 05:31 , 24-Май-20, (83)

Не МАКАКА А МИСТЕР ГОРИЛЛА Понял, да А ты УДАВ УЗЛОВАТЫЙ , cool29 (?), 12:54 , 25-Май-20, (88) +2

Предупреждали - не делать в коде С ассемблерных системно зависимых вставок , Аноним (26), 06:21 , 22-Май-20, (26) –5

Увы, если в коде эмбедовки делать это не делать - она ворочаться будет как Windo, Онаним (?), 08:21 , 22-Май-20, (28)

Согласен Сам таким баловался, когда по просьбе знакомых докторов вьвер для томо, Аноним (26), 09:51 , 22-Май-20, (36) –1
Не запустится 80486 на 25 МГц 8212 это SX, без сопроцессора, и более чем уве, Аноним (37), 09:51 , 22-Май-20, (37) +1

Сопроцессоры для 486 SX выпускались отдельно https ru wikipedia org wiki Inte, Zenitur (ok), 11:22 , 22-Май-20, (43)

Ты на Avito покупаешь или продаёшь , Аноним (3), 18:46 , 22-Май-20, (64)

Вот , Онаним (?), 11:45 , 22-Май-20, (45)
Am486 DX-25 был вполне себе с сопром Более того, двухштучник сопра и P5 не треб, Онаним (?), 11:53 , 22-Май-20, (48) +2

Кто и кого предупреждал , Аноним (3), 18:42 , 22-Май-20, (63)

встроенный в автомобильные информационные системы http-сервер блин, дайте мне, Аноним (27), 07:13 , 22-Май-20, (27) +2

В принципе, и этот глобус - достаточно большой, чтобы хватило на всех веб-макак , пох. (?), 12:00 , 22-Май-20, (49) +1

Веб-макаками уже стали ассемблерные программисты под арм А вообще, даже забавно, Lex (??), 08:11 , 23-Май-20, (71) +1

Было бы чего плохого , iPony129412 (?), 07:30 , 25-Май-20, (87)

В новости ошибка ВСЯ ФУНКЦИЯ ЦЕЛИКОМ НА АССЕМБЛЕРЕ Нет никаких вставок http, Аноним (30), 08:55 , 22-Май-20, (31) –3

Директивы препроцессора на С Хотя не знаю, можно ли препроцессор считать часть, Аноним (39), 10:12 , 22-Май-20, (39)

Ага, с прототипом где явно указано size_t , Sw00p aka Jerom (?), 11:50 , 22-Май-20, (46) +1
Нельзя Препроцессор о синтаксисе C не знает, он просто тупо подставляет Поэтом, Аноним (3), 18:49 , 22-Май-20, (65)
Во многих ассемблерах были макросы TASM, MASM , но в линуксовом их нет и добави, Аноним (30), 06:02 , 23-Май-20, (70)

Есть там макросы macro endm Они позволяют создавать макросы, используемые как, BSA (?), 15:39 , 23-Май-20, (75)

Три человека, что поставили минус Всё теперь ясно о компетентности комментаторо, Аноним (30), 05:54 , 23-Май-20, (69) –2

Размер копируемой должен быть от 2 Гб, для того, чтобы получить отрицательное зн, ЛениваяЖ (?), 09:05 , 22-Май-20, (33) +2

2ГБ чтобы выйти на минус и ещё 2ГБ чтобы указатель сместить в конец первых 2ГБ , Аноним (5), 11:26 , 22-Май-20, (44) +1
и вот тебе жалко 2г нулей ради хорошего дела , пох. (?), 12:02 , 22-Май-20, (50)
Если послать через сжатый канал например, http gzip , то объемы будут значитель, BSA (?), 15:41 , 23-Май-20, (76) +1

Разработчики glibc в принципе не умеют в форматирование кода Что там за каша , Аноним (42), 11:17 , 22-Май-20, (42)

Это всеми любимый gnu coding style - , vle (ok), 23:52 , 26-Май-20, (89)

нестрашно, добрый вендор всегда оберегает тебя через TrustZone бггг, mos87 (ok), 18:36 , 22-Май-20, (61) +1
просто надо было писать на rush а параметры передавать через https json, Аноним (66), 18:55 , 22-Май-20, (66) –1
Какой идиот додумался для РАЗМЕРА использовать знаковое целочисленное , Аноним (78), 20:56 , 23-Май-20, (78)

Кто-то из POSIX Глупые наверное, и конвенции сишные глупые выдумали Совсем дур, Аноним (21), 00:39 , 24-Май-20, (79) +1

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

41. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +23 +/–

Сообщение от Ordu (ok), 22-Май-20, 10:33

Наблюдаю в комментах непонимание, поэтому краткая справка для далёких от машинного представления чисел.
Знаковые числа и беззнаковые -- это просто наборы бит. Никто не запрещает один и тот же набор бит интерпретировать как знаковый или беззнаковый. Чаще всего, получается примерно такое соответствие:
0 <=> 0
1 <=> 1
...
2^31-2 <=> 2^31-2
2^31-1 <=> 2^31-1
2^31 <=> -2^31
2^31+1 <=> -2^31+1
...
2^32-1 <=> -1
Для знакомых с группами вычетов Z/nZ: знаковые и беззнаковые -- это одна и та же факторизация множества целых чисел, но представители классов выбраны разные. Это как группу Z/3Z можно представлять как множество элементов {0, 1, 2}, а можно как {-1, 0, 1}.
(Кстати обратите внимание, если не сталкивались с этим раньше: abs(abs(x)) не всегда равен x. -2^31 -- это самое большое по модулю число, и оно одно, для него нет положительной пары. Бага системы кодирования чисел, которая иногда становится занозой в заднице).
При этом, что удачно, при таком подходе к кодированию целых, можно использовать одни и те же операции сложения/вычитания для работы как со знаковыми числами, так и с беззнаковыми. Но когда речь заходит об умножении, делении, сравнении чисел, на уровне машинных команд код начинает различаться, в зависимости от знаковости аргументов.
Обсуждаемый бажный memcpy работал с size как со знаковым числом. Для значений меньше чем 2^31 это работало как надо, потому что если такие беззнаковые числа интерпретировать как знаковые, то они по смыслу будут тем же самым. А вот для значений больше либо равных 2^31 уже не работало, потому что если их интерпретировать как знаковые, то получатся отрицательные числа.
И собственно эксплуатация бага свелась к тому, чтобы добиться передачи в memcpy буфера с размером в 2Gb или больше. То есть код, использующий memcpy может быть 100% безбажным, и тем не менее эксплоит будет возможен, при наличии такой бажной реализации memcpy.

Ответить | Правка | Наверх | Cообщить модератору

51. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +6 +/–

Сообщение от CAE (ok), 22-Май-20, 12:20

Гм. Современное поколение программистов не знает что такое прямой, обратный и дополнительный код? :))

Ответить | Правка | Наверх | Cообщить модератору

52. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +9 +/–

Сообщение от смузихлеб вейпер тимлид (?), 22-Май-20, 12:41

эй потише там

Ответить | Правка | Наверх | Cообщить модератору

80. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (80), 24-Май-20, 05:13

Программист - слишком громкое название для вебмакаки, там из образования книжка по пэхапэ прочитанная за неделю. И все, можно идти твАрить.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

86. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (86), 25-Май-20, 01:49

Ох уж эта русскоязычная терминология. Конечно, современные программисты ее не знают.
По-английски это называется ones’ complement.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

53. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +7 +/–

Сообщение от Аноним (53), 22-Май-20, 13:54

> abs(abs(x)) не всегда равен x.
Вообще-то никогда не равен, если x - отрицательное.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

58. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Ordu (ok), 22-Май-20, 14:29

А, простите, перепутал операцию. Да, имелось в виду -(-x).

Ответить | Правка | Наверх | Cообщить модератору

56. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +5 +/–

Сообщение от PnD (??), 22-Май-20, 14:26

Объяснил так объяснил. Для далёких. Попробую показать "на пальцах" для остальных.
Число внутри 32-разрядного процессора состоит из 32 записанных друг за другом "битов", содержащих либо "0" либо "1".
Т.о. привычный нам ноль — это 32 бита с "0" внутри процессора.
Дальше будем полагать что числа пишутся/читаются в привычном нам порядке, слева направо. Бывает и наоборот. С какого конца читать — указывают в названии архитектуры процессора (big|litle endian).
Единица в самом правом разряде "00000000000000000000000000000001" соответствует 2º (в степени 0), т.е. = 1. Следующие биты справа налево кодируют 2¹=2, 2²=4 и т.д.
Двоичное число "01000000000000000000000000000000" (единица в 31-м разряде) соответствует 2³º= 1073741824 (десятичное представление).
Чтобы записывать отрицательные числа, договорились использовать 32-й (самый левый) бит.
При этом число "10000000000000000000000000000000" = 2³¹ кодирует самое маленькое (для 32-разрядного процессора) число -2³¹. И оно уникально, т.к. соответствующее ему положительное число в 32 разряда не лезет (или надо знак убирать).
Остальные биты при этом обозначают сколько надо прибавить к -2³¹. То есть:
"10000000000000000000000000000001" = -2³¹ + 1 = -2147483647
"11111111111111111111111111111111" = -1 (прибавили всё кроме последней единицы)
В этом месте нетрудно заметить, что операция сложения чисел со знаком ничем не отличается от той же самой операции "без знака". Например, "-1 + 1":
"11111111111111111111111111111111" + "00000000000000000000000000000001" = "00000000000000000000000000000000".
* Разряды переполнились и обнулились. Не хуже чем на старых арифмометрах.
** В умных книжках такой способ представления отрицательных чисел называется "второе дополнение": в первом дополнении число "переворачивают": например из "1100" получается "0011". Во втором — добавляют 1 (получим "0100"). Но это выносит неокрепший моск и напрочь убивает понимание как с этим обращается процессор.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

72. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (72), 23-Май-20, 09:37

Даёшь троечную систему счисление!!!

Ответить | Правка | Наверх | Cообщить модератору

81. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (-), 24-Май-20, 05:23

Такая даже была на заре развития компьютеров, но популярности не снискала, только тогда уж "троичная".

Ответить | Правка | Наверх | Cообщить модератору

74. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от BSA (?), 23-Май-20, 15:33

"Второе дополнение"? Обычно, это называется просто "дополнительный код числа" и он именно от "дополнения единицей". Число не "переворачивают", а инвертируют: 0 заменяют на 1, а 1 на 0.
Ваше объяснение тоже не сильно лучше. А местами просто вводит в заблуждение.

Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

84. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (84), 24-Май-20, 07:00

да он только вчера книжку прочитал, ещё не все термины запомнил, вероятно, имелось в виду "дополнение до двух"

Ответить | Правка | Наверх | Cообщить модератору

77. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от InuYasha (?), 23-Май-20, 17:12

С древних времён у меня вызывало недоумение: кто и зачем всякие memcpy() определяет в signed-типами?...
Ну и всякие int count, int size и т.п. Проверки на -1 - не оправдание - это симптом уже случившегося кабздеца.

Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

82. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (-), 24-Май-20, 05:28

На самом деле кабздец - вообще не там. Проблема в том что когда делается математика - она делается в регистрах, как таковое, железо в общем виде не сигналит софту аппаратными исключениями и т.п. если вдруг результат счета оказался больше регистра и старший бит был обрублен, в общем то, скорее даже железом. Ну или абсракциями рядом.
Как максимум процессоры взводят флаг состояний. Но если после каждой операции проверять эти флаги - это перестанет быть си и станет чем-то типа яваскрипта по скоростью работы. Потому что 2/3 операций будут не тем что хотелось посчитать, а кучей проверок "а как посчиталось?!". Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что сейчас есть, даже если это чуть безопаснее? Это ж заякорит в 3 раза вообще всю систему, на самых базовых уровнях. В бенчах будет швах и это даром никто не возьмет.

Ответить | Правка | Наверх | Cообщить модератору

85. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от InuYasha (?), 24-Май-20, 11:11

> Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что
> сейчас есть, даже если это чуть безопаснее?
Всем. В debug-версии. И ещё горы ASSERT-ов и логов. Отладил - и можно в релиз, где проверок меньше. А в редко используемых функциях типа Init и Create я проверки вообще не вырубаю.

Ответить | Правка | Наверх | Cообщить модератору

90. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (90), 27-Май-20, 09:34

нужна аппаратная поддержка корректности
типа (условный ассемблер)
add Ax,Bx ; сложение когда переполнение не ошибка
add Ax,Bx ; сложение когда переполнение ошибка, выполняется процем параллельно и на производительность не влияет.

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

1. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." –1 +/–

Сообщение от native76 (ok), 21-Май-20, 23:29

звучит страшновато

Ответить | Правка | Наверх | Cообщить модератору

2. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +11 +/–

Сообщение от BSDun (?), 21-Май-20, 23:38

Хорошо звучит. Можно будет рутовать ARMv7 устройства, а затем обновлять глибси.

Ответить | Правка | Наверх | Cообщить модератору

10. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +4 +/–

Сообщение от Аноним (10), 22-Май-20, 00:21

Всякую встроенку которая никогда не обновится теперь можно ломать.

Ответить | Правка | Наверх | Cообщить модератору

17. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +3 +/–

Сообщение от Аноним (17), 22-Май-20, 00:57

Во всякой встроенке скорее всего будет другая libc.

Ответить | Правка | Наверх | Cообщить модератору

91. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +/–

Сообщение от sabretoothedhamster (?), 28-Май-20, 15:06

Вот, кстати, да, про другие либы что-нибудь пишут (типа uClibc/ng)?

Ответить | Правка | Наверх | Cообщить модератору

60. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +/–

Сообщение от Аноним (60), 22-Май-20, 17:49

Welchia 2.0

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

68. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +2 +/–

Сообщение от погроммист (?), 23-Май-20, 00:29

Надо только сначала найти ARMv7 устройство с более чем 2гб памяти.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

18. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +2 +/–

Сообщение от Ivan_83 (ok), 22-Май-20, 00:58

Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны и код его до этого никак не валидировал - то memcpy() не виновато что в него мусор заслали.
И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый.
Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

32. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +7 +/–

Сообщение от sfdsf (?), 22-Май-20, 08:58

> станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый
Вы Чукчи Писатели уже раздражать начинаете. Черным по бежевому написано же:
>>в реализации для ARMv7 вместо size_t в добавленных для оптимизации ассемблерных вставках оно обрабатывается как signed integer

Ответить | Правка | Наверх | Cообщить модератору

34. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." –3 +/–

Сообщение от Аноним (34), 22-Май-20, 09:23

Во времена мамонтов были процессоры в которых беззнаковая арифметика была реализована, как то иначе чем у большинства. Из за этих героев весь мир должен страдать многие десятки лет.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

54. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +/–

Сообщение от Анон123 (?), 22-Май-20, 14:07

То ли ещё было во времена грекоримлян...

Ответить | Правка | Наверх | Cообщить модератору

47. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +1 +/–

Сообщение от пох. (?), 22-Май-20, 11:51

> Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны
в memcpy, внезапно, частенько приходят данные пользователя - и длинна их контролируется, хотя и косвенно, пользователем. Сколько прислали (в пределах разумного, но это, например - адресное пространство целиком вполне может быть), столько и копируем.
> и код его до этого никак не валидировал
а зачем коду его валидировать? Код просто посчитал, сколько байтиков ему прислали. Правильно посчитал. А там ляп-ляп-ляп, забыли про unsigned.
> И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый.
к сожалению, ассемблер ничего не знает ни про какие size_t.
> Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна.
в glibc-то? Да кто б сомневался. Особенно на редких и немодных платформах.

Ответить | Правка | К родителю #18 | Наверх | Cообщить модератору

3. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +2 +/–

Сообщение от Аноним (3), 21-Май-20, 23:47

Что-то непонятное на скриншоте. Вроде речь идёт о системе, основанной на GLibc, а запускают какой-то ехешник.

Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +3 +/–

Сообщение от Аноним (5), 21-Май-20, 23:54

Что тут непонятно, запустили netcat на винде для атаки на внешний хост по сети.

Ответить | Правка | Наверх | Cообщить модератору

6. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +/–

Сообщение от Sw00p aka Jerom (?), 21-Май-20, 23:55

на скриншоте показано подключение к сокету, который уже был открыт после экслоитинга.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

38. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +/–

Сообщение от Аноним (38), 22-Май-20, 10:11

Взлом системы с уже открытым портом, на котором уже висит рут-шелл с помощью вантузного нетката. Что непонятного? Это сиска... Там ещё питоновские файлы в некрософт-шояде редактируют и перфорс используют вместо гита. Сам видел. А ещё там заставляют людей использовать cisco-webex тех, кто не убедил начальство переползти на slack или skype, на худой уонец.

Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

67. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..." +1 +/–

Сообщение от териванов (?), 22-Май-20, 21:01

Кул стори, бро...

Ответить | Правка | Наверх | Cообщить модератору

4. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (4), 21-Май-20, 23:53

Стоит отметить, что и Android проблема тоже не затрагивает ввиду использования bionic вместо libc. Мало ли кто об этом не знает.

Ответить | Правка | Наверх | Cообщить модератору

7. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (5), 21-Май-20, 23:56

А какая связь bionic и glibc (GNU libc)? Это совершенно разные libc.

Ответить | Правка | Наверх | Cообщить модератору

8. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (5), 21-Май-20, 23:58

ой, прочитал "не затрагивает" как "затрагивает".

Ответить | Правка | Наверх | Cообщить модератору

11. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от gogo (?), 22-Май-20, 00:30

Не знает тот, кто не прочитал статью, а строчит комменты.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

14. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от vitalif (ok), 22-Май-20, 00:43

а жаль!

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

15. Скрыто модератором –8 +/–

Сообщение от Аноним (15), 22-Май-20, 00:57

Потому что android единственный нормальный линукс, а все остальное - унылые неработающие поделки.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. Скрыто модератором –1 +/–

Сообщение от Аноним (21), 22-Май-20, 01:40

Не работающие… Ты или поехавший, либо мелкий траль. Как насчёт потоньше? Иди лучше бсдшников поразвлекай этим аргументом, или макосников. Вот у них проблемки, да.

Ответить | Правка | Наверх | Cообщить модератору

35. Скрыто модератором +4 +/–

Сообщение от Аноним (35), 22-Май-20, 09:36

Я еще понимаю критику windows и из пользователей.
Но, что вам сделали BSD и osx?
Это отличные ос, которые ничуть не хуже линукса.
И что вам сделали пользователи bsd и макоси, что вы их так ненавидите и ставите себя выше их?
У линуксоидов была какая-то травма в детстве, связанная с этим?
Верно говорят, что линуксоиды ставят свою ос на уровне бога и критикуют и ненавидят все, что не связано с ним.
Моральные уроды вы линуксоиды и больше никто.

Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором –2 +/–

Сообщение от Аноним (21), 22-Май-20, 10:14

Я могу ответить. Пользователи эскбсд достали своим хэйтом, а проблемы с запуском софта у них и правда есть. Пользоваться osx же откровенно больно. И где ты увидел критику?

Ответить | Правка | Наверх | Cообщить модератору

55. Скрыто модератором –1 +/–

Сообщение от Школьник (ok), 22-Май-20, 14:16

Если вкратце, то каков поп, таков и приход.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

59. Скрыто модератором –3 +/–

Сообщение от с (?), 22-Май-20, 15:30

> Верно говорят, что линуксоиды ставят свою ос на уровне бога
А как должно быть? за 42 года какие достижения? Линукс в 2 раза младше, а достижений гораздо больше.
> что вам сделали пользователи bsd
"сожгли Джордано Бруно", фигурально, буквально - тормозили прогресс, 42 года своей псевдо бесплатной, псевдо открытой лицензией, подлизывая корпорастам. И слава гну и жпл, линукс поставил на этом крест, ну конечно больше жпл, с радикальными шлюхами бороться можно только радикальными методами.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

62. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (3), 22-Май-20, 18:40

>Я еще понимаю критику windows и из пользователей.
А чем Макось и её пользователи лучше? Тоже закрытая хрень. И кому до того какое дело, что она официально сертифицирована на UNIX.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

73. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Anonn (?), 23-Май-20, 10:47

Ну вот, а Google винили в NIH-синдроме. Не даром они и boring ssl сделали, и много чего другого.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

24. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –4 +/–

Сообщение от Аноним (24), 22-Май-20, 03:42

Совершенно непонятная новость. У memcpy аргумент имеет тип size_t как он в безанковый тип передали отрицательное число?

Ответить | Правка | Наверх | Cообщить модератору

29. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (5), 22-Май-20, 08:24

В коде использовались ассемблерные вставки с инструкциями для работы со знаковыми числами.

Ответить | Правка | Наверх | Cообщить модератору

30. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –2 +/–

Сообщение от Аноним (30), 22-Май-20, 08:50

Нет там вставок, функция целиком на ассемблере написана.

Ответить | Правка | Наверх | Cообщить модератору

57. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от Жека Воробьев (?), 22-Май-20, 14:27

а еще у математиков бывают пустые множества, прикинь какая боль

Ответить | Правка | Наверх | Cообщить модератору

83. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (-), 24-Май-20, 05:31

Боль - это пытаться объяснить вебмакаке как работает рид-соломон :)

Ответить | Правка | Наверх | Cообщить модератору

88. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от cool29 (?), 25-Май-20, 12:54

Не МАКАКА А МИСТЕР ГОРИЛЛА! Понял, да!? А ты УДАВ УЗЛОВАТЫЙ!

Ответить | Правка | Наверх | Cообщить модератору

26. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –5 +/–

Сообщение от Аноним (26), 22-Май-20, 06:21

Предупреждали - не делать в коде С ассемблерных системно зависимых вставок.

Ответить | Правка | Наверх | Cообщить модератору

28. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Онаним (?), 22-Май-20, 08:21

Увы, если в коде эмбедовки делать это не делать - она ворочаться будет как Windows 2000 на 80486-25.

Ответить | Правка | Наверх | Cообщить модератору

36. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –1 +/–

Сообщение от Аноним (26), 22-Май-20, 09:51

Согласен. Сам таким баловался, когда по просьбе знакомых докторов вьвер для томографа написал в начале 90-х.

Ответить | Правка | Наверх | Cообщить модератору

37. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (37), 22-Май-20, 09:51

Не запустится. 80486 на 25 МГц — это SX, без сопроцессора, и более чем уверен, что специфические для Pentium инструкции были использованы. Плюс я не помню чипсетов для 80486, поддерживающих хотя бы 32 МБ ОЗУ (минимум для первых версий винтукея, на которых он только и может, что запуститься, где-то за полчаса).

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

43. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Zenitur (ok), 22-Май-20, 11:22

Сопроцессоры для 486 SX выпускались отдельно. https://ru.wikipedia.org/wiki/Intel487SX
У меня на материнке с Am386DX-40 (1993 год) можно максимум установить 32 Мб ОЗУ, судя по документации. 8 30-pin SIMM-модулей по 4 Мб каждый. Но я не пробовал. На 486 и 72-pin SIMM не должно быть проблем

Ответить | Правка | Наверх | Cообщить модератору

64. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (3), 22-Май-20, 18:46

Ты на Avito покупаешь или продаёшь?

Ответить | Правка | Наверх | Cообщить модератору

45. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Онаним (?), 22-Май-20, 11:45

> минимум для первых версий винтукея, на которых он только и может, что запуститься, где-то за полчаса).
Вот!

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

48. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от Онаним (?), 22-Май-20, 11:53

> 80486 на 25 МГц — это SX
Am486 DX-25 был вполне себе с сопром. Более того, двухштучник сопра и P5 не требовал и за полчасика взлетал и на SX.

Ответить | Правка | К родителю #37 | Наверх | Cообщить модератору

63. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (3), 22-Май-20, 18:42

>Предупреждали - не делать в коде С ассемблерных системно зависимых вставок.
Кто и кого предупреждал?

Ответить | Правка | К родителю #26 | Наверх | Cообщить модератору

27. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от Аноним (27), 22-Май-20, 07:13

"встроенный в автомобильные информационные системы http-сервер". блин, дайте мне другой глобус

Ответить | Правка | Наверх | Cообщить модератору

49. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от пох. (?), 22-Май-20, 12:00

В принципе, и этот глобус - достаточно большой, чтобы хватило на всех веб-макак.
Я думаю, даже 2x1.5 им жырно, можно просто сваливать в одну траншею.
Хотя, с другой стороны, чего матеръял-то зря переводить...
"За холмом открывалось огромное поле. В поле, точно по линеечке,
стояли рядами не то кресты, не то деревья, не то вязанки рогов. И перед
каждым из них виднелись могильные холмики."

Ответить | Правка | Наверх | Cообщить модератору

71. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Lex (??), 23-Май-20, 08:11

Веб-макаками уже стали ассемблерные программисты под арм?)
А вообще, даже забавно наблюдать за настолько нелепыми ошибками у «системных_и_не_веб_программистов»

Ответить | Правка | Наверх | Cообщить модератору

87. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от iPony129412 (?), 25-Май-20, 07:30

Было бы чего плохого...

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

31. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –3 +/–

Сообщение от Аноним (30), 22-Май-20, 08:55

В новости ошибка. ВСЯ ФУНКЦИЯ ЦЕЛИКОМ НА АССЕМБЛЕРЕ. Нет никаких "вставок". https://code.woboq.org/userspace/glibc/sysdeps/arm/memcpy.S....

Ответить | Правка | Наверх | Cообщить модератору

39. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (39), 22-Май-20, 10:12

Директивы препроцессора на С. (Хотя не знаю, можно ли препроцессор считать частью языка).
А, еще комментарии сишные есть!

Ответить | Правка | Наверх | Cообщить модератору

46. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Sw00p aka Jerom (?), 22-Май-20, 11:50

Ага, с прототипом где явно указано size_t :)

Ответить | Правка | Наверх | Cообщить модератору

65. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (3), 22-Май-20, 18:49

Нельзя. Препроцессор о синтаксисе C не знает, он просто тупо подставляет. Поэтому не может давать адекватных сообщений о проблемах.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

70. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (30), 23-Май-20, 06:02

Во многих ассемблерах были макросы (TASM, MASM), но в линуксовом их нет и добавили препроцессор из С. Этот препроцессор для много чего может использоваться, можно вызывать его отдельно.

Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

75. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от BSA (?), 23-Май-20, 15:39

Есть там макросы .macro/.endm. Они позволяют создавать макросы, используемые как инструкции.

Ответить | Правка | Наверх | Cообщить модератору

69. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –2 +/–

Сообщение от Аноним (30), 23-Май-20, 05:54

Три человека, что поставили минус. Всё теперь ясно о компетентности комментаторов в программировании.

Ответить | Правка | К родителю #31 | Наверх | Cообщить модератору

33. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +2 +/–

Сообщение от ЛениваяЖ (?), 22-Май-20, 09:05

Размер копируемой должен быть от 2 Гб, для того, чтобы получить отрицательное значение

Ответить | Правка | Наверх | Cообщить модератору

44. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (5), 22-Май-20, 11:26

2ГБ чтобы выйти на минус и ещё 2ГБ чтобы указатель сместить в конец первых 2ГБ. Следующие данные уже полезут за ожидаемый буфер.

Ответить | Правка | Наверх | Cообщить модератору

50. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от пох. (?), 22-Май-20, 12:02

и вот тебе жалко 2г нулей ради хорошего дела?!

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

76. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от BSA (?), 23-Май-20, 15:41

Если послать через сжатый канал (например, http+gzip), то объемы будут значительно меньше.

Ответить | Правка | К родителю #33 | Наверх | Cообщить модератору

42. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (42), 22-Май-20, 11:17

Разработчики glibc в принципе не умеют в форматирование кода? Что там за каша?

Ответить | Правка | Наверх | Cообщить модератору

89. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от vle (ok), 26-Май-20, 23:52

Это "всеми любимый" gnu coding style ;-)

Ответить | Правка | Наверх | Cообщить модератору

61. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от mos87 (ok), 22-Май-20, 18:36

нестрашно, добрый вендор всегда оберегает тебя через TrustZone бггг

Ответить | Правка | Наверх | Cообщить модератору

66. "Критическая уязвимость в реализации функции memcpy для ARMv7..." –1 +/–

Сообщение от Аноним (66), 22-Май-20, 18:55

просто надо было писать на rush а параметры передавать через https+json

Ответить | Правка | Наверх | Cообщить модератору

78. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +/–

Сообщение от Аноним (78), 23-Май-20, 20:56

Какой идиот додумался для РАЗМЕРА использовать знаковое целочисленное?

Ответить | Правка | Наверх | Cообщить модератору

79. "Критическая уязвимость в реализации функции memcpy для ARMv7..." +1 +/–

Сообщение от Аноним (21), 24-Май-20, 00:39

Кто-то из POSIX. Глупые наверное, и конвенции сишные глупые выдумали. Совсем дурачки. Ты-то умный, вон сразу видно, надо было спросить у тебя.

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

41. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+23 +/–
Сообщение от Ordu (ok), 22-Май-20, 10:33
Наблюдаю в комментах непонимание, поэтому краткая справка для далёких от машинного представления чисел. Знаковые числа и беззнаковые -- это просто наборы бит. Никто не запрещает один и тот же набор бит интерпретировать как знаковый или беззнаковый. Чаще всего, получается примерно такое соответствие: 0 <=> 0 1 <=> 1 ... 2^31-2 <=> 2^31-2 2^31-1 <=> 2^31-1 2^31 <=> -2^31 2^31+1 <=> -2^31+1 ... 2^32-1 <=> -1 Для знакомых с группами вычетов Z/nZ: знаковые и беззнаковые -- это одна и та же факторизация множества целых чисел, но представители классов выбраны разные. Это как группу Z/3Z можно представлять как множество элементов {0, 1, 2}, а можно как {-1, 0, 1}. (Кстати обратите внимание, если не сталкивались с этим раньше: abs(abs(x)) не всегда равен x. -2^31 -- это самое большое по модулю число, и оно одно, для него нет положительной пары. Бага системы кодирования чисел, которая иногда становится занозой в заднице). При этом, что удачно, при таком подходе к кодированию целых, можно использовать одни и те же операции сложения/вычитания для работы как со знаковыми числами, так и с беззнаковыми. Но когда речь заходит об умножении, делении, сравнении чисел, на уровне машинных команд код начинает различаться, в зависимости от знаковости аргументов. Обсуждаемый бажный memcpy работал с size как со знаковым числом. Для значений меньше чем 2^31 это работало как надо, потому что если такие беззнаковые числа интерпретировать как знаковые, то они по смыслу будут тем же самым. А вот для значений больше либо равных 2^31 уже не работало, потому что если их интерпретировать как знаковые, то получатся отрицательные числа. И собственно эксплуатация бага свелась к тому, чтобы добиться передачи в memcpy буфера с размером в 2Gb или больше. То есть код, использующий memcpy может быть 100% безбажным, и тем не менее эксплоит будет возможен, при наличии такой бажной реализации memcpy.
Ответить \| Правка \| Наверх \| Cообщить модератору


	51. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+6 +/–
	Сообщение от CAE (ok), 22-Май-20, 12:20
	Гм. Современное поколение программистов не знает что такое прямой, обратный и дополнительный код? :))
	Ответить \| Правка \| Наверх \| Cообщить модератору


	52. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+9 +/–
	Сообщение от смузихлеб вейпер тимлид (?), 22-Май-20, 12:41
	эй потише там
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (80), 24-Май-20, 05:13
	Программист - слишком громкое название для вебмакаки, там из образования книжка по пэхапэ прочитанная за неделю. И все, можно идти твАрить.
	Ответить \| Правка \| К родителю #51 \| Наверх \| Cообщить модератору


	86. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (86), 25-Май-20, 01:49
	Ох уж эта русскоязычная терминология. Конечно, современные программисты ее не знают. По-английски это называется ones’ complement.
	Ответить \| Правка \| К родителю #51 \| Наверх \| Cообщить модератору


	53. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+7 +/–
	Сообщение от Аноним (53), 22-Май-20, 13:54
	> abs(abs(x)) не всегда равен x. Вообще-то никогда не равен, если x - отрицательное.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	58. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+1 +/–
	Сообщение от Ordu (ok), 22-Май-20, 14:29
	А, простите, перепутал операцию. Да, имелось в виду -(-x).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+5 +/–
	Сообщение от PnD (??), 22-Май-20, 14:26
	Объяснил так объяснил. Для далёких. Попробую показать "на пальцах" для остальных. Число внутри 32-разрядного процессора состоит из 32 записанных друг за другом "битов", содержащих либо "0" либо "1". Т.о. привычный нам ноль — это 32 бита с "0" внутри процессора. Дальше будем полагать что числа пишутся/читаются в привычном нам порядке, слева направо. Бывает и наоборот. С какого конца читать — указывают в названии архитектуры процессора (big\|litle endian). Единица в самом правом разряде "00000000000000000000000000000001" соответствует 2º (в степени 0), т.е. = 1. Следующие биты справа налево кодируют 2¹=2, 2²=4 и т.д. Двоичное число "01000000000000000000000000000000" (единица в 31-м разряде) соответствует 2³º= 1073741824 (десятичное представление). Чтобы записывать отрицательные числа, договорились использовать 32-й (самый левый) бит. При этом число "10000000000000000000000000000000" = 2³¹ кодирует самое маленькое (для 32-разрядного процессора) число -2³¹. И оно уникально, т.к. соответствующее ему положительное число в 32 разряда не лезет (или надо знак убирать). Остальные биты при этом обозначают сколько надо прибавить к -2³¹. То есть: "10000000000000000000000000000001" = -2³¹ + 1 = -2147483647 "11111111111111111111111111111111" = -1 (прибавили всё кроме последней единицы) В этом месте нетрудно заметить, что операция сложения чисел со знаком ничем не отличается от той же самой операции "без знака". Например, "-1 + 1": "11111111111111111111111111111111" + "00000000000000000000000000000001" = "00000000000000000000000000000000". * Разряды переполнились и обнулились. Не хуже чем на старых арифмометрах. ** В умных книжках такой способ представления отрицательных чисел называется "второе дополнение": в первом дополнении число "переворачивают": например из "1100" получается "0011". Во втором — добавляют 1 (получим "0100"). Но это выносит неокрепший моск и напрочь убивает понимание как с этим обращается процессор.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	72. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+1 +/–
	Сообщение от Аноним (72), 23-Май-20, 09:37
	Даёшь троечную систему счисление!!!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (-), 24-Май-20, 05:23
	Такая даже была на заре развития компьютеров, но популярности не снискала, только тогда уж "троичная".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от BSA (?), 23-Май-20, 15:33
	"Второе дополнение"? Обычно, это называется просто "дополнительный код числа" и он именно от "дополнения единицей". Число не "переворачивают", а инвертируют: 0 заменяют на 1, а 1 на 0. Ваше объяснение тоже не сильно лучше. А местами просто вводит в заблуждение.
	Ответить \| Правка \| К родителю #56 \| Наверх \| Cообщить модератору


	84. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (84), 24-Май-20, 07:00
	да он только вчера книжку прочитал, ещё не все термины запомнил, вероятно, имелось в виду "дополнение до двух"
	Ответить \| Правка \| Наверх \| Cообщить модератору


	77. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от InuYasha (?), 23-Май-20, 17:12
	С древних времён у меня вызывало недоумение: кто и зачем всякие memcpy() определяет в signed-типами?... Ну и всякие int count, int size и т.п. Проверки на -1 - не оправдание - это симптом уже случившегося кабздеца.
	Ответить \| Правка \| К родителю #41 \| Наверх \| Cообщить модератору


	82. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (-), 24-Май-20, 05:28
	На самом деле кабздец - вообще не там. Проблема в том что когда делается математика - она делается в регистрах, как таковое, железо в общем виде не сигналит софту аппаратными исключениями и т.п. если вдруг результат счета оказался больше регистра и старший бит был обрублен, в общем то, скорее даже железом. Ну или абсракциями рядом. Как максимум процессоры взводят флаг состояний. Но если после каждой операции проверять эти флаги - это перестанет быть си и станет чем-то типа яваскрипта по скоростью работы. Потому что 2/3 операций будут не тем что хотелось посчитать, а кучей проверок "а как посчиталось?!". Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что сейчас есть, даже если это чуть безопаснее? Это ж заякорит в 3 раза вообще всю систему, на самых базовых уровнях. В бенчах будет швах и это даром никто не возьмет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от InuYasha (?), 24-Май-20, 11:11
	> Ну и кому будет надо всю алгоритмику на скорости 1/3 от того что > сейчас есть, даже если это чуть безопаснее? Всем. В debug-версии. И ещё горы ASSERT-ов и логов. Отладил - и можно в релиз, где проверок меньше. А в редко используемых функциях типа Init и Create я проверки вообще не вырубаю.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Критическая уязвимость в реализации функции memcpy для ARMv7..."	+/–
	Сообщение от Аноним (90), 27-Май-20, 09:34
	нужна аппаратная поддержка корректности типа (условный ассемблер) add Ax,Bx ; сложение когда переполнение не ошибка add Ax,Bx ; сложение когда переполнение ошибка, выполняется процем параллельно и на производительность не влияет.
	Ответить \| Правка \| К родителю #82 \| Наверх \| Cообщить модератору

1. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	–1 +/–
Сообщение от native76 (ok), 21-Май-20, 23:29
звучит страшновато
Ответить \| Правка \| Наверх \| Cообщить модератору


	2. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+11 +/–
	Сообщение от BSDun (?), 21-Май-20, 23:38
	Хорошо звучит. Можно будет рутовать ARMv7 устройства, а затем обновлять глибси.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+4 +/–
	Сообщение от Аноним (10), 22-Май-20, 00:21
	Всякую встроенку которая никогда не обновится теперь можно ломать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+3 +/–
	Сообщение от Аноним (17), 22-Май-20, 00:57
	Во всякой встроенке скорее всего будет другая libc.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+/–
	Сообщение от sabretoothedhamster (?), 28-Май-20, 15:06
	Вот, кстати, да, про другие либы что-нибудь пишут (типа uClibc/ng)?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	60. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+/–
	Сообщение от Аноним (60), 22-Май-20, 17:49
	Welchia 2.0
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	68. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+2 +/–
	Сообщение от погроммист (?), 23-Май-20, 00:29
	Надо только сначала найти ARMv7 устройство с более чем 2гб памяти.
	Ответить \| Правка \| К родителю #2 \| Наверх \| Cообщить модератору


	18. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+2 +/–
	Сообщение от Ivan_83 (ok), 22-Май-20, 00:58
	Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны и код его до этого никак не валидировал - то memcpy() не виновато что в него мусор заслали. И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый. Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	32. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+7 +/–
	Сообщение от sfdsf (?), 22-Май-20, 08:58
	> станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый Вы Чукчи Писатели уже раздражать начинаете. Черным по бежевому написано же: >>в реализации для ARMv7 вместо size_t в добавленных для оптимизации ассемблерных вставках оно обрабатывается как signed integer
	Ответить \| Правка \| Наверх \| Cообщить модератору


	34. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	–3 +/–
	Сообщение от Аноним (34), 22-Май-20, 09:23
	Во времена мамонтов были процессоры в которых беззнаковая арифметика была реализована, как то иначе чем у большинства. Из за этих героев весь мир должен страдать многие десятки лет.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	54. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+/–
	Сообщение от Анон123 (?), 22-Май-20, 14:07
	То ли ещё было во времена грекоримлян...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+1 +/–
	Сообщение от пох. (?), 22-Май-20, 11:51
	> Если у тебя в memcpy() приходит контролируемое удалённым пользователем значение длинны в memcpy, внезапно, частенько приходят данные пользователя - и длинна их контролируется, хотя и косвенно, пользователем. Сколько прислали (в пределах разумного, но это, например - адресное пространство целиком вполне может быть), столько и копируем. > и код его до этого никак не валидировал а зачем коду его валидировать? Код просто посчитал, сколько байтиков ему прислали. Правильно посчитал. А там ляп-ляп-ляп, забыли про unsigned. > И вообще станно, у memcpy() для размера должен sixe_t использоваться, а он без знаковый. к сожалению, ассемблер ничего не знает ни про какие size_t. > Короче, если и найдётся софт в котором из за этого дырка - то там она будет явно не одна. в glibc-то? Да кто б сомневался. Особенно на редких и немодных платформах.
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору

3. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+2 +/–
Сообщение от Аноним (3), 21-Май-20, 23:47
Что-то непонятное на скриншоте. Вроде речь идёт о системе, основанной на GLibc, а запускают какой-то ехешник.
Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Уязвимость в реализации функции memcpy для ARMv7 из состава ..."	+3 +/–
	Сообщение от Аноним (5), 21-Май-20, 23:54
	Что тут непонятно, запустили netcat на винде для атаки на внешний хост по сети.
	Ответить \| Правка \| Наверх \| Cообщить модератору