[Перевод] Безопасность памяти для скептиков

Если вам надоело слушать проповеди про «безопасность памяти» - эта большое эссе именно для вас, усталых скептиков. Эндрю Лилли Бринкер - ведущий инженер компании MITRE в области безопасности программного обеспечения - спокойно разбирает факты и доказывает: безопасность памяти - не прихоть и не религия Rust-евангелистов, а экономически оправданный шаг в сторону надёжного, дешёвого и безопасного софта. Rust, Java, Go и им подобные языки не делают программистов «лучше» - они просто предоставили ремни безопасности в сам процесс разработки. И, как в случае с автомобилями, это спасает тысячи «жизней» приложений.

https://habr.com/ru/articles/965432/

#memory_safety #programming_languages

The Opus! So cool!
#vlc #onionsite #TorMedia

→ Development Idea
imagine #Oniux ‘bash’ for #systemd (all applications through tor on boot)

!! #Mobile #Tor in #Rust gateway for all #apps !!

* namespace #sandbox
* #Memory_Safety
could be implemented in #Termux and eventually at the #OS level

#MALbookclub

[Перевод] Как Мэтт Годболт «продал» мне Rust (рассказав о C++)

Мэтт Годболт, знаменитый разработчик Compiler Explorer — потрясающий человек, вам стоит найти в вебе и изучить весь созданный им контент. Именно этим и занимался, просматривая Correct by Construction: APIs That Are Easy to Use and Hard to Misuse . Я уже больше двадцати лет работаю с C/C++, поэтому эта тема была мне близка. Когда я смотрел его доклад, ко мне постоянно приходила мысль: «Да! И именно поэтому в Rust это делается так». После просмотра видео я подумал, что этот доклад — отличный способ понять, как Rust помогает разработчикам не только в безопасности по памяти, и в своей статье я расскажу об этом. Но прежде нам следует поговорить о поднятых Мэттом проблемах и о том, как он предлагает решать их в C++. Сделайте себе одолжение и посмотрите доклад целиком, а я разберу один из его пунктов.

https://habr.com/ru/articles/908032/

#безопасность_доступа_к_памяти #memory_safety #type_safety #типобезопасность

CISA and FBI Alert: Mitigating Buffer Overflow Vulnerabilities in Software - https://www.redpacketsecurity.com/cisa-and-fbi-warn-against-buffer-overflow-vulnerabilities/

#threatintel #buffer_overflow #cybersecurity #memory_safety

CHERI Security Hardware Program: A Vital Initiative for UK's Cyber Safety - https://www.redpacketsecurity.com/cheri-security-hardware-program-essential-to-uk-security-says-government/

#threatintel #CHERI #memory_safety #cybersecurity

Безопасная работа с итераторами в С++

После публикации предыдущей статьи на данную тему, некоторые читатели не обратили внимания, что данный проект, это не действующий инструмент, готовый для боевого применения в реальных проектах, а только доказательство работоспособости концепции использования плагинов компилятора для дополнительного семантического контроля исходного кода С++ во время компиляции. А в качестве примера реализации подобного плагина я взял концепцию безопасной работы с памятью из языка NewLang с минимальной адаптацией под C++ . То есть основная идея предыдущей статьи — продемонстрировать возможность использования плагина компилятора для дополнительного анализатора исходного текста, а не изучение функциональности реализованной библиотеки для работы с памятью (которая и не может быть в полном объеме портирована на С++ из-за архитектурных различий в этих языках программирования). Тем не мене, большинство читателей все же уловило основную мысль и проявило интерес к возможному дальнейшему развитию подобного подхода к повышению безопасной разработки на С++ без нарушения обратной совместимости со старым кодом. Поэтому, чтобы не смущать читателей отсылкой к неизвестному для них новому языку, я начал адаптировать концепцию безопасной работы с памятью под чистый С++ для решения специфических для С++ проблем. А пока идет доработка плагина и мне очень захотелось поделиться одним очень увлекательным квестом, которой показывает непреодолимые архитертурыне проблемы С++ на пути к безопасному программирования. И поводом для того стали итераторы.

