Проект grsecurity (https://grsecurity.net), в рамках которого развивается серия надстроек для усиления безопасности ядра Linux, сообщил (https://grsecurity.net/rap_announce.php) о важной вехе в своём развитии - в набор патчей для ядра Linux 4.5 включён механизм защиты RAP, позволяющий блокировать работу эксплоитов, основанных на технике заимствования кусков кода (https://ru.wikipedia.org/wiki/%D0%92%D0%....Данная техника атак используется для организации выполнения кода атакующего при переполнении буфера в условиях, когда в страницах памяти стека и буфера установлен запрет на исполнение кода. Суть метода в применении для построении логики выполнения shell-кода возвратно-ориентированного программирования (ROP), оперирующего уже имеющимися в библиотеках кусках машинных инструкций, завершающихся инструкцией возврата управления или перехода, как правило, это окончания предоставляемых библиотекой функций. Работа эксплоита сводится к построению цепочки вызовов подобных блоков ("гаджетов") для получения нужной функциональности. В том числе через вызов предопределённых в системной библиотеке блоков организуется работа условных операторов и циклов. Для автоматизации выявления блоков применяются специальные инструменты (https://github.com/JonathanSalwan/ROPgadget/).
Ранее предлагаемые способы защиты от атак с использованием методов возвратно-ориентированного программирования, как правило, основывались на рандомизации адреса загрузки библиотеки, который при технике ASLR меняется при каждом запуске программы. Слабая сторона такого способа в том, что атакующий может подобрать точку входа в библиотеку (определить адрес известной функции) и вычислить смещение для вызова используемых в эксплоите гаджетов, относительная позиция которых в библиотеке сохраняется. Для нарушения вычисленных атакующим смещений гаджетов предлагаются методы перемешивании всех функций системной библиотеки, но они достаточно ресурсоёмки, что мешает их практическому внедрению. Разработчики OpenBSD попытались найти компромисс и предложили (https://www.opennet.me/opennews/art.shtml?num=44320) выполнять перекомпоновку системной библиотеки на этапе загрузки системы.
Подход RAP (Return Address Protection), предлагаемый в grsecurity, позволяет достаточно надёжно блокировать атаки на основе заимствования кусков кода и при этом оказывает минимальное влияние на производительность. Суть метода (https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf) в организации проверки адресов, по которым производится возврат из функций. Для проверки используется проверочный ключ (RAP cookie), который сохраняется в резервном регистре (r12). Ключ вычисляется сразу после сохранения в стек адреса возврата и проверяется перед осуществлением выхода из функции. Если в момент выхода сохранённый и вычисленный ключи не совпадают, то переход на код функции был произведён не на начало функции.
URL: https://grsecurity.net/rap_announce.php
Новость: http://www.opennet.me/opennews/art.shtml?num=44348
https://twitter.com/marcan42/status/724745886794833920
Эй! OPENNET! Что за игнорирование такой интересной новости?!
> Команда Grsecurity приняла информацию к сведению и… забанила Мартина в твиттере и на
> сайте по IP-адресу. Разработчики также пообещали устранить проблему в следующем релизе,
> попутно оскорбив исследователя: «Надлежащее исправление (то есть не твое, мистер Капитан
> Очевидность На Белом Коне) выйдет вместе со следующим патчем, удачно тебе его скачать».(https://xakep.ru/2016/04/28/grsecurity-ban/)
Просто прекрасно же!
> (https://xakep.ru/2016/04/28/grsecurity-ban/)
> Согласно сообщениям на Reddit, Grsecurity также блокируют всех пользователей,
> кто поставил лайки твитам исследователя. Позже разработчики сообщили,
> что тестовый патч уже доступен. Один из последних твитов
> Grsecurity гласил: «Новый тестовый патч с защитой от ненужных инфосек молокососов готов».Адекватность и взрослое поведение изо всех щелей.
А когда исследователь, обнаруживший идиотский код постебался насчет бана по IP (эффективно от исследователей, лол) - они показали что еще и твиттером пользоваться не умеют. Теперь это так: "Only confirmed followers have access to @grsecurity's Tweets and complete profile.". Почти самозабанились. Но эффект Стрейзанд не забанишь.
а не мог ли всё это устроить (дыру и баны) один/несколько человек в тайне от остальных участников Grsecurity, например?
саботаж, всепроникающий m$ с гугелем, заговор мирового правительства, и всё такое...
На xakep.ru копипаст без ссылки на первоисточник.
Оригинал статьи http://www.theregister.co.uk/2016/04/27/linux_security_bug_r.../
не копипаст, а перевод. человекочитаемый перевод требует трудозатрат.
Вставление ссылки на оригинал требует трудозатрат?
Вот это полностью характеризует grsecurity. Защищаясь чёрт знает от чего, оставляют совершенно реальные дыры.Вот прав был Линус насчёт "борцов за безопасность"...
Таки да, security circus как он есть.
Однако. Тролли помогли grsec'ам самодискредитироваться.
> Однако. Тролли помогли grsec'ам самодискредитироваться.Дорогой ребенок, ты хоть сначала термины загугли, перед тем как писать откровения на опеннет.
Тролль - этот тот кто извлекает лулзы из батхеда пациента.
А тут претензия по существу и с доказательством. Это называется критика. Выучи это полезное слово.
Молодцы. Активно пользуюсь их системой защиты.
а как будете банить тех, кто минусов комменту наставил?
То есть они на эту хрень (необходимость которой вообще под вопросом) хотят угробить целый регистр. Чудесное решение, ничего не скажешь.
А что ты можешь сказать про сам регистр?
А что про него говорить? РОН как РОН, на amd64 во всяком случае
Вы правы, всем POH.
Мне - нет.
А что вы хотели они же недавно стали почти коммерческой организацией, платный доступ к их детищу. А тут какой то Мартин портит им всю безопасность. Так глупо грубить человеку который хотел помочь и помог, ведь по факту ошибку исправили.
в южном парке был выразительный эксперимент на обезъяне, которой дали охапку баксов.
grsecurity слился, они за деньги продают патчи.
И чем они отличаются от продающих эксплоиты или прочий опиум для народа? :)
А какие есть альтернативы?
Интересно, что в Astra Linux тоже используют эти патчи. Ну будем считать, что они сделали ревью кода, и знали о проблеме. Будем надеяться, что наша популяция человеков защищается профессионалами.
Существует мнение, что за те деньги, которые они распилили на линуксах, они бы могли создать полностью безопасную ОС с верифицируемым кодом. Ну будем считать, что у них есть план развития, и они его придерживаются.
> grsecurity слился, они за деньги продают патчи.Какие плохие люди, хотят денег за свою работу.
(мне тоже не нравится их поведение в твиттерной ситуации выше, но в данном случае наезд какой-то странный)
> Какие плохие люди, хотят денег за свою работу.В твитере про это ни слова, поэтому твой каммент мимо.
> (мне тоже не нравится их поведение в твиттерной ситуации выше, но в
> данном случае наезд какой-то странный)Мой маленький друг, это "наезд" странный от того, что ты недавно в теме и не знаешь порядок опубликования уязвимостей.
Тут на лицо самая типичная ситуация, когда вендор в лице gsucurity клал на сообщение о дыре. А потом появился странный, своей точки зрения, "наезд".
Конечно, было бы гораздо лучше, если бы автор заткнулся и не отсвечивал, и все прочие, кто нашел уязвимости в gsecure так же заткнулись бы и не отсвечивали. И все пользователи gsecure молча бы платили деньги за работу тем, кто делает сервера более уязвимыми, чем те были до патчей.
Ты бы был счастлив, да?
>[оверквотинг удален]
> теме и не знаешь порядок опубликования уязвимостей.
> Тут на лицо самая типичная ситуация, когда вендор в лице gsucurity клал
> на сообщение о дыре. А потом появился странный, своей точки зрения,
> "наезд".
> Конечно, было бы гораздо лучше, если бы автор заткнулся и не отсвечивал,
> и все прочие, кто нашел уязвимости в gsecure так же заткнулись
> бы и не отсвечивали. И все пользователи gsecure молча бы платили
> деньги за работу тем, кто делает сервера более уязвимыми, чем те
> были до патчей.
> Ты бы был счастлив, да?Мой огромный друк, вам бы читать внимательнее то, на что отвечаете. Меня зацепила именно претензия, что люди хотят денег за свою работу.
То, что сами люди при этом не совсем адекватны — совсем другой разговор, и про это я тоже упомянул, но с первого раза вам это, к сожалению, заметить не удалось.
Сходите на курсы по тренировке внимательности, авось, поможет.
А почему новость о технологиях одного и того же направления и сравнимого результата в случае grSecurity — основная новость, а в случае OpenBSD — мини-новость? Потому что в OpenBSD размер патча для решения задачи на порядок меньше?
> А почему новость о технологиях одного и того же направления и сравнимого
> результата в случае grSecurity — основная новость, а в случае OpenBSD
> — мини-новость? Потому что в OpenBSD размер патча для решения задачи
> на порядок меньше?1. OpenBSD некоммерческий.
2. У OpenBSD нет PR-службы.
Потому что в Grsecurity более серьёзная защита, а в OpenBSD - вариант ASLR.
>Потому что в Grsecurity более серьёзная защитаПрибитая гвоздями к x86, да еще и замедляющая работу приложений
>>Потому что в Grsecurity более серьёзная защита
> Прибитая гвоздями к x86, да еще и замедляющая работу приложенийОчень аргументированное мнение. :) Во-первых, к x86_64 в текущей версии патчей, и это не фундаментальное ограничение. Во-вторых, это самая быстрая и действенная реализация CFI вообще, "замедляющая работу приложений" на единицы процентов, т.е. на порядок меньше ближайших конкурентов, которые при этом отстают по уровню защиты. Лично вам не нужно? Ну так никто ж не заставляет.
Уже не кому не нужно, закрытая реализация костыля.
Торвальдс реализует открытую и без понтов.
Ничего закрытого. Не надо тут писать то, что прочитал на заборе.
> Ничего закрытого. Не надо тут писать то, что прочитал на заборе.Идея банить исследователя за то что он, цуко, бажный код таки изволил прочитать - это финиш. Толку с такой "открытости"?
> закрытая реализация костыля.
> Толку с такой "открытости"?Что сказать хочешь?
> Что сказать хочешь?Что возможность уронить всю систему для непривилегированного пользователя - не очень секурно. И вообще, они там жирный и глупый баг в работе с integer'ами повесили. Ну ладно бы признали и выпустили патч. Но такой реакцией они показали что ЧСВ пожрало здравый смысл и там полный улет.
Точно такой "баг", но c int вместо size_t, был и есть в оригинальном коде ядра в том же месте. В данном случае происходит ложное срабатывание механизма защиты, который и "роняет" систему, чтобы потенциальный злоумышленник не получил над ней контроль.
https://forums.grsecurity.net/viewtopic.php?t=4342Дело тут не в ЧСВ, а в том, что ложное срабатывание SIZEOVERFLOW, каких за год в grsecurity устраняется больше десятка в обычном порядке после получения багрепортов от пользователей, "исследователь" превратил в публичную драму, по сути вылив очередной ушат помоев на проект, плодами которого сам годами пользовался совершенно бесплатно. Это просто стало последней каплей.
Вот тут пишут, что твиттер @grsecurity теперь закрыт. На самом деле Brad Spengler удалил все свои сообщения и теперь использует аккаунт только для чтения чужих сообщений. А ограничение доступа поставлено, чтобы люди напрасно не фолловили.
Что до здравого смысла, то плодами проекта пользуются все без исключения основные современные ОС общего назначения, включая коммерческие. Позиция в отношении "security circus" среди большинства разработчиков линукса продиктована скорее политикой и стратегией развития, в которой сделан акцент на быстродействие и расширение функциональности, а уязвимости замалчиваются или недооцениваются (в плане возможных последствий) регулярно. При этом заявление о следовании принципам Full Disclosure в Documentation/SecurityBugs ядра никто не спешит исправлять (хотя это обсуждалось) - видимо, чтобы не создавать медиа-повода. И что-то не слышно злорадных возгласов формуных аналитиков на этот счет. Двойные стандарты, господа?
> Точно такой "баг", но c int вместо size_t, был и есть в
> оригинальном коде ядра в том же месте.Оригинальный код не падает от копипаста в терминал. Там "хак", но работает. Починка того что не сломано, с усугублением - с технической точки зрения про#б. А бан исследователя по IP, с такими коментами - фэйспалм.
> В данном случае происходит ложное срабатывание механизма защиты,
В данном случае произошла замена знакового на беззнаковое. Заведомо проблемное действие. А вот аудита логики которая предсказуемо отвалилась - не произошло. Наверное вопрос "почему?" достаточно правомерен.
> который и "роняет" систему, чтобы потенциальный злоумышленник не получил над ней контроль.
В данном случае непривилегированный пользователь может всю систему завалить. И Linux превращается, превращается линукс... в элегантный MS-DOS?
> Дело тут не в ЧСВ, а в том, что ложное срабатывание SIZEOVERFLOW,
> каких за год в grsecurity устраняется больше десятка в обычном порядкеЯ не вижу чего этот исследователь сделал такого уж из ряда вон. Спросил почему у них так получается? Глядя на этот патч такой вопрос возникает.
> после получения багрепортов от пользователей, "исследователь" превратил в публичную драму,
Не вижу ничего драматичного в начальном сообщении. Обычное сообщение об ошибке с удивлением как такая ошибка вообще проскочила в таком проекте. Драма началась после бана. Это уже ожидаемо, поскольку такой реакции на репорт позавидует Oracle и Microsoft.
> по сути вылив очередной ушат помоев на проект, плодами которого сам
> годами пользовался совершенно бесплатно. Это просто стало последней каплей.Для ушата это как-то слабовато. Ну и повод все-таки был. Бывает и хуже. Некоторым сразу CVE прилетает, а то и эксплойт в диком виде.
> Вот тут пишут, что твиттер @grsecurity теперь закрыт. На самом деле Brad
> Spengler удалил все свои сообщенияПоскольку доступ закрыт - это очевидно далеко не всем. А твиттер пишет что наоборот надо запрос оставить - и тогда может быть заfollow'ят.
> и теперь использует аккаунт только для чтения чужих сообщений.
А зачем для этого аккаунт вообще?
> А ограничение доступа поставлено, чтобы люди напрасно не фолловили.
С учетом того что там пишет твиттер и такого дурного пиара - думаю его напротив завалит запросами на follow, каждый будет пытаться поиграть в шпиона. Половина достаточно успешно - на реддите "шпионы" которых зафолловили отписываются.
> Что до здравого смысла, то плодами проекта пользуются все без исключения основные
> современные ОС общего назначения, включая коммерческие. Позиция в отношении "security
> circus" среди большинства разработчиков линукса продиктована скорее политикой и стратегией
> развития, в которой сделан акцент на быстродействие и расширение функциональности,Да, их не устроит если их система резко превратится в MSDOS, который валится любой "недружелюбной" программой любого пользователя. И наверное в этом есть пойнт.
> а уязвимости замалчиваются или недооцениваются (в плане возможных последствий) регулярно.
Обычно локальное повышение прав. Бяка, но лучше или хуже ли это чем локальный DoS - интересный вопрос.
> При этом заявление о следовании принципам Full Disclosure в Documentation/SecurityBugs
> ядра никто не спешит исправлять (хотя это обсуждалось) - видимо, чтобы не создавать медиа-повода.Они наверное догадываются что к этому стоит стремиться, но если слишком педалировать тему - потом недовольные пользователи спросят: как же так, вы секурити обещали, а тут MSDOS какой-то, когда Вася мне сервер роняет потому что у него шелл там есть.
> И что-то не слышно злорадных возгласов формуных аналитиков
> на этот счет. Двойные стандарты, господа?Не то чтобы, просто те кто вокруг секурити получают более высокие ожидания аудитории и облом этих ожиданий чреват серьезным штормом. Что и произошло. Тому немало способствовала странная реакция. Забанить исследователя по IP - таки security circus.
> Починка того что не сломано, с усугублением - с технической точки зрения про#б.Вы понимаете, что на каждый такой "про#б" приходится несколько обезвреженных или смягченных по последсвиям уязвимостей, включая неопубликованные? Раздуваете из мухи слона, преувеличивая техническую значимость ошибки, притягивая для этого человеческую реакцию в твиттере. Пользователи grsecurity осведомлены о возможных неудобствах, ложных срабатываниях, ошибках, сталкиваются с ними на практике рано или поздно, и ничего. Вы, когда излагаете свою версию, кому-то глаза хотите открыть?
> Наверное вопрос "почему?" достаточно правомерен.
Потому что каждый человек рано или поздно ошибается. В начале нулевых в PaX была найдена и опубликована уязвимость, позволяющая выполнить произвольный код в контексте ядра, но я не знаю ни одного пользователя grsecurity, который на этом основании стал бы вешать ярлыки на проект. В основном этим занимаются совершенно посторонние и плохо информированные люди.
> И Linux превращается, превращается линукс... в элегантный MS-DOS?
Снова двойные стандарты. Линукс давно "превратился в MS-DOS", если следовать такой логике. Например, RLIMIT_RSS еще в 2.6.0 работать перестал. Где же публичное негодование по поводу юбилея уязвимости к злонамеренному исчерпанию доступной памяти посредством mmap()? Можете хоть один дистрибутив назвать, где этой проблеме нашли хотя бы эрзац-решение (к примеру, через лимиты memory resource controller на базе контрольных групп)?
> Я не вижу чего этот исследователь сделал такого уж из ряда вон.
Вывалил уязвимость в твиттер, с неуместными комментариями. Так даже фанатики от Full Disclosure не работают. Кстати, никакой он не исследователь, а обычный пользователь, который случайно столкнулся с ошибкой на практике.
> Драма началась после бана. Это уже ожидаемо, поскольку такой реакции на репорт позавидует Oracle и Microsoft.
Это ваша оценка как человека, который не имеет ни малейшего понятия о контексте, в котором команде grsecurity приходится работать. Почитайте комментарии хотя бы на этом сайте - сколько здесь эмоций и голословных обвинений на фоне полного невежества и ложных представлений. Я со стороны наблюдаю эту картину в течение многих лет и только удивляюсь тому, насколько редко у ребят нервы сдают.
> Поскольку доступ закрыт - это очевидно далеко не всем.
Вы против? :) Думаю, в данный момент Брэду просто плевать на твиттер и общественное мнение. Собака лает - караван идет. Все пользователи grsecurity, кому было не понятно, уже задали вопросы в IRC или по почте.
> Да, их не устроит если их система резко превратится в MSDOS, который валится любой "недружелюбной" программой любого пользователя. И наверное в этом есть пойнт.
Даже если не спорить, придерживаются ли разработчики ядра такой точки зрения, то на каждый подобный просчет приходится, как я уже сказал, по несколько обезвреженных или "смягченных" уязвимостей в основном коде ядра. Но вас эта сторона вопроса мало интересует, не так ли?
> Обычно локальное повышение прав. Бяка, но лучше или хуже ли это чем локальный DoS - интересный вопрос.
Что значит, лучше или хуже? Локальное повышение привилегий это всегда как минимум локальный DoS.
> Они наверное догадываются что к этому стоит стремиться, но если слишком педалировать тему - потом недовольные пользователи спросят: как же так, вы секурити обещали, а тут MSDOS какой-то, когда Вася мне сервер роняет потому что у него шелл там есть.
Если вас интересует, как оно на самом деле, почитайте дискуссии на LKML по ключевым словам "security bugs are just bugs", "SecurityBugs" и "full-disclosure".
> Не то чтобы, просто те кто вокруг секурити получают более высокие ожидания аудитории и облом этих ожиданий чреват серьезным штормом. Что и произошло.
Снова двойные стандарты. Например, конкретные способы обхода KASLR, который включен в официальный код ядра, публикуются регулярно, а сам их принцип и вытекающая неэффективность KASRL была очевидна еще до его включения. Где же недоумевающая аудитория? :) Или негодующие читатели рекламных материалов Red Hat, в которых SELinux позиционируется в том числе как инструмент защиты ядра?
> Забанить исследователя по IP - таки security circus.
Это медиа-повод и не более. Для тех, у кого нет более важных дел. Настоящий цирк - это реальный уровень безопасности в линуксе и столь же низкий уровень осведомленности масс, а также политика двойных стандартов, лицемерие и сокрытие информации, которым многие пытаются найти оправдание, вместо того, чтобы назвать вещи своими именами.
> годами пользовался совершенно бесплатно.Там выше ребенок утверждал что не бесплатно. Кто из вас врёт?
Стабильная ветка бесплатна по сей день. Стабильная ветка LTS платна с начала прошлой осени. Есть коммерческая поддержка.
Никогда он ничего подобного не реализует.
> Потому что в Grsecurity более серьёзная защита, а в OpenBSD - вариант
> ASLR.Аргументируйте, пожалуйста, почему «более серьёзная»? И почему связанное с ASLR решение опёнковцев хуже, тоже.
> Аргументируйте, пожалуйста, почему «более серьёзная»? И почему связанное с
> ASLR решение опёнковцев хуже, тоже.Попробуйте самостоятельно разобраться. Ссылка на слайды к презентации по RAP есть в новости, способы обхода ASLR несложно нагуглить.
>> Аргументируйте, пожалуйста, почему «более серьёзная»? И почему связанное с
>> ASLR решение опёнковцев хуже, тоже.
> Попробуйте самостоятельно разобраться. Ссылка на слайды к презентации по RAP есть в
> новости, способы обхода ASLR несложно нагуглить.Я хочу услышать ваши аргументы, так как утверждение высказано именно вами, и разговор идёт именно с вами. Я могу точно также сказать «вы не правы, подробности в Гугле» (или наоборот), и это, согласитесь, будет идиотизмом.
А я со своей стороны не хочу вступать в спор с человеком, который спрашивает об очевидных, на мой взгляд, вещах, но при этом не проявляет заинтересованности по существу вопроса.
> А я со своей стороны не хочу вступать в спор с человеком,
> который спрашивает об очевидных, на мой взгляд, вещах, но при этом
> не проявляет заинтересованности по существу вопроса.Я не так давно нашёл, например, небольшую ошибку в OpenBSD-ом коде по этой части (уже исправлена). И чем одно отличается от другого — понимаю хорошо. А вот сравнение с учётом минусов обоих решений — было бы интересно. Если у вас его нет, а есть только очевидная вам очевидность — что ж, сидите дальше со своим сакральным знанием, и без вас разберёмся.
> — мини-новость? Потому что в OpenBSD размер патча для решения задачи
> на порядок меньше?В OpenBSD не решение, а костыль, и оно ещё только предложено, а не включено в состав системы.
> В OpenBSD не решение, а костыль, и оно ещё только предложено, а
> не включено в состав системы.Сабж тоже внешний костыль, не включенный в состав системы.
>> — мини-новость? Потому что в OpenBSD размер патча для решения задачи
>> на порядок меньше?
> В OpenBSD не решение, а костыль, и оно ещё только предложено, а
> не включено в состав системы.Уже включено.
А вот соответствующий патч от grsecurity в mainline что-то не видно.
спасибо за статью. добавил grsecurity в спам лист как распостранителей малвари.
https://grsecurity.net/rap_faq.php
Отличная новость от очень хорошего проекта.Спасибо команде Grsecurity & PAX за их труд!
ЗЫ: видать не все здесь ещё доросли до этого проекта.. Автору новости не стоило бисер перед свиньями рассыпать.
> Отличная новость от очень хорошего проекта.
> Спасибо команде Grsecurity & PAX за их труд!А за мир и май? забыл?
Идея хорошая, и реализация, возможно, неплохая. Плохо, что за деньги и закрытое.Вдвойне плохо тем, что, если, например, делаешь свой дистрибутив с такой защитой, то пользователи не смогут скомпилировать свои пакеты, так как тулчейн закрытый, и выкладывать его нельзя.
В контексте grsecurity "закрыты" только grsec-патчи для ядер LTS-веток и дополнительный вероятностный механизм защиты адреса возврата. Патчи для веток ядра, которые раньше и сейчас используются в Gentoo и Arch, остаются открытыми. И вообще RAP сейчас доступен только в публичной версии 4.5. Для 4.4 его, возможно, портируют, а для 3.14 не портируют точно.
и реализация ASLR и типизации и доменификации доступа/активности - там довольно наивно реализовано, поэтом гротэскно смотрятся попытки - это еще и продать.