URL: https://www.opennet.dev/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 131535
[ Назад ]
Исходное сообщение
"Уязвимость в GCC, позволяющая обойти защиту от переполнения стека"
Отправлено opennews , 15-Сен-23 14:14 
В наборе компиляторов GCC выявлена уязвимость (CVE-2023-4039), позволяющая обойти режим "-fstack-protector", обеспечивающий защиту от атак, направленных на переполнение стека. Уязвимость проявляется только для приложений, собранных для архитектуры AArch64 и использующих динамическое выделение памяти для переменных. Проблема позволяет атакующему эксплуатировать  уязвимости, приводящие к переполнению буфера при работе с динамически выделяемыми структурами, несмотря на включение защиты...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59763

Содержание
Сообщения в этом обсуждении
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено InuYasha , 15-Сен-23 14:14 
!ожиданно && надо_править // как раз недавно на этот самый аарч64 и собирал... Хотя, в итоге, этой опцией и не пользовался, вроде.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 14:25 
ею в релизе никто не пользуется. это дебажная фича для тестовых прогонов.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 14:55 
Аноним выше написал бред:

> ею в релизе никто не пользуется. это дебажная фича для тестовых прогонов.

Напиши заявление на увольнение по собственному желанию, ты не компетентен.

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 15:04 
Аноним прав, как правило в релизе задействован флаг protector-strong и protector-all является отладочным.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 07:23 
Это смортя кто релизит. У меня релиз c:

--param ssp-buffer-size=1 -fstack-protector-all

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 15:03 
Gentoo Hardened, по умолчанию, релиз:
 
--param ssp-buffer-size=4 -fstack-protector-all


"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 17-Сен-23 14:52 
> Gentoo Hardened, по умолчанию, релиз:
> --param ssp-buffer-size=4 -fstack-protector-all

У генты бывают релизы? :)

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 18-Сен-23 07:50 
Речь шла о настройках по умолчанию, спецификациях gcc, для Hardened Gentoo.

Как таковых релизов Gentoo нет, но есть релизы официальных Gentoo Live сборок:
1. Minimal installation CD
2. Admin CD
3. LiveGUI DVD
Последние, правильные, сборки Admin CD и LiveGUI DVD датированы февралём 2018. Сегодняшние "пионерские сборки" не рекомендую. Сегодняшние уже могут собирать без параметров '--param ssp-buffer-size=4 -fstack-protector-all'.

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 14:15 
alloca - зло
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 14:26 
alloca - добро, сберегающее планете гигаватты.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 09:26 
alloc, пиши правильно. Aloha - это гавайское приветствие.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 14:21 
Какая продуманная архитектура у этого арма.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 16:20 
У RISC-V еще "круче", там на безопасность сразу болт забили - проблемы с безопасностью не считаются проблемами, гениально ведь!
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено AKTEON , 15-Сен-23 19:44 
Пусть погроммисты правильно код пишут !А то нарасплодилось!
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено burjui , 15-Сен-23 19:45 
Поясни
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 07:30 
Прочти все ответы на этот комент: https://www.opennet.dev/openforum/vsluhforumID3/129886.html#134 (О безопасной компьютерной архитектуре: CPU + ядро OS)
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 19:31 
А при чем здесь архитектура арма? Все вопросы к кодогенератору gcc для нее.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Анонин , 15-Сен-23 14:37 
Ахаха! Кто там в предыдущей теме раз пять лез с советами использовать -fstack-protector?
Получите, распишитесь!
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 15:08 
Так поэтому и новость - уязвимость, а не фича. Завтра исправят и будет норм.
А если в ядре уязвимость будет - больше ядром не пользуемся?
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 17:14 
А в чём уязвимость? Без отдельной уязвимости в софте толку от этого 0, а с дополнительной - так это она и уязвимость, а не сабж. Не уязвимость это, а у-визг-вимость.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 17:27 
Сейчас любой комп это сплошная уязвимость. Те кто думает что блоб только intel me, вы сильно ошибаетесь. Блобы уже есть даже в ШИМ контроллерах, не говоря о других чипах которые так же с прошивкой.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено AKTEON , 15-Сен-23 20:58 
И каким образом АНБ подключается к микроконтрллеру ??
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено ИмяХ , 15-Сен-23 21:58 
Через вездесущие спутники илона маска
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Товарищ Ким Чен Ын , 17-Сен-23 09:28 
Специальной ассемблерной инструкцией или изменением битов или ещё чего-то там открывается то о существовании чего ты только догадываешься. Не зря же комп принудительно шатдаунится через 30 минут если вырезать из флешки регион IME.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 17-Сен-23 10:56 
Программатором, когда есть доступ, как и все нормальные люди. А затем делают выводы, все зависит от устройства. Проблема в том что микроконтроллер, который окончательно запрограммирован не должен выдавать лишнюю информацию, но у него могут быть недокументированные возможности.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 15-Сен-23 23:46 
Сгорел сарай, гори и хата.

Правда неясно, какое отношение блоб Intel ME имеет к лаже в опесорсном GCC.

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Товарищ Ким Чен Ын , 17-Сен-23 09:30 
> Сгорел сарай, гори и хата.

Отношение отказаться от компьютера вообще. Л - логика. Ты только представь как жизнь упростится и сколько появится времени на общение с живыми людьми.

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 17-Сен-23 11:05 
Мне кажется никакого.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 18-Сен-23 14:06 
> ШИМ контроллерах

что это? IBV?

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Пес , 15-Сен-23 18:22 
Именно поэтому я за llvm/clang.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено C00l_ni66a , 15-Сен-23 21:02 
Не любишь, когда уязвимости фиксят?
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Товарищ Ким Чен Ын , 17-Сен-23 09:24 
Появление clang обусловлено только лицензионной шизой и не более.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено riokor , 15-Сен-23 19:57 
день два, да дыру залатают
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 00:12 
Но софт собранный уязвимой версией сам не пересоберётся.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 02:37 
Даёшь каждому приложению по собственному серверу, как завещал Великий Ленин!
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 02:13 
Т.е. исправление этой ошибки облегчит отладку ошибки переполнения буфера на AARCH. Раньше это называли ошибкой, потом ишью, теперь уже уязвимость (компилятора)! Теперь вопрос — где эта архитектура применяется? Не интересовался как-то.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 16-Сен-23 08:33 
> Защита "-fstack-protector" основана на добавлении в стек после указателей и объектов канареечных меток - случайных последовательностей, неизменность которых проверяется...

Всё так печально?

"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Tron is Whistling , 16-Сен-23 10:58 
Угу.
Кмк в отрасли ныне имеет место быть параноидальная переоценка рисков.
Множественные статьи о wifi-радарах, съёмке моргания LED при чтении смарт-карты и прочем маразме только подтверждают.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Tron is Whistling , 16-Сен-23 11:00 
А обусловлено всё гиперконцентрацией в "мегаоблачках", проникновение в которые может разом ударить по миллионам пользователей совершенно разных сервисов. Вот с этим стоило бы что-то делать, например ограничивать облачка по числу клиентов и сервисов на клиента.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 17-Сен-23 02:12 
А у вас есть лучше идеи? Мне кажется что по другому и не возможно, разве-что другой язык использовать.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Товарищ Ким Чен Ын , 17-Сен-23 09:22 
Добрая часть современных погромистов и понятия не имеют что такое стек и как он вообще работает. Их стек это стек оверфлоу.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено Аноним , 17-Сен-23 18:16 
Стек - это первым вошёл и последник вышел.
"Уязвимость в GCC, позволяющая обойти защиту от переполнения ..."
Отправлено adolfus , 03-Окт-23 19:36 
Это привет из ООП-говнопомойки.
Кошерный ООП требует, чтобы все переменные без исключения размещались в куче. Типа, как в жабе. Из-за катастрофической потери производительности многие как-бы ООП языки забивают на теорию и выделяют память локальным (автоматическим) переменным в стеке (что совершенно правильно с точки зрения нормального разума). Не пользуйтесь языками, которые неявно выделяют память переменным в куче -- не будет проблем. Польщуйтесь явными запросами к системе для этого (malloc/new), если требуется.