The OpenNET Project / Index page

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

Checkpoint предложил технику защиты Safe-Linking, усложняющую эксплуатацию уязвимостей

23.05.2020 12:21

Компания Checkpoint представила механизм защиты Safe-Linking, позволяющий усложнить создание эксплоитов, манипулирующих определением или изменением указателей на буферы, выделенные при выполнении вызова malloc. Safe-Linking полностью не блокирует возможность эксплуатации уязвимостей, но при минимальных накладных расходах существенно усложняет создание некоторых категорий эксплоитов, так как помимо эксплуатируемого переполнения буфера необходимо найти ещё одну уязвимость, вызывающую утечку сведений о размещении кучи (heap) в памяти.

Патчи с реализацией Safe-Linking подготовлены для Glibc (ptmalloc), uClibc-NG (dlmalloc), gperftools (tcmalloc) и Google TCMalloc, а также предложены для модернизации защиты в Chromium (в Chromium с 2012 году уже встроена нацеленная на решение той же проблемы техника защиты MaskPtr, но решение от Checkpoint демонстрирует более высокую производительность). Предложенные патчи уже одобрены для поставки в августовском выпуске Glibc 3.32 и применение Safe-Linking будет включено по умолчанию. В uClibc-NG поддержка Safe-Linking вошла в состав выпуска 1.0.33 и включена по умолчанию. В gperftools (старый tcmalloc) изменения приняты, но будут предложены в одном из будущих выпусков в качестве опции.

Разработчики TCMalloc (новый tcmalloc) отказались принять изменение, сославшись на сильное снижение производительности и необходимость добавления расширенных тестов для регулярной проверки того, что всё работает должным образом. Тестирование же инженерами Checkpoint показало что метод Safe-Linking не приводит к дополнительному расходу памяти, а производительность при выполнении операций с кучей в среднем снижается лишь на 0.02%, а при наихудшем стечении обстоятельств на 1.5% (для сравнения накладные расходы в применяемом в Chromium методе оцениваются как "меньше 2%"). Включение Safe-Linking приводит к выполнению 2-3 дополнительных ассемблерных инструкций при каждом вызове free() и 3-4 инструкций при вызове malloc(). Запуск стадий инициализации и генерации случайных значений не требуется.

Safe-Linking может применяться не только для повышения безопасности различных реализаций кучи (heap), но и для добавления средств контроля целостности в любые структуры данных, в которых применяются односвязные списки указателей, размещаемые рядом с самими буферами. Метод очень прост в реализации и требует лишь добавления одного макроса и его применения к указателям на следующий блок в коде (например, для Glibc изменяется всего несколько строк в коде). Метод сводится к следующим изменениям:



   +#define PROTECT_PTR(pos, ptr) \
   +  ((__typeof (ptr)) ((((size_t) pos) >> 12) ^ ((size_t) ptr)))
 
   +#define REVEAL_PTR(ptr)  PROTECT_PTR (&ptr, ptr)

   -       nextp = p->fd;
   +       nextp = REVEAL_PTR (p->fd);
   ...

Суть метода в применении случайных данных от механизма рандомизации адресов ASLR (mmap_base) для защиты односвязных списков, таких как Fast-Bins и TCache. Перед применением к значению указателя на следующий элемент в списке выполняется преобразование по маске и проверка выравнивания по границе страницы памяти. Указатель заменяется на результат операции "(L >> PAGE_SHIFT) XOR (P)", где P - значение указателя, а L - местоположение в памяти, где хранится этот указатель.

При использовании в системе ASLR (Address Space Layout Randomization) часть битов L с базовым адресом кучи содержат случайные значения, которые используется как ключ для кодирования P (извлекаются операцией сдвига на 12 бит для 4096-байтовых страниц). Подобная манипуляция снижает риск захвата указателя в эксплоите, так как указатель не хранится в исходном виде и для его замены требуется знать сведения о размещении кучи. Кроме того, в коде патча также присутствует дополнительная проверка выравнивания блока, которая не позволяет атакующему заменить указатель на невыровненное значение и требует знания числа бит, на которые произведено выравнивание, что на 64-разрядных системах дополнительно позволяет блокировать 15 из 16 попыток атак, не учитывающих выравнивание.

Метод эффективен для защиты от атак, в которых используются частичное переопределение указателей (изменение младших байтов), полная перезапись указателей (перенаправление на код атакующего) и смена позиции списка по невыровненному адресу. В качестве примера показано, что применение Safe-Linking в malloc позволило бы блокировать эксплуатацию недавно выявленной теми же исследователями уязвимости CVE-2020-6007 в умной подсветке Philips Hue Bridge, вызванной переполнением буфера и позволяющей получить контроль над устройством.

  1. Главная ссылка к новости (https://blog.checkpoint.com/20...)
  2. OpenNews: Проект grsecurity опубликовал реализацию механизма защиты RAP для ядра Linux
  3. OpenNews: Планы по усилению механизма защиты W^X в OpenBSD
  4. OpenNews: Проект по продвижению в ядро Linux новых технологий активной защиты
  5. OpenNews: В OpenBSD добавлена новая защита от атак на основе заимствования кусков кода
  6. OpenNews: В состав OpenBSD-Current добавлен механизм защиты RETGUARD
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/53013-safe-linking
Ключевые слова: safe-linking, malloc, checkpoint, glibc
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (96) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 12:47, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –27 +/
    Чего только люди не придумают, лишь бы не писать на memory-safe языках...
     
     
  • 2.3, Аноним (3), 12:55, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +32 +/
    потому-что есть разница между +3~4 строками ассемблема и +over9000
     
  • 2.7, z (??), 14:21, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Кто заплатит за оверхед пистона и пр. высокоуровневой мути в системный библиотеках?
     
     
  • 3.71, YetAnotherOnanym (ok), 10:46, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Пользователи, конечно! Что за странные вопросы...
     
  • 2.8, Онаним (?), 14:27, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +22 +/
    В самом деле. Как только не изголяются, чтобы не потерять половину производительности на ровном месте.
     
  • 2.17, Фантик Хруста (?), 15:12, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Правильно нужно на РАСТЕ всё писать
     
     
  • 3.21, Аноним (-), 15:31, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И тогда троянцев вгрузят прямо из хранилища карго-культа, оптом. Всем и сразу. Вы же не хотите сказать что мозилла может сколь-нибудь безопасно это содержать?
     
  • 3.52, deeaitch (ok), 00:05, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Да, а параметры в функцию передавать через https+jsob/bson

    Бинарные файлы вообще хранить в строках base64 и пото всё это постоянно парсить, писать парсеры парсеров парсеров парсеров, чтобы обпарсилось всё в хлам.

    И везде должны быть гамбургеры меню.

     
     
  • 4.59, Аноним (59), 01:30, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Как ты умудрился всё это у себя в голове с ржавчиной связать?
     
     
  • 5.73, Аноним (73), 11:24, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Код на ржавчине наверное позырил. Там такие конструкции попадаются что им даже самые тертые плюсовики-извращенцы позавидуют.
     
  • 5.91, deeaitch (ok), 19:16, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Как ты умудрился всё это у себя в голове с ржавчиной связать?

    Очень просто. Горепрограммисты обычно такую кашу и делают. И обычно именно горе програмисты и кричат больше всего что rust спасёт мир и это единственно верный язык. Слепо веря что компилятор вылечит их от тупости.

     
  • 2.20, Аноним (-), 15:31, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > лишь бы не писать на memory-safe языках...

    Ну тогда и ножик с кухни выкинь, им порезаться можно.

     
     
  • 3.53, deeaitch (ok), 00:06, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мозг надо выкинуть, он иногда сбоит и подталкивает к самоубийству.
     
  • 2.24, Аноним (24), 15:39, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Какие только memory-safe языки не придумают, лишь бы не учиться нормально программировать...
     
     
  • 3.54, deeaitch (ok), 00:09, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Так он не memory-safe внезапно. Это идиотская видимость.

    Внезапно C++ тоже memory-safe. Пользуйся исключительно stl, не пользуй динамическую память напрямую (аля safe - unsafe в rust), которого хватает для 90% задач и не будет проблем. Внутри работа с памятью выверена и перепроверена десятелетиями. Тот-же unsafe внутри rust от которого они так кипятком писают.

    Просто когда у человека в колове полный unsafe то ему ни один язык уже не поможет. Там уже топор нужен.

     
     
  • 4.74, Аноним (74), 11:26, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если на то пошло - в сях так например никто и не заставляет pointer'ы использовать, равно как и динамическое выделение памяти. И поэтому при наличии желания можно и на сях безопасно и предсказуемо, а при отсутствии и на пыхапэ сплошная дыра получается, хоть там и нет указателей.
     
     
  • 5.89, n00by (ok), 17:04, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если на то пошло - в сях так например никто и не
    > заставляет pointer'ы использовать, равно как и динамическое выделение памяти.

    Если память распределена статически, её объём фиксирован и, в общем случае, недостаточен.

     
  • 5.95, deeaitch (ok), 19:25, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если на то пошло - в сях так например никто и не
    > заставляет pointer'ы использовать, равно как и динамическое выделение памяти. И поэтому
    > при наличии желания можно и на сях безопасно и предсказуемо, а
    > при отсутствии и на пыхапэ сплошная дыра получается, хоть там и
    > нет указателей.

    Это кстати именно так. К слову в контроллерах вообще не используется динамическая память. И ничего, пишут на c\c++ и проблем не знают.

     
  • 4.88, Аноним (88), 16:01, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я все время говорю что rust гораздо более опасный язык программирования чем Си. Одни только unsafe блоки чего стоят.
    Никто не будет писать системное по на опастном rust если есть более безопасный Си в котором нет unsafe блоков
     
     
  • 5.96, deeaitch (ok), 19:25, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Я все время говорю что rust гораздо более опасный язык программирования чем
    > Си. Одни только unsafe блоки чего стоят.
    > Никто не будет писать системное по на опастном rust если есть более
    > безопасный Си в котором нет unsafe блоков

    Вот и я о примерно тоже.

     
  • 2.27, Аноним (27), 16:26, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    А что, в memory-safe языках под капотом не malloc/free?
     
     
  • 3.36, Lex (??), 17:41, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В том же Расте вроде нет.. раньше. Но тогда хэллоувроды весили под 300Кб ( на асм - 2Кб и то, из-за выравнивания и проч, т.к в секции кода оставалась куча неиспользованного пространства ).
    А потом.. в потом - господа решили использовать для работы с памятью системное апи.
    Хотя мб я и ошибаюсь..

    В случае с остальными.. а такие вообще реально существуют ?)
    Всм, чтобы и у прог, написанных на них, никаких проблем не было, но чтобы и кто-то со стороны их "бомбануть" принципиально не мог

     
     
  • 4.55, deeaitch (ok), 00:10, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сам то понял что сказал? rust пускается на операционной системе а не в сферическом вакууме.
     
     
  • 5.69, Lex (??), 06:26, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сам то понял что сказал ?
    Само-собой, что запускается на системе и, в конечном счёте, память запрашивается у неё, но malloc в данном случае - просто сишное поделие и сишная прослойка к ОС и «абстракция»( к примеру, у той же винды, насколько помню, память выделяется посредством winapi VirtualAlloc ).
     
     
  • 6.92, Аноним84701 (ok), 19:19, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    И заодно рантаймлиба немалого размера - к которой и линкуются все маленькие си... большой текст свёрнут, показать
     
     
  • 7.97, Lex (??), 12:24, 25/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Сишные приложения и сами по себе не шибко маленькие, так за ними еще и тонны ран... большой текст свёрнут, показать
     
  • 2.50, deeaitch (ok), 00:03, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Каких только глупостей люде не придумают лишь бы мозг не включать.
     
     
  • 3.60, Аноним (60), 01:45, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Очень неосмотрительно ассоциациировать попытку привнести больше безопасности в мир с чем-то отрицательным.
    Да, полной безопасности не бывает, опасность может затаиться и в языке с VM/GC, и на уровне ошибок железа.
    Но если можно что-то автоматизировать, особенно когда это касается безопасности, это НУЖНО делать.

    И C, и C++ навсегда останутся оружием для стрельбы по ногам, в большей или меньшей степени, при всей моей любви к C++.
    И никакой мозг не поможет не совершить ни одной ошибки в коде, если проект больше хелловорлда. Никакой.

     
     
  • 4.81, YetAnotherOnanym (ok), 11:54, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Очень неосмотрительно ассоциировать потакание неряшливости и лености ума с попыткой привнести больше безопасности в мир

    Можешь не благодарить.

     
     
  • 5.85, Аноним (60), 15:23, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Чушь.
    Написание на C не приводит к ряшливости ума, а лишь порождает баги на пустом месте из-за абсолютного unsafe. Которые потом годами могут висеть и внезапно вылезать в самый неподходящий момент как мировая уязвимость.
    Любая автоматизация - это благо и повышение эффективности.

    Естественно, подход раста не панацея, но безопаснее, при этом он удобнее для рутинных действий, вроде банального подключения библиотек.
    И даёт возможность сосредоточиться на бизнес-логике, а не отладке сегфолтов.

     
     
  • 6.86, YetAnotherOnanym (ok), 15:37, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А Вы писали на C и в ваших программах вылезали баги? Или анализировали баги в чужих программах и определили, то они появились благодаря "абсолютному unsafe"?
     
     
  • 7.98, Аноним (60), 16:40, 26/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    C++ в основном, в контексте разница не велика, stl или qt core вообще не панацея, а скорее затычка в днище
    Баги только логические, а из-за языка сегфолты. Конечно, это дебажится и правится, но веселее править эти падения в чужом коде. Или многопоточном, когда дебаггер иногда сам не выкуривает, где пошло что-то не так
    Так что да, из-за unsafe
    О чем говорить, если взятие ссылки на элемент в векторе и пуш - это уже жесткое ub
    И такие ub на каждом шагу, иногда и не заметишь, и будет годами висеть
     
     
  • 8.99, YetAnotherOnanym (ok), 11:54, 27/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну не знаю Я писал на простом C, у меня всё работало корректно Возможно, это... текст свёрнут, показать
     
  • 4.82, Аноним (82), 11:56, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Мозилла корп, огестапливающая свою паству там и тут почему-то не ощущается "безопасно".
     
  • 4.93, deeaitch (ok), 19:22, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Что-то у меня ничего не падает, не течет и в ногу ни разу не попал Нет, я не го... большой текст свёрнут, показать
     
  • 3.68, Аноним (68), 02:37, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Умный ходить по минному полю не будет.
     
     
  • 4.94, deeaitch (ok), 19:23, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Умный ходить по минному полю не будет.

    Да госпади, где вы это минное поле то нашли? Хоть бы почитали какие книжки. Пользуйся рамками stl и не будет тебе никакого минного поля. Если у тебя такая паническая атака от одного только упомиания динамической памяти и указателе.

     
  • 2.51, deeaitch (ok), 00:03, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Каких только глупостей люде не придумают лишь бы мозг не включать.
     

  • 1.2, Аноним (2), 12:51, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    А как же jemalloc? Или он уже не модный? 4 года назад он был эффективней и в отличие от gperftools не вызывал зависаний при половине свободной памяти.
     
     
  • 2.37, Lex (??), 17:42, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Из того же раста его вроде выкинули-таки..
     
     
  • 3.43, имя (ok), 17:59, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    В расте скорее дали свободу выбора аллокатора и выкинули очередной багаж времён экспериментов в версиях 0.x, когда там был жирный рантайм и зелёные треды. Никто не мешает продолжать линковать приложения с jemalloc, если хочется.
     

  • 1.4, Fracta1L (ok), 13:13, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –8 +/
    Сколько утомительной работы вокруг сишных дыр...
     
     
  • 2.15, Аноним (15), 15:06, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Давай, фрактал, пришло твоё время, расскажи как правильно, мы внемлим.
     
     
  • 3.25, Аноним (-), 15:39, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Можно забить на программирование и пойти выращивать рассаду. Тогда дыры будут только в земле.
     
     
  • 4.38, Lex (??), 17:43, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    На самом деле, не такая уж и плохая идея. Тем более, как раз самый сезон :)
     
     
  • 5.40, InuYasha (?), 17:49, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Хочешь быть передовым - сей квадратно-гнездовым!
     
     
  • 6.61, Аноним (61), 01:59, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Наша главная задача - молотьба и хлебоздача!
     
  • 2.56, deeaitch (ok), 00:12, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Тыб уже написал чтонибудь дельное на своё истинно верном языке который спасает от всех проблем. Что-то такое чем пользоваться можно было бы.
     
     
  • 3.64, псевдонимус (?), 02:14, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >дельное
    >Фрактал

    Выбери что-нибудь одно.

     

  • 1.5, qwe (??), 13:49, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    Одни не принимает патч из-за дополнительных 5-7 ассемблерных инструкций, зато другие смело хватаются за электрон при написании хеллоувордов. Эх.
     
     
  • 2.6, Аноним (2), 13:56, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    У вторых электрон просаживается в 10 раз когда первые вставляют дополнительные 5-7 ассемблерных инструкций.
     
     
  • 3.41, InuYasha (?), 17:52, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    И все вместе хватаются за голову когда дополнительные 5-7 ассемблерных инструкций вставляют в микрокод разработчики процов и прошивок. )
     

  • 1.9, Онаним (?), 14:29, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    А по теме - да, это нужно внедрять, как опцию. Приятным бонусом будет ловля не всегда очевидных сразу блох с указателями.
     
  • 1.10, Аноним (10), 14:30, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –7 +/
    На rust пиши, проблем не знай.
     
     
  • 2.11, Crazy Alex (ok), 14:41, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Дядь, в борьбе с переполнениями есть ровно два варианта - ренжи, которые есть далеко не только в расте, и bound checks, которые тоже можно сделать где угодно, только тупят они тоже где угодно.

    В общем, как и всё в расте - либо то же самое тривиально делается (и давно стало стандартной практикой) в плюсах - либо тоже тривиально делается, но опционально потому что имеет жирные минусы.

     
     
  • 3.46, Аноним (10), 20:03, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В rust оно всё есть из коробки и для всех, ваш юный джун не обосрется.
     
     
  • 4.75, Аноним (74), 11:29, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Поэтому он наломает дров в десятке других мест. Проверено WormPress'ом и прочими джумлами :)
     
  • 2.22, Аноним (-), 15:33, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > На rust пиши, проблем не знай.

    Красиво было на бумаге, да забыли про овраги. Очередной спаситель человечества. И как обычно карманный проектик одной стремной корпорахи. Примерно как D.

     
     
  • 3.30, Crazy Alex (ok), 16:51, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Эй, D вообще не из той серии - там тот же подход, что и в плюсах - все инструменты доступны, выбирай нужное подмножество, никакого концлагеря. Профит исключительно от отказа от исторически накопившихся в плюсах костылей вроде компиляции сишного кода или адски запутанной системы шаблонов.
     
     
  • 4.76, Аноним (74), 11:32, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > выбирай нужное подмножество, никакого концлагеря.

    Если не считать того что дохрена лет был 1 компилер, делаемый 1 полупроприетарной чтототам-mars-corporation, или как там его. И общего тут то что mozilla corp с примерно теми же причудами в примерно той же позе, только еще чтобы совсем уж концлагерно, репу завели, с нахрапом впаривают и конечно же содержится все это именно той корпой, в последнее время очень переклиненой на том чтобы строить других. Чем, собственно, и заколебали разработчиков своей экосистемы в край.

     
  • 2.57, deeaitch (ok), 00:14, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > На rust пиши, проблем не знай.

    Именно, всё равно это никому надо не будет, вот и дыр нет.

     

  • 1.12, Crazy Alex (ok), 14:44, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Чудесно, все прочие тормоза "защит" умножили ещё на один коэффициент. Если всё ампутировать производительность, небось раза в три поднимется.
     
     
  • 2.26, solardiz (ok), 15:43, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    К счастью, нет, в большинстве случаев это так не работает. Например, эта правка malloc'а не замедляет дополнительно защиту от Meltdown с помощью KPTI, и наоборот. Тут речь идет приблизительно о сложении, а не об умножении. Если попытаться найти пример другой защиты, последствия которой для производительности умножались бы на получаемые от дополнительных инструкций в malloc, в голову приходит только выключение speculative store bypass в CPU, но это сейчас делают только в программах, явно запросивших такую защиту через prctl, и при использовании seccomp.
     
     
  • 3.28, Crazy Alex (ok), 16:47, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Конкертно это - пожалуй, да. Но очень интересно было бы сравнить нынешний "дефолтный" код с "чистой" версией - без ASLR, stack protection и прочего, в идеале - с защитой исключительно от ошибок, а не атак.
     
     
  • 4.32, Аноним (-), 16:53, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > с защитой исключительно от ошибок, а не атак.

    DJB определил уязвимости как ошибки, ведущие к проблемам безопасности. Так что если исключительно все ошибки исключить, проблемы безопасности тоже должны исключиться, как частный случай. Но что надо сделать с людьми чтобы исключить все ошибки в коде - вопрос открытый.

     
     
  • 5.35, Crazy Alex (ok), 17:05, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я имею в виду ситуацию, когда мы вообще никаких атак не ожидаем и не боимся. То есть мы, конечно, не хотим, чтобы по ошибке одно приложение переписало память другого или забрало себе все ресурсы системы (поэтому некоторая изоляция таки нужна), но именно злонамеренных действий не ждём.
     
     
  • 6.77, Аноним (-), 11:39, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Я имею в виду ситуацию, когда мы вообще никаких атак не ожидаем и не боимся.

    Для обычного десктопника или сервера это достаточно синтетическая ситуация. Даже просто посмотреть картинку или музычку послушать - уже untrusted input в общем случае.

    Единственный юзкейс который я могу вспомнить vs алгоритмы: в демке на speccy чувак юзал unsafe версию декомпрессора, забивающую на проверку всяких глупостей. Ну, в крайнем случае, если демка сдуреет, поезд с рельсов не сойдет, банки не взломают, так что и черт с ним. Вот там на отсутствии проверок у чувака был солидный профит, при ориентации на столь тормозной проц как бы актуально. Однако ценность такого кейса ... вызывает определенные вопросы.

     
  • 5.47, Sw00p aka Jerom (?), 20:53, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >Но что надо сделать с людьми чтобы исключить все ошибки в коде - вопрос открытый.

    когда капуста, козы и волки в одной лодке никакие перегородки не спасут. Может все таки архитектура Фон Неймана - УГ?

     
     
  • 6.78, Аноним (-), 11:41, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Может все таки архитектура Фон Неймана - УГ?

    Как бы MMU/MPU позволяют разграничивать что и где. А чистый гарвардец офигенная штука. Попробуй блин под него хотя-бы бутлоадер написать. Так что вон в AVR в RAM извне вгрузить прошивалку совсем низя, а в флехе - пока флеха шьется, все встает раком, в том числе и код бутлоадера. И он тупо недееспособен все время пока флеха в ауте, на это время чип становится полной тыквой - и это вообще совсем нельзя обойти.

     
     
  • 7.84, Sw00p aka Jerom (?), 13:52, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Попробуй блин под него хотя-бы бутлоадер написать.

    Попробуйте сначала разговаривать с машиной на её "языке", а не посредством переводчиков, я бы посмотрел бы сколько Г еще посыпалось из её архитектуры.

     
  • 5.48, Sw00p aka Jerom (?), 21:01, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >DJB определил уязвимости как ошибки, ведущие к проблемам безопасности

    а определение понятию "безопасность" очевидно он не дал :)

    Как вы думаете, в природе есть понятие "безопасность" ? По мне - нет, есть понятие "инстинкт самосохранение", и природа создала баланс всех животных, "ахиллесову пяту" имеют все.

     
     
  • 6.79, Аноним (-), 11:46, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > а определение понятию "безопасность" очевидно он не дал :)

    Оно следует из определения уязвимости по DJB: это в принципе любое поведение программы, которое не было запланировано программистом. Атакующий потенциально может использовать неожиданное для программиста поведение его программы для получения какого-то незапланированного бонуса, в ущерб чьим-то легитимным интересам.

    > Как вы думаете, в природе есть понятие "безопасность" ?

    Я попробовал доразвить идею.

    > "ахиллесову пяту" имеют все.

    Люди не умеют писать программы без ошибок. Поэтому как максимум одни классы ошибок мутируют в другие. Ну хорошо, вместо кидисов с переполнением буфера приходит пачка ботов с вордпресовского плагина. Безопаснее это не ощущается.

     
     
  • 7.83, Sw00p aka Jerom (?), 13:46, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >Оно следует из определения уязвимости по DJB:

    когда одно определение следует из другого - это порочный круг, вот вы и доказали, что безопасность это порочный круг ("Щит и меч").

    >это в принципе любое поведение программы, которое не было запланировано программистом.

    как такое возможно? не запланировано - это как? Может ли быть у детерминированного алгоритма незапланированное поведение?

    >Люди не умеют писать программы без ошибок.

    Ну так смиритесь с этим, будут и ошибки и заплатки, чем крепче меч - тем крепче и щит, и так по кругу - "порочному".

    >Безопаснее это не ощущается.

    Потому-что это псевдо-ощущение.

     
  • 2.31, Аноним (-), 16:51, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если всё ампутировать производительность, небось раза в три поднимется.

    Да, в всяких там декомпрессорах и парсерах протоколов оборвать к дьяволу проверку валидности входных данных и прочих глупостей. Вот весело будет, когда все это - в интернете!

     

  • 1.13, Alen (??), 14:54, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Правильно, что не приняли этот гимн современного маркетинга.
    А то, давайте забьём на качество кода, а вместо этого будем добавлять +100500 тормозящих проверок, а всем будем продавать это как очередную технологию безопасности следующего поколения :)
     
  • 1.14, Аноним (14), 15:01, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А мне вот что стало интересно. Сколько процентов производительности процессора занимает дыра в безопасности? Другими словами, насколько упадёт эта самая производительность, если закрыть ну совсем все дыры?
     
     
  • 2.16, Аноним (15), 15:11, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    До нуля. Всё, что работает - небезопасно. Ибо может быть сломано. =)
     
  • 2.23, Аноним (-), 15:35, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > насколько упадёт эта самая производительность, если закрыть ну совсем все дыры?

    До нуля. Если компьютер оставить совсем без электричества, его хрен сломаешь, конечно. В остальных случаях - возможны варианты. Людям видите ле свойственно ошибаться.

     
  • 2.39, Lex (??), 17:46, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Пожалуйста уточните, какая конкретно дыра в безопасности ?)
     

  • 1.19, Аноним (19), 15:29, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Здравая идея, похожее уже применяется в GCC для защиты функций от переполнения стека. (-fstack-protector)
     
     
  • 2.34, mos87 (ok), 16:55, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    здравая идея это манагеров интела под суд
    и гос. конторы которые у них это закупают (в США конечно, на госконторы богоспасаемых индий пофиг)
     

  • 1.33, mos87 (ok), 16:54, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    помню как в одной конторе работали с гуй-мордой чекпоинтовского фиревола))) применение любых телодвижений с правилами занимало то ли несколько минут то ли еще больше)))
     
  • 1.44, Аноним (44), 19:03, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    а разве __typeof не GCC специфичная штука? Да не закидают меня помидорами, но разве использование компилятороспецифичных расширений не полный отстой? Это уже получается плохо портируемая разработка не на самом языке, а на его диалекте. Сейчас погуглил - в Clang typeof работает только если врубить режим GNU-совместимости. Для MVSC/Intel C Compiler не нашел, как врубить поддержку вообще. А вот в Tiny C поддержка есть, кек.
     
     
  • 2.49, Аноним (49), 21:30, 23/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Intel C Compiler поддерживает как и большую часть гццшных расширения, MVSC просто не нужен, так не компилятор C, а какое-то недоразумение.
     
  • 2.63, Аноним (61), 02:12, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Особо выбора нет. В С++11 есть портируемый declspec, а в чистом С нету. Но реализации malloc обычно тоже плохо портируемы, не лучше, чем тот __typeof. Так что не вижу лучшего решения. А если нужна будет совметимость с другим компилятором, у которого нет __typeof, а есть что-то другое - использовать то другое через #ifdef, как водится.
     

  • 1.45, Аноним (45), 19:15, 23/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Решение проблемы косвенными методами - зло. Т.ч. всё правильно сделали.
     
  • 1.58, deeaitch (ok), 00:21, 24/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Вот не дочитал коменты до конца, но в очередной раз увидел и задался вопросом.

    Отчего сообщество rust такое токсичное?

    Чем вот например отличается верующий от сектанта? Верующий верит себе и верит, никому ничего не навязывает. А вот сектант как раз ходит и проповедует что есть только его единственная вера способная спасит твою грешную душу.

    К слову, вот есть верующие и атеисты. Сколько в мире религий? Да дохрена. При этом верующий верит в одну из дохрена, а атеист ни в одну. Как-то верующие не далеко ушли.

    Другое дело секта, спасители мира блин.

    При этом нет ни одного софта на rust которым вот прямо захотелось бы попользоваться. Вот даже на посмотреть. Ни одной тулзы ни одного ничего что нужно в повседневной жизни для работы \ дома.

    Сделайте уже что-то дельное на своём rust'е. А то только бла бла бла. Пока нормальные люди пишут нормальный код и что-то ничего ни у кого не падает и не глючит.

     
     
  • 2.62, Аноним (60), 02:00, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я обычно вижу кучу хейтеров раста, а как раз его приверженцы вполне спокойные и ... большой текст свёрнут, показать
     
     
  • 3.65, Аноним (61), 02:17, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > имеет единый компилятор

    Это всего лишь следствие молодости и "неокреплости" языка. У С, С++ и Явы тоже когда-то был ровно один компилятор.

     
     
  • 4.67, Аноним (60), 02:35, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Не думаю, что когда-нибудь будет такая же жесть, как с плюсами
    Да это и не к чему, разве что for fun
    Слишком удобно качать всё через rustup
    У C/C++ никогда такого не было, как и ведущей компании
     
     
  • 5.80, Аноним (82), 11:53, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > У C/C++ никогда такого не было, как и ведущей компании

    Так что визгливые идиотины желающие именно концлагерных порядков от стремной комерсовской корпорашки, по счастью, сольются в те экосистемы. Куда и дорога этим вебмакакам.

     
     
  • 6.87, Аноним (60), 15:53, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Факты говорят сами за себя Я люблю C , но он безнадежно отстаёт И во многом и... большой текст свёрнут, показать
     
  • 2.66, Ordu (ok), 02:18, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот не дочитал коменты до конца, но в очередной раз увидел и задался вопросом.
    > Отчего сообщество rust такое токсичное?

    Сказанное тобою, на мой взгляд, подразумевает, что ты увидел представителей сообщества rust в комментах? Ты можешь указать хотя бы на один коммент, который, на твой взгляд, был оставлен представителем этого самого сообщества rust?

    (не считая этого моего коммента -- про этот коммент я и так знаю, что он оставлен сектантом rust'а)

     

  • 1.70, Аноним (70), 08:29, 24/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это каким боком две доп инструкции при вызове malloc роняют произовдительность на 0.02%? По-моему, это на 200% (была одна инструкция, стало три)
     
     
  • 2.72, Ordu (ok), 11:19, 24/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    malloc это не одна, а десятки или даже сотни инструкций.
     

  • 1.90, Аноним (90), 18:05, 24/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В аду сатана pешил пpоведать, как у него людям "живется".
    Hу, зашел в одну комнату - там мpак, чеpти издеваются
    над людьми, в дpугую заходит - там на костpе всех жаpят,
    кpики вокpуг... Заглядывает в тpетью - а там тишина, на
    столе стоит комп, pядом ящик
    пива, сидит программист, чего-то пpогpаммиpует. Сатана чеpтям:
    - Ребята, у нас же здесь ад! Что это вообще такое?
    - А!.. Дык он на C пишет!:-Е}
     

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



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

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