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

"Уязвимость во FreeType, позволяющая выполнить код при обработке шрифтов"	+/–
Сообщение от opennews (ok), 13-Мрт-25, 14:22
В библиотеке отрисовки шрифтов... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62875
Ответить | Правка | Cообщить модератору

Сообщения

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

2. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
Сообщение от Аноним (2), 13-Мрт-25, 14:24
А когда добавили? В прошлый раз была уязвимость с шрифтами в формате png. Так теперь и не отключить png во freetype стало.
Ответить | Правка | Наверх | Cообщить модератору

	34. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от Аноним (34), 13-Мрт-25, 20:42
	Хороший вопрос... Ибо вариативные шрифты придумала в 2016 году группа компаний Adobe, Apple, Google и Microsoft.
	Ответить | Правка | Наверх | Cообщить модератору

	44. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от Аноним (44), 13-Мрт-25, 23:57
	Хорошие компании
	Ответить | Правка | Наверх | Cообщить модератору

	49. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+7 +/–
	Сообщение от Аноним (49), 14-Мрт-25, 01:24
	> вариативные шрифты придумала в 2016 году группа > компаний Adobe, Apple, Google и Microsoft. Ужасные компании! Мало того что платиновые спонсоры линукс фаундейшн, так еще умудяются наложить в штаны freedesktop'у, создавая стандарты который фридесктопчики ниасиливают! Подбросили CVE вот так прямо в их репозиторий!
	Ответить | Правка | К родителю #34 | Наверх | Cообщить модератору

	64. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от крабб (?), 14-Мрт-25, 09:36
	это пять!
	Ответить | Правка | Наверх | Cообщить модератору

3. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+3 +/–
Сообщение от Аноним (3), 13-Мрт-25, 14:26
Никогда такого не было и вот опять
Ответить | Правка | Наверх | Cообщить модератору

4. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+9 +/–
Сообщение от Аноним (4), 13-Мрт-25, 14:36
Заходя в эту новость, я уже предвкушал, что тут будет переполнение буфера.
Ответить | Правка | Наверх | Cообщить модератору

	13. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+9 +/–
	Сообщение от Аноним (13), 13-Мрт-25, 15:20
	Пора это уже в спецификации языка Си указать, что буфер -- это то, за пределы чего должен выйти любой уважающий себя сишник. Закрепить, так сказать, официально этот стандарт де-факто.
	Ответить | Правка | Наверх | Cообщить модератору

	60. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–2 +/–
	Сообщение от Смузихлеб забывший пароль (?), 14-Мрт-25, 07:49
	> из-за присвоения переменной с типом "signed short", > участвующей в вычислении размера буфера, значения с типом "unsigned long" Просто диды - мастера не только в индексах, но и в преобразованиях типов которые сами себе напридумывали в т.ч ради экономии на спичках, точнее, отдельных байтах
	Ответить | Правка | Наверх | Cообщить модератору

5. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от DeerFriend (?), 13-Мрт-25, 14:43
freetype-2.13.1-1.fc39 created a year ago for Fedora 39 какой смысл писать про такие древности?
Ответить | Правка | Наверх | Cообщить модератору

	8. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от НяшМяш (ok), 13-Мрт-25, 14:55
	Любители дебиана уже дуреют с 2.12.1+dfsg-5+deb12u3 прикормки.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–2 +/–
	Сообщение от kai3341 (ok), 13-Мрт-25, 15:27
	Точно подмечено
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (32), 13-Мрт-25, 18:11
	таки и не все на 12-ом (!) 2.10.4+dfsg-1+deb11u1 all
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	22. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (2), 13-Мрт-25, 15:53
	Всего год? В генту уязвимая 2.13.0 до сих пор стабильная. А теперь представь сколько софта тащит только эту версию (и сколько более старые), у нас же деды-специалисты говорят обновляться стыдно и в то же время юнцы-специалисты топят за статическую линковку или как минимум таскать всё бандлом.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	38. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от dannyD (?), 13-Мрт-25, 21:31
	не нада ля-ля в генту зеленое 2.13.3
	Ответить | Правка | Наверх | Cообщить модератору

	39. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (2), 13-Мрт-25, 21:33
	> не нада ля-ля > в генту зеленое 2.13.3 все 3 зелёные (2.13.0 2.13.2 2.13.3), крайне странное решение.
	Ответить | Правка | Наверх | Cообщить модератору

	40. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от dannyD (?), 13-Мрт-25, 21:36
	ну может зависимости какие, каким-то пакетам нужны устаревшие версии.
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (2), 13-Мрт-25, 21:37
	Причём, 2.13.3 уже почти год без обновлений, хочешь свежей собирай из гита и софт к этому может весьма плохо отнестись. Ситуация довольно патовая, ключевая либа такая дохлая -- одни уязвимости добавляют по мере надобности.
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

7. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от Аноним (7), 13-Мрт-25, 14:54
Дарка от бублика наш линукс злосчастный. К тому же, если учесть, что код всем открыт. Чем там все кичатся. Кто бы что ни говорил, но зачастую это банальный кактус, который мы с ехидной улыбкой, как у 20-летних заносчивых супэраутишников, жуём все вместе. Ну.. жуём дальше господа ))
Ответить | Правка | Наверх | Cообщить модератору

	59. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноним (59), 14-Мрт-25, 07:30
	Согласен, надо ставить проприетарную Solaris от Oracle.
	Ответить | Правка | Наверх | Cообщить модератору

	67. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (67), 14-Мрт-25, 10:34
	лучше такой же астра линкус там манда ты
	Ответить | Правка | Наверх | Cообщить модератору

	61. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от ИмяХ (ok), 14-Мрт-25, 08:03
	>>код всем открыт. Чем там все кичатся. Странный повод, чтоб кичиться. Ведь благодаря открытому коду любой школьник может прочитать diff закрытия свежей уязвимости и по быстрому написать зловред для тех, кто ещё не успел обновиться.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

	65. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от Аноним (65), 14-Мрт-25, 10:13
	Не любому это надо, у кого-то и детство есть.
	Ответить | Правка | Наверх | Cообщить модератору

	71. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (71), 14-Мрт-25, 12:20
	Cчастливые люди, приятно слышать что такие ещё остались.
	Ответить | Правка | Наверх | Cообщить модератору

	74. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (74), 14-Мрт-25, 13:22
	Ну да, в проприетарных ОС-подобных поделиях уязвимости просто никто не ищет, поэтому там их количество постоянно растёт.
	Ответить | Правка | К родителю #7 | Наверх | Cообщить модератору

9. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
Сообщение от Аноним (9), 13-Мрт-25, 15:00
> Amazon Linux 2, Debian stable / Devuan, RHEL 8 и 9 Вся суть "стабильных" дистрибутивов.
Ответить | Правка | Наверх | Cообщить модератору

	10. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (10), 13-Мрт-25, 15:11
	А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей. Стабильные дистры не тащат новые фичи, которые ломают поведение библиотек/программ.
	Ответить | Правка | Наверх | Cообщить модератору

	18. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноним (-), 13-Мрт-25, 15:37
	> Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей. Ну-ну. Проблема была исправлена еще в 2023 году. А сейчас на календаре 2025й, но окаменевший деб все еще уязвим security-tracker.debian.org/tracker/CVE-2025-27363 Вот где бекпорт??
	Ответить | Правка | Наверх | Cообщить модератору

	23. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (10), 13-Мрт-25, 16:16
	Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена?
	Ответить | Правка | Наверх | Cообщить модератору

	29. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноним (-), 13-Мрт-25, 16:56
	> Дак выявили проблему в этом году. Проблемы выявили и исправили еще в 2023. Просто тогда не осознали насколько она проблемная. > Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена? Но из-за того, что некродистры не забирают фиксы обычных багов, а только тех, которые оценили как критику, то естественно ее никто не забирал. Причем для нормальных дистров это проблемой не стало - они просто обновились и забыли. В итоге в шта6ильных сурьезных дистрах типа RHEL9 дырень прожила на полтора года дольше чем во всяких рачах и бубунтах
	Ответить | Правка | Наверх | Cообщить модератору

	31. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от User (??), 13-Мрт-25, 17:51
	Ты не бойся, в рачах уже четыре новые слопатили)
	Ответить | Правка | Наверх | Cообщить модератору

	35. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (9), 13-Мрт-25, 21:13
	> Дак выявили проблему в этом году. Как они могли себе фикс бекпортировать, если проблема еще не была обнаружена? Обновившись до актуальной версии, прикинь.
	Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

	36. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (9), 13-Мрт-25, 21:14
	> А что не так? Стабильные дистры затаскивают и бекпортируют себе фикс уязвимостей. Не так то что ничего они не затаскивают и не бэкпортируют, как иллюстрирует этот случай. А просто злонамеренно держат в репах тухлые дырявые версии.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

11. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
Сообщение от Аноним (11), 13-Мрт-25, 15:14
Я забыл, дум уже запустили в шрифте или мне приснилось?
Ответить | Правка | Наверх | Cообщить модератору

	45. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноним (44), 13-Мрт-25, 23:58
	GTA запустили
	Ответить | Правка | Наверх | Cообщить модератору

	51. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (51), 14-Мрт-25, 01:49
	https://fuglede.github.io/llama.ttf/
	Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

12. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от Fracta1L (ok), 13-Мрт-25, 15:17
Разрабы freetype просто не умеют писать на сишке, вот местные комментаторы никогда бы не допустили такого бага.
Ответить | Правка | Наверх | Cообщить модератору

16. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от Ivan_83 (ok), 13-Мрт-25, 15:31
> до версии 2.13.0 включительно и устранена в версии 2.13.1 (июнь 2023 года). А что за некронвости такие!? freetype2-2.13.3 уже стоит из портов. Опять у растовиков обострение и пообщатся захотелось?
Ответить | Правка | Наверх | Cообщить модератору

	17. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от Аноним (-), 13-Мрт-25, 15:35
	> А что за некронвости такие!? Обычные некроновости для некродистров вроде Debian stable / Devuan, RHEL 8 и 9 и так далее. Потому что исправлено оно было в июне 2023 года, но не помечено как CVE. Поэтому бекпорта не было. > Опять у растовиков обострение и пообщатся захотелось? О чем тут общаться? Типикал сишная дыра, никогда такого не было и вот опять. А вот предупредить некролюбов что нужно обновиться - это доброе дело.
	Ответить | Правка | Наверх | Cообщить модератору

	21. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Ivan_83 (ok), 13-Мрт-25, 15:50
	> А вот предупредить некролюбов что нужно обновиться - это доброе дело. Скорее всего систем со старой либой где шрифт с эксплоитом можно загрузить и "заюзать" единицы, они не представляют интереса, если только в таргетированных атаках.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+3 +/–
	Сообщение от 12yoexpert (ok), 13-Мрт-25, 16:22
	все корпоративные дистры со старыми либами
	Ответить | Правка | Наверх | Cообщить модератору

25. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от Аноним (25), 13-Мрт-25, 16:28
Годно. Теперь код необязательно запускать, достаточно открыть его в редакторе, чтобы произошел взлом.
Ответить | Правка | Наверх | Cообщить модератору

	26. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (2), 13-Мрт-25, 16:47
	Достаточно открыть страничку в интернете без дефолтной блокировки шрифтов ublock. Будь готовые прототипы в паблике, можно было бы использовать их их для обхода цифровой тюрьмы¸а так ничего хорошего.
	Ответить | Правка | Наверх | Cообщить модератору

	28. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (-), 13-Мрт-25, 16:47
	Раньше было лучше (с) В 2020 у них была 0-day дырень [1], которая мало того что активно эксплуатировалась. Так еще и работала через браузер (хром и лиса). И работала на андроиде. Вот это уровень! [1] opennet.ru/opennews/art.shtml?num=53922
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	33. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (33), 13-Мрт-25, 18:32
	Перед этим правдва надо установить нужный шрифт, и вот потом уже да.
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

30. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
Сообщение от Аноним (30), 13-Мрт-25, 17:46
Если это жадность до ОЗУ, то это необоснованно, т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64. Более того, если говорить о микроконтроллерах с Cortex M, то там в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами.
Ответить | Правка | Наверх | Cообщить модератору

	37. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–1 +/–
	Сообщение от Аноним (9), 13-Мрт-25, 21:19
	> т.к. в 32 битных системах переменная всё равно по факту займет 32 бита (если не извращаться, и к массивам не относится), а в 64-битной - 64 Да ты что.
	Ответить | Правка | Наверх | Cообщить модератору

	63. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (63), 14-Мрт-25, 08:18
	Прикинь, в ОЗУ Cortex M0 оно так по умолчанию.
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–1 +/–
	Сообщение от Аноним (-), 13-Мрт-25, 21:38
	> в 32 битных системах переменная всё равно по факту займет 32 бита Да ладно? Так уж и займёт 32 бита? Попробуй такое: struct test {     char a;     char b;     char c;     char d; }; struct test var; assert!(sizeof(var) == 16); Отметь, это не массив нисколько. > в некоторых случаях придется дополнительно выполнить команды SXTB, SXTH, UXTB и UXTH при операциях с меньшими по разрядности типами. Ага. Это ты ещё не видел как битовые поля распаковывают в представление, над которым затем можно выполнять осмысленные операции.
	Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

	47. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от _kp (ok), 14-Мрт-25, 00:14
	Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора. >>Ага Полагаться на то что выдал sizeof  - некорректно. Ваше утверждение тоже неверное. Правильный ответ: неопределенный размер. Хотя и с большой вероятностью 32 или 128 бит, но не конкретное  значение.
	Ответить | Правка | Наверх | Cообщить модератору

	52. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+4 +/–
	Сообщение от Аноним (52), 14-Мрт-25, 02:59
	> Ваше утверждение тоже неверное. Какое утверждение? Где и что я утверждал? Вы assert сочли "утверждением"? Это не утверждение, это часть кода, которую я предлагал скомпилировать и посмотреть, что выйдет. > Выравнивание подобной структуры, если об упаковке явно не указано, зависит и от платформы, и от уровня оптимизации, и конкретного компилятора. Да-да. > Полагаться на то что выдал sizeof  - некорректно. Из предыдущей цитаты вас, я могу утверждать, что неверно полагаться на то, что любое значение будет занимать 32 бита, потому что реально это будет зависеть от "выравнивания подобной структуры, ... бла-бла-бла". > Правильный ответ: неопределенный размер. Это не совсем правильный ответ. Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы, но как только мы определились с платформой, так сразу мы можем точно сказать, сколько байт будет занимать вышеприведённая структура. Нам не нужно для этого знать, каким компилятором для данной платформы мы будем пользоваться. Флагами компилятора можно это всё "испортить", но, кстати, не "флагами уровня оптимизации", потому что ABI должен быть фиксированным вне зависимости от уровня оптимизации: как ты будешь вызывать функции libc, если твой уровень оптимизации меняет layout структур libc? То есть ты такой сказал -O0, для отладки, и у тебя всё сломалось, потому что libc скомпилирована с -O2 или с -Os? Более того, я вам скажу, что ваш ответ категорически неправильный. Он истинный с формальной точки зрения (хотя бы потому, что мы всегда можем найти компилятор C, который делает не так как все), но он _абсолютно_ _бесполезен_ на практике. С философской точки зрения это банальный нигилизм, отрицание всего по каким-то метафизическим формальным причинам, с положением толстого болта на прагматику. Таким образом _правильный краткий ответ_: размер структуры вполне определён на каждой платформе, хотя могут быть нюансы. Более развёрнутый правильный ответ таков. Есть простое правило: alignment члена структуры равно его размеру, округлённому вверх на ближайшую степень двойки (но не больше 4 или 8 байт, в зависимости от битности системы). Таким образом, смещения членов относительно начала структуры будут 0, 1, 2 и 3, потому что alignment char'а 1 байт. Если вы укажете мне десктопную/серверную* систему в которой это правило не работает, вместо дальнейших пустопорожних рассуждений об абстрактных опциях компилятора, то я буду премного вам благодарен. Мне всегда интересно расширить свой кругозор. А до тех пор, пока вам такую систему найти не удалось, я продолжу следовать этому правилу, располагая поля в своих структурах так, чтобы структура бы занимала минимальный размер, не упираясь в проблемы с unaligned access. Собственно то правило выше, можно переформулировать в ещё более прагматичной форме, которая прям инструкция к действию: самый простой способ минимизировать размер структуры, не сталкиваясь с ограничениями packed структур, это располагать поля в структуре в порядке уменьшения их размера. *) эмбедщина не интересна, там свои правила, там даже соответствие в граните отлитым стандартам C весьма условно. Там уже у каждой зверюшки свои погремушки, каждая железка требует отдельного изучения особенностей архитектуры и компилятора. > Хотя и с большой вероятностью 32 или 128 бит, но не конкретное  значение. Что значит "не конкретное значение"? Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof: sizeof специфически говорит о том, сколько структура занимает места в памяти (не считая padding'а после неё, который может добавляться с тем, чтобы выдержать alignment других объектов в памяти). Что вы вообще хотели сказать этим? Я вот гадаю, и единственное объяснение, которое мне приходит на ум, это то, что компилятор может хранить эту структуру распакованной в четырёх регистрах. Он запросто может проделать такое в процессе оптимизации. Распаковать из RAM в регистры, поработать с ними, потом упаковать обратно в RAM, если компилятору покажется, что это будет быстрее, чем каждый раз обращаться к индивидуальным полям структуры по адресу. Я полагаю, что и на стеке он может хранить поля этой структуры в любом порядке с любым padding'ом который ему удобно, в конце концов там делали даже ассемблерные программисты во времена DOS, потому что push на стек клал 2 байта, и запушить туда один байт было невозможно. Таким образом, если хотелось освободить регистр, сохранив байт хранящийся там, то на стек летел этот байт расширенный нулями до двух байт. Но если вы _это_ имели в виду, то это мимо кассы. Речь идёт о layout'е структур в RAM. Аноним выше специфически хотел поговорить об этом. Это не memory layout структуры, это то что делает оптимизатор (человек или алгоритм), когда ему не надо заботиться об ABI: это временное, нефиксированное представление данных, с которым будет работать только локальный код, и оно оптимизировано под этот код. Если же вы имели в виду что-то иное, то вам следует изложить свою мысль внятно и последовательно.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–1 +/–
	Сообщение от _kp (ok), 14-Мрт-25, 04:32
	Да, утверждение не Ваше, лишне я сказал. Но, в остальном, мы друг друга поняли все равно верно. >>Если вы укажете мне десктопную/серверную* систему в которой это правило не работает Вы подметили про оптимизацию, а она может быть и под конкретную серию процессоров, и учитывать внутренниие нюансы скорости, особенности кэша.. В общем полагаться на то как уложит структуру компилятор "по умолчанию" в любом случае не стоит. >>эмбедщина не интересна Сейчас там отличий от десктопного кода все меньше >>Мне не понятно это ваше заявление, равно как и ваш отказ полагаться на то, что говорит sizeof Не верно полагаться но именно на то, что sizeof выдаст предполагаемый размер. А если он проверяется в рантайме, то конечно, ему тогда уже нужно доверять. ;)
	Ответить | Правка | Наверх | Cообщить модератору

	57. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–2 +/–
	Сообщение от Аноньимъ (ok), 14-Мрт-25, 04:32
	> Одно из свойств C, которое делает его незаменимым везде, это фиксированный ABI. Да, этот ABI зависит от платформы 🤣🤣🤣🤣🤣 Это капец.
	Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

	62. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (63), 14-Мрт-25, 08:17
	Речь о переменных, а не о полях структуры, помимо массивов. И речь идет о жадности, а на операции с битовыми полями сколько инструкций нужно выполнить?
	Ответить | Правка | К родителю #42 | Наверх | Cообщить модератору

53. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от мяв (?), 14-Мрт-25, 04:12
в очередной раз доказывает несостоятельность разного рода изкоробочных селинуксов и подчеркивает нужность МАСов.
Ответить | Правка | Наверх | Cообщить модератору

54. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
Сообщение от мяв (?), 14-Мрт-25, 04:14
>из-за присвоения переменной с типом "signed short", участвующей в вычислении размера буфера, значения с типом "unsigned long", госпади, на это же все современные компиляторы жалуются. как это произошло вообще ?
Ответить | Правка | Наверх | Cообщить модератору

	55. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноньимъ (ok), 14-Мрт-25, 04:31
	Варнинги отключили. Иначе память при компиляции ими переполнялась.
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Аноним (69), 14-Мрт-25, 10:57
	Гспди, рукалицо, если это правда.
	Ответить | Правка | Наверх | Cообщить модератору

68. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
Сообщение от Аноним (69), 14-Мрт-25, 10:56
>устранена в версии 2.13.1 (июнь 2023 года) Тю.
Ответить | Правка | Наверх | Cообщить модератору

70. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+3 +/–
Сообщение от svsd_val (ok), 14-Мрт-25, 12:13
ИМХО, не обращайте внимание, мысли в слух xD Вам не смешно читать, комменты, "вумных" людей, которые говорят как всё плохо и как надо, и о защите от ошибок программистов... И тем более о Сях как о плохом языке. И из них никто даже близко не берётся подумать что быстрее сей ТОЛЬКО ассемблер с ОЧЕНЬ читаемым кодом и Очень независимыми от платформы командами xD... Си же читабелен, понятен и многое упрощает (хотя и там для специфичных команд платформ юзается асм). И да, только благодаря отсутствию лишних проверок который компилятор возлагает на человека, получается достичь этих скоростей. Даже одна лишняя проверка в цикле на уровне ядра не в удачном месте может много порезать... А так, ну да, могут писать на языках с кучей проверок на каждый пук и получится производительность как у питона ;D Вот, тогда-то "заживём" будут защищённые ОС от простых ошибок ("Супер скоростные", что тормозить будут на последних рязанях с 128ядрами, а оперативки в 256гб будет мало даже на запуск тетриса xD ), но не от человеческого фактора (x_(x_x(O_o)x_x)_x) И там снова будут ошибки и с нова будут бэкдоры
Ответить | Правка | Наверх | Cообщить модератору

	72. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+2 +/–
	Сообщение от Weders (ok), 14-Мрт-25, 13:10
	Так и будет, просто пока бэкдоры и ошибки в коде на русте - это вина погромиста,а вот в сях/крестах - это дырявый язык, понимать надо.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от svsd_val (ok), 14-Мрт-25, 22:10
	Конечно так и есть, если программист управляет поинтерами и выходит за буфер, виноват язык, а не программист =) Если смотреть в сторону лучших практик оберон был лучшим в этом плане.
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+/–
	Сообщение от Аноним (-), 15-Мрт-25, 00:12
	> Так и будет, просто пока бэкдоры и ошибки в коде на русте - это вина погромиста,а вот в сях/крестах - это дырявый язык, понимать надо. Бекдор бекдору рознь. И ошибка тоже. Если ошибка из-за того что программер вынужден прокидывать ошибки из функции int'ами вместо нормального типа Error (я уже молчу про Result) то это действительно плохой язык. Если в языке нет типа boolean (оно же существует в математике с 18хх годов!). То это просто п̶л̶о̶х̶о̶й̶ ужасный язык. Если вместо перечислений под капотом инты и крокодилы сравниваются с апельсинами - это просто плохой язык.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	73. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	–1 +/–
	Сообщение от Аноним (-), 14-Мрт-25, 13:18
	> Вам не смешно читать, комменты, "вумных" людей, которые говорят как всё плохо и как надо, и о защите от ошибок программистов... Неа, к сожалению не смешно. Когда мой комп могут взломать просто поставив "специальный шрифт" на сайт (прошлая дыра в freetype) - это не смешно. Когда grub взламывется нажатием backspace 28 раз - это тоже не смешно. Когда CVE/RCE сыпятся как из рога изобилия - это ваще ни разу не смешно. > И тем более о Сях как о плохом языке. Он не плохой. Он просто ужасный. Если автор языка писал "The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use." > И из них никто даже близко не берётся подумать что быстрее сей ТОЛЬКО ассемблер Выбирающий скорость вместо корректности, остается и без первого, и без второго. > Си же читабелен, понятен и многое упрощает А еще С99 содержит 192 UB которые в зависимости от платформы, компилятора и даже его версии, фазы луны и астрологического прогноза могут выдавать разные результаты. #define __is_constexpr(x) \         (sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int *)8))) #define ICE_P(x) (sizeof(int) == sizeof(*(1 ? ((void*)((x) * 0l)) : (int*)1))) #define FIELD_SIZEOF(t, f) (sizeof(((t*)0)->f)) ʼшидеврыʼ понятности и читабельности прям из ядра линукс > Даже одна лишняя проверка в цикле на уровне ядра не в удачном  месте может много порезать... Например возможность получения рута. Но настоящим пограммистам на такие мелочи побоку. > А так, ну да, могут писать на языках с кучей проверок на каждый пук и получится производительность как у питона ;D Если это такой неумелый наброс на раст - то у него проверки во время компиляции. Если на с++ - то смартпойнтеры не дают такой большой оверхед. > Вот, тогда-то "заживём" будут защищённые ОС от простых ошибок Например удаленный RCE? Да, это несущественные ошибки, можно на них не обращать внимание. > ("Супер скоростные", что тормозить будут на последних рязанях с 128ядрами, а оперативки в 256гб будет мало даже на запуск тетриса xD), Твое умение передергивать и гиперболизировать заслуживает уважения. Мало кто смог бы придумать такое еб---е сравнение. Но если даже так, то мнение нищуков которые не смогут себе купить новое железо мало кого волнует. Пусть сидят на старых версиях. > но не от человеческого фактора (x_(x_x(O_o)x_x)_x) И там снова будут ошибки и с нова будут бэкдоры Но их будет меньше. Этого достаточно. Проекты становятся сложнее. И архитектурно и в коде. Человеку не надо будет тратить свой ресурс "внимание" на мелочи типа "а какой тут енам" тк ему будет подсказывать компилятор. Следовательно будет больше сил тратить на недопущение логических ошибок. ps. вообще это забавный аргумент "раз мы не можем исправить логические ошибки, то давайте положим болт вообще на все"
	Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

	75. "Уязвимость во FreeType, позволяющая выполнить код при обрабо..."	+1 +/–
	Сообщение от svsd_val (ok), 14-Мрт-25, 22:06
	>Неа, к сожалению не смешно. Когда мой комп могут взломать просто поставив "специальный шрифт" на сайт (прошлая дыра в freetype) - это не смешно. Когда grub взламывется нажатием backspace 28 раз - это тоже не смешно. Когда CVE/RCE сыпятся как из рога изобилия - это ваще ни разу не смешно. ОК, приплетайте всех и вся, а лучше, может, покажите как надо и начните уже переписывать весь софт. Да так что бы он не просел нигде и без единой ошибки ;) Между прочим имя многолетний опыт работы с разным коммерческим софтом за большую денюшку, могу сказать, что он сыпется не только на сях написанный, но и на других языках, но мы слепы и не видим этого, да и видите это потому что софт открытый, большая коммерческого софта на разных языках имеют те же проблемы правда их не афишируют и стараются закрыть в "тихаря". >Он не плохой. Он просто ужасный. Если автор языка писал "The fundamental problem is that it is not possible to write real programs using the X3J11 definition of C. The committee has created an unreal language that no one can or will actually use." Ну да, может с тем же самым успехом обратиться к мнению Ыкспертов к волочковой или валуеву ? Только вот что-то практика показывает что Он и его разновидности используются и востребованы и по сей день =) А языков которые УМЕЮТ собирать самих себя можно пересчитать по пальцам... >А еще С99 содержит 192 UB которые в зависимости от платформы, компилятора и даже его версии, фазы луны и астрологического прогноза могут выдавать разные результаты. Вы инлайны на других языках давно видели ? Там и не такое бывает, к примеру лямда функции на питоне бывают весьма вырвиглазны. Но НЕТ это проблема ТОЛЬКО Сей и ТОЛЬКО стандарта 99 года %) >Например возможность получения рута. Но настоящим пограммистам на такие мелочи побоку. Вот давайте без этого, вы основы безопасности похоже даже не знаете, если злоумышленник получил доступ к системе то вы хоть что делайте уже всё пропало... Даже всеми любимой винде такое делали, по самбе доступ уровня ядра... или через диспетчер печати ) Круто же... Давайте ещё разбирём пути получения уровней у маков ... короче где угодно можно при должной сноровке поднять свои привилегии. Но Я верую что в Вашей ОС полностью написанной с нуля на расте под микроядерную архитектору ТАКОГО точно не будет xD >Если это такой неумелый наброс на раст - то у него проверки во время компиляции. Если на с++ - то смартпойнтеры не дают такой большой оверхед. Мне глубоко начхать и на него и на другие, есть те вещи где вы будете ВЫНУЖДЕННЫ отключать проверки, даже у раста есть небезопасный код и не спроста... На моей памяти самый безопасный был ОБЕРОН и у него даже ОС была одноимённая. Работала Она быстрее других ОС и на том же оборудовании позволяла 3 видео потока декодировать на котором винда только 1 с трудом прожёвывала, но увы оно всё забыто... >Но если даже так, то мнение нищуков которые не смогут себе купить новое железо мало кого волнует. Пусть сидят на старых версиях. Круто, вы умудрились унизить большую часть человечества. КРАСАВА так держать... это ещё уметь надо. А давайте так, ВСЕ ИГРЫ и ВЕСЬ софт писать только под Nvidia RTX 5090 и только под AMD EPYC 9655P, а остальные низшие человеки не достойны пользоваться софтом =) >Но их будет меньше. Этого достаточно. Проекты становятся сложнее. И архитектурно и в коде. Человеку не надо будет тратить свой ресурс "внимание" на мелочи типа "а какой тут енам" тк ему будет подсказывать компилятор. Следовательно будет больше сил тратить на недопущение логических ошибок. Отчасти согласен, но есть пару но... Уровень подкованности упадёт, снизится качество кода и Если без изменения подхода хоть обвешайся проверками так и будем говно код в продакшн кидать. В итоге получим потребление ресурсов которое железо за приемлемые финансы не сможет обеспечить. >ps. вообще это забавный аргумент "раз мы не можем исправить логические ошибки, то давайте положим болт вообще на все" Заметьте я такого даже не говорил. Выдумывать вы горазды =)
	Ответить | Правка | Наверх | Cообщить модератору

	77. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Мрт-25, 00:05
	> ОК, приплетайте всех и вся, Почему сразу приплетать? Я привел предыдущую крупную ошибку в freetype. И знаковые уязвимости в софте написанном на СИ. > а лучше, может, покажите как надо и начните уже переписывать весь софт. В соседней теме рубятся на тему uutils) В ядре попытались начать переписывать - но диды-вахтеры раскудахтались. Пришлось даже одного выкинуть из мейнтенеров. > Да так что бы он не просел нигде и без единой ошибки ;) Опять передергивание. Для меня будет достаточно "скорость того же порядка" и надежность "лучше чем было - без ошибок памяти". > Между прочим имя многолетний опыт работы с разным коммерческим софтом за большую денюшку, могу сказать, что он сыпется не только на сях написанный,  но и на других языках, Сыплется с какими последствиями? Если просто упало - то почти пофиг, а если подарит рута - то нет. > но мы слепы и не видим этого, да и видите это потому что софт открытый, большая коммерческого софта на разных языках имеют те же проблемы правда их не афишируют и стараются закрыть в "тихаря". Я уже лет 15 в коммерческой разработке. И "незаметить" что софт упал весьма сложно. И что попортил данные тоже. > Ну да, может с тем же самым успехом обратиться к мнению Ыкспертов к волочковой или валуеву ? Вообще то это цитата Деннис Ритчи, который вместе с Керниганом этот самый СИ придумали. > Только вот что-то практика показывает что он и его разновидности используются и востребованы и по сей день =) Есть лож, наглая лож и копиум любитей СИ)) Дыряшку выкинули из почти всех ниш, которые существуют. Микроконтроллеры и прошивки уже давно можно делать на С++. Бизнес-софт - джава, мобилки - swift/kotlin. Удел СИ это древние легаси проекты. > А языков которые УМЕЮТ собирать самих себя можно пересчитать по пальцам... Компилятор раста написан на расте. И вообще странный плюс. В стиле "да у нас язык просто шерето из UB, но зато он может сам себя собрать!!11" >>А еще С99 содержит 192 UB которые в зависимости от платформы, компилятора и даже его версии, фазы луны и астрологического прогноза могут выдавать разные результаты. > Вы инлайны на других языках давно видели ? Как инлайны относятся к тоннам UB& >>Например возможность получения рута. Но настоящим пограммистам на такие мелочи побоку. > Вот давайте без этого, вы основы безопасности похоже даже не знаете, если злоумышленник получил доступ к системе то вы хоть что делайте уже всё пропало... А если он это делает через интернет? > Даже всеми любимой винде такое делали Ну давайте ориентироваться на винду) > Но Я верую что в Вашей ОС полностью написанной с нуля на расте под микроядерную архитектору ТАКОГО точно не будет xD Очередное глупейшее передергивание. В стиле "раз везде плохо, зачем делать лучше". > Мне глубоко начхать и на него и на другие, есть те вещи где вы будете ВЫНУЖДЕННЫ отключать проверки, даже у раста есть небезопасный  код и не спроста... Например для биндинга с дыряшкой) Но разница в том, что в расте часть кода небезопасна, а в СИ весь. > Круто, вы умудрились унизить большую часть человечества. КРАСАВА так держать... Это было сложно, но я смог опуститься на уровень бреда ваших заявлений про "тормозить на рязанях с 128ядрами, а оперативки в 256гб". Поэтому сочту за похвалу от "мастера глупых фантазий". > Отчасти согласен, но есть пару но... Уровень подкованности упадёт, снизится качество кода Почему? Качество кода уже дно. Программеры в ядре тупо не проверяют входные параметры. Некоторые вещи пишутся потому что "мамой клянусь там не будет null" (null конечно был, и CVE исправили через 10 лет, после того как уязвимость начали использовать). > и Если без изменения подхода хоть обвешайся проверками так и будем говно код в продакшн кидать. Предположение без подтверждений? Не удивлен. Если проверки перенести на этап компиляции, то у тебя просто не получится кинуть такой код в продакшн. > В итоге получим потребление ресурсов которое железо за приемлемые финансы не сможет обеспечить. Опять же "этап компиляции". Да у разработчика оно будет минут на 10 дольше собираться. Зато у миллионов пользователей будет быстрый код и, главное, более надежный. >>ps. вообще это забавный аргумент "раз мы не можем исправить логические ошибки, то давайте положим болт вообще на все" > Заметьте я такого даже не говорил. Выдумывать вы горазды =) А как тогда понять "И там снова будут ошибки и с нова будут бэкдоры". Я это читаю как "ну раз снова будут, то зачем вообще что-то менять".
	Ответить | Правка | Наверх | Cообщить модератору

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

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