The OpenNET Project / Index page

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

Уязвимость в GCC, позволяющая обойти защиту от переполнения стека

15.09.2023 14:04

В наборе компиляторов GCC выявлена уязвимость (CVE-2023-4039), позволяющая обойти режим "-fstack-protector", обеспечивающий защиту от атак, направленных на переполнение стека. Уязвимость проявляется только для приложений, собранных для архитектуры AArch64 и использующих динамическое выделение памяти для переменных. Проблема позволяет атакующему эксплуатировать уязвимости, приводящие к переполнению буфера при работе с динамически выделяемыми структурами, несмотря на включение защиты.

Например, защиту можно обойти при выделения памяти при помощи функции alloca() или использовании в коде массивов переменной длины (VLA, Variable-Length Arrays), предоставляющих возможность указания переменной в качестве размера при создании массива ("void foo(int n){ int m[n];}"). Уязвимость не затрагивает ядро Linux, так как использование в коде ядра массивов переменной длины было прекращено в выпуске 4.20 (2018 год).

Защита "-fstack-protector" основана на добавлении в стек после указателей и объектов канареечных меток - случайных последовательностей, неизменность которых проверяется. В случае переполнения буфера в процессе эксплуатации уязвимости канареечная метка оказывается перезаписана другими данными, что приводит к срабатыванию последующей проверки неизменности метки и инициированию аварийного завершения приложения. Суть уязвимости в том, что динамически выделяемые локальные переменные размещаются на системах AArch64 в памяти не до, а после канареечной метки и переполнение динамических переменных не приводит к повреждению метки, т.е. переполнение остаётся необнаруженным.

  1. Главная ссылка к новости (https://fosstodon.org/@Azeria@...)
  2. OpenNews: Релиз набора компиляторов GCC 11
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/59763-gcc
Ключевые слова: gcc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (43) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, InuYasha (??), 14:14, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    !ожиданно && надо_править // как раз недавно на этот самый аарч64 и собирал... Хотя, в итоге, этой опцией и не пользовался, вроде.
     
     
  • 2.6, Аноним (-), 14:25, 15/09/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 2.13, Аноним (13), 14:55, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Аноним выше написал бред:

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

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

     
     
  • 3.14, Аноним (14), 15:04, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Аноним прав, как правило в релизе задействован флаг protector-strong и protector-all является отладочным.
     
     
  • 4.38, Аноним (38), 07:23, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Это смортя кто релизит. У меня релиз c:



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



     
     
  • 5.46, Аноним (46), 15:03, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Gentoo Hardened, по умолчанию, релиз:



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



     
     
  • 6.58, Аноним (-), 14:52, 17/09/2023 Скрыто ботом-модератором     [к модератору]
  • –1 +/
     
  • 6.62, Аноним (62), 07:50, 18/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Речь шла о настройках по умолчанию, спецификациях 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'.

     

  • 1.2, Аноним (2), 14:15, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    alloca - зло
     

     ....ответы скрыты (2)

  • 1.4, Аноним (14), 14:21, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Какая продуманная архитектура у этого арма.
     
     
  • 2.19, Аноним (19), 16:20, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +6 +/
    У RISC-V еще "круче", там на безопасность сразу болт забили - проблемы с безопасностью не считаются проблемами, гениально ведь!
     
     
  • 3.25, AKTEON (?), 19:44, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Пусть погроммисты правильно код пишут !А то нарасплодилось!
     
  • 3.26, burjui (ok), 19:45, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Поясни
     
     
  • 4.39, Аноним (38), 07:30, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Прочти все ответы на этот комент: https://www.opennet.me/openforum/vsluhforumID3/129886.html#134 (О безопасной компьютерной архитектуре: CPU + ядро OS)
     
  • 2.24, Аноним (24), 19:31, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А при чем здесь архитектура арма? Все вопросы к кодогенератору gcc для нее.
     

  • 1.11, Анонин (?), 14:37, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Ахаха! Кто там в предыдущей теме раз пять лез с советами использовать -fstack-protector?
    Получите, распишитесь!
     
     
  • 2.15, Аноним (15), 15:08, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так поэтому и новость - уязвимость, а не фича. Завтра исправят и будет норм.
    А если в ядре уязвимость будет - больше ядром не пользуемся?
     

  • 1.20, Аноним (20), 17:14, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А в чём уязвимость? Без отдельной уязвимости в софте толку от этого 0, а с дополнительной - так это она и уязвимость, а не сабж. Не уязвимость это, а у-визг-вимость.
     
  • 1.21, Аноним (21), 17:27, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Сейчас любой комп это сплошная уязвимость. Те кто думает что блоб только intel me, вы сильно ошибаетесь. Блобы уже есть даже в ШИМ контроллерах, не говоря о других чипах которые так же с прошивкой.
     
     
  • 2.30, AKTEON (?), 20:58, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    И каким образом АНБ подключается к микроконтрллеру ??
     
     
  • 3.32, ИмяХ (?), 21:58, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Через вездесущие спутники илона маска
     
  • 3.52, Товарищ Ким Чен Ын (?), 09:28, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Специальной ассемблерной инструкцией или изменением битов или ещё чего-то там открывается то о существовании чего ты только догадываешься. Не зря же комп принудительно шатдаунится через 30 минут если вырезать из флешки регион IME.
     
  • 3.56, Аноним (56), 10:56, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Программатором, когда есть доступ, как и все нормальные люди. А затем делают выводы, все зависит от устройства. Проблема в том что микроконтроллер, который окончательно запрограммирован не должен выдавать лишнюю информацию, но у него могут быть недокументированные возможности.
     
  • 2.33, Аноним (33), 23:46, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Сгорел сарай, гори и хата.

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

     
     
  • 3.53, Товарищ Ким Чен Ын (?), 09:30, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > Сгорел сарай, гори и хата.

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

     
  • 3.57, Аноним (56), 11:05, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Мне кажется никакого.
     
  • 2.63, Аноним (63), 14:06, 18/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    > ШИМ контроллерах

    что это? IBV?

     

  • 1.23, Пес (?), 18:22, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Именно поэтому я за llvm/clang.
     
     
  • 2.31, C00l_ni66a (ok), 21:02, 15/09/2023 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не любишь, когда уязвимости фиксят?
     
  • 2.51, Товарищ Ким Чен Ын (?), 09:24, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Появление clang обусловлено только лицензионной шизой и не более.
     

  • 1.27, riokor (?), 19:57, 15/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    день два, да дыру залатают
     
     
  • 2.34, Аноним (34), 00:12, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Но софт собранный уязвимой версией сам не пересоберётся.
     
     
  • 3.37, Аноним (37), 02:37, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Даёшь каждому приложению по собственному серверу, как завещал Великий Ленин!
     

  • 1.36, Аноним (36), 02:13, 16/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Т.е. исправление этой ошибки облегчит отладку ошибки переполнения буфера на AARCH. Раньше это называли ошибкой, потом ишью, теперь уже уязвимость (компилятора)! Теперь вопрос — где эта архитектура применяется? Не интересовался как-то.
     
  • 1.40, Аноним (40), 08:33, 16/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Защита "-fstack-protector" основана на добавлении в стек после указателей и объектов канареечных меток - случайных последовательностей, неизменность которых проверяется...

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

     
     
  • 2.43, Tron is Whistling (?), 10:58, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Угу.
    Кмк в отрасли ныне имеет место быть параноидальная переоценка рисков.
    Множественные статьи о wifi-радарах, съёмке моргания LED при чтении смарт-карты и прочем маразме только подтверждают.
     
     
  • 3.44, Tron is Whistling (?), 11:00, 16/09/2023 [^] [^^] [^^^] [ответить]  
  • –2 +/
    А обусловлено всё гиперконцентрацией в "мегаоблачках", проникновение в которые может разом ударить по миллионам пользователей совершенно разных сервисов. Вот с этим стоило бы что-то делать, например ограничивать облачка по числу клиентов и сервисов на клиента.
     
  • 2.49, Аноним (49), 02:12, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    А у вас есть лучше идеи? Мне кажется что по другому и не возможно, разве-что другой язык использовать.
     

  • 1.50, Товарищ Ким Чен Ын (?), 09:22, 17/09/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Добрая часть современных погромистов и понятия не имеют что такое стек и как он вообще работает. Их стек это стек оверфлоу.
     
     
  • 2.60, Аноним (-), 18:16, 17/09/2023 [^] [^^] [^^^] [ответить]  
  • +/
    Стек - это первым вошёл и последник вышел.
     

  • 1.65, adolfus (ok), 19:36, 03/10/2023 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Это привет из ООП-говнопомойки.
    Кошерный ООП требует, чтобы все переменные без исключения размещались в куче. Типа, как в жабе. Из-за катастрофической потери производительности многие как-бы ООП языки забивают на теорию и выделяют память локальным (автоматическим) переменным в стеке (что совершенно правильно с точки зрения нормального разума). Не пользуйтесь языками, которые неявно выделяют память переменным в куче -- не будет проблем. Польщуйтесь явными запросами к системе для этого (malloc/new), если требуется.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



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

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