https://habr.com/ru/articles/878156/

#clang #clangtidy #plugin #memory_management #memory_safety #iterator

[Перевод] Как мы нашли уязвимость в SQLite при помощи LLM

Введение В нашем предыдущем посте Project Naptime: Evaluating Offensive Security Capabilities of Large Language Models мы рассказали о фреймворке для исследований уязвимостей при помощи языковых моделей и продемонстрировали его потенциал, усовершенствовав показатели современных бенчмарков CyberSecEval2 компании Meta. С тех пор Naptime эволюционировал в Big Sleep — совместный проект Google Project Zero и Google DeepMind. Сегодня мы с радостью готовы поделиться первой уязвимостью из реального мира. обнаруженной агентом Big Sleep : отрицательным переполнением (underflow) буфера стека с возможностью реализации эксплойтов в SQLite , — широко используемом опенсорсном движке баз данных. Мы обнаружили уязвимость и сообщили о ней разработчикам в начале октября, и они устранили её в тот же день. К счастью, мы обнаружили эту проблему до её появления в официальном релизе, так что она не затронула пользователей SQLite . Мы считаем, что это первый публичный пример обнаружения ИИ-агентом ранее неизвестной уязвимости безопасности по памяти в широко используемом реальном ПО. В этом же году на мероприятии DARPA AIxCC команда Team Atlanta обнаружила разыменование нулевого указателя в SQLite, что вдохновило нас использовать его в нашем тестировании, чтобы проверить, сможем ли мы найти более серьёзную уязвимость. Мы считаем, что наша работа обладает огромным защитным потенциалом. Нахождение уязвимостей в ПО ещё до его релиза не позволит нападающим пользоваться ими: уязвимости устраняются ещё до того, как их увидят злоумышленники. Очень сильно помог в поиске уязвимостей фаззинг, но нам нужна методика, позволяющая защищающимся находить баги, которые сложно (или невозможно) обнаруживать фаззингом, и мы надеемся, что ИИ позволит закрыть этот пробел. Мы считаем, что это многообещающий путь к полному изменению ситуации в кибербезопасности и обеспечению асимметричного преимущества для защищающихся. Сама уязвимость довольно любопытна, к тому же существующая инфраструктура тестирования SQLite (и через OSS-Fuzz, и через собственную инфраструктуру проекта) не обнаружила проблему, так что мы провели дополнительное исследование.

https://habr.com/ru/articles/855882/

#уязвимости #sqlite #memory_safety #безопасность_памяти #эксплойты

[Перевод] Как устранить первопричину уязвимостей безопасности памяти

Уязвимости безопасности памяти остаются серьёзной угрозой для защиты ПО. Мы, работники Google, считаем, что путь к крупномасштабному устранению этого класса уязвимостей и к защищённому ПО заключается в Safe Coding — подходе secure-by-design, отдающем приоритет переходу на безопасные по памяти языки. В этом посте мы покажем, почему стремление к Safe Coding при создании нового кода быстро (хотя и контринтуитивно) снижает риски безопасности кодовой базы в целом, позволяя наконец-то прорваться через неподдающееся плато уязвимостей безопасности памяти и начать экспоненциальное снижение их количества с сохранением масштабируемости и экономности. Также мы приведём обновлённую статистику того, как благодаря переходу на безопасные по памяти языки, процент уязвимостей безопасности памяти в Android упал за шесть лет с 76% до 24%.

https://habr.com/ru/companies/ruvds/articles/847056/

#безопасность_памяти #memory_safety #rust #c++ #kotlin #устранение_уязвимостей #ruvds_перевод

Торги на Мосбирже приостановлены на час из-за ошибки при работе с памятью

14 августа с 16:18 по 17:30 Московская биржа приостановила торги на фондовом рынке. По информации с официального сайта инцидент произошел из-за программной ошибки на сервере доступа.

https://habr.com/ru/articles/836116/

#безопасная_разработка #rust #c++ #undefined_behavior #memory_safety