The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Уязвимость в реализации функции 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ообщить модератору

Оглавление

Сообщения [Сортировка по времени | 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 из состава ..."  +/
Сообщение от sabretoothedhamsteremail (?), 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 
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

21. Скрыто модератором  –1 +/
Сообщение от Аноним (21), 22-Май-20, 01:40 
Ответить | Правка | Наверх | Cообщить модератору

35. Скрыто модератором  +4 +/
Сообщение от Аноним (35), 22-Май-20, 09:36 
Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором  –2 +/
Сообщение от Аноним (21), 22-Май-20, 10:14 
Ответить | Правка | Наверх | Cообщить модератору

55. Скрыто модератором  –1 +/
Сообщение от Школьник (ok), 22-Май-20, 14:16 
Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

59. Скрыто модератором  –3 +/
Сообщение от с (?), 22-Май-20, 15:30 
Ответить | Правка | К родителю #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..."  +/
Сообщение от vleemail (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..."  +/
Сообщение от Анонимemail (78), 23-Май-20, 20:56 
Какой идиот додумался для РАЗМЕРА использовать знаковое целочисленное?
Ответить | Правка | Наверх | Cообщить модератору

79. "Критическая уязвимость в реализации функции memcpy для ARMv7..."  +1 +/
Сообщение от Аноним (21), 24-Май-20, 00:39 
Кто-то из POSIX. Глупые наверное, и конвенции сишные глупые выдумали. Совсем дурачки. Ты-то умный, вон сразу видно, надо было спросить у тебя.
Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру