Комментарии 24
методы обратной разработки
Методы реверс инженеринга. Тут, имхо, англицизм уместнее.
"кто угодно может прочитать код ядра линукс и исправить" (с) каждый первый борец против кровавой проприетарщины, рассказывающий о том, почему опенсорс безопаснее
Вы, наверно, забыли таблетки принять
Я и без таблеток прекрасно помню рассказы про маздай, про виндекапец, про закрытую проприетарщину с неправильной "безопасностью по неясности" и опенсорс в котором кто угодно может залезть в код ядра линукс и найти там проблемы.
А уж если я таблетки приму, то я ещё больше вспомню. Надо?
Ну, коли вам так хочется поистерить, пожалуйста. Ток после таблеток скорее всего стыдно станет что взрослый человек, а таким страдает на ХАБРЕ. Хотя, это я надеюсь что взросляй человек
Сейчас все ломанулись искать уязвимости в ядре линукса просто потому, что там предварительно реверсить ничего не нужно. Но это временно, сейчас с помощью REA доберутся до ядра MS, и начнут смотреть, что интересного есть там. И, поверьте, находить начнут не меньше
Ну сейчас все популярное и открытое будут регулярно ломать. ИИ дали для это широкие возможности. Теперь похоже на сервере чем меньше софта, тем лучше.
В нормальных компаниях так было всегда. Политики безопасности четко разграничали сервера, права по ролям(использовали политику минимальных прав, когда выдаются только минимальные права для решения той или иной задачи), векторам атаки, чтобы снизить blast radius. Например в нормальном банке, администратор баз данных никогда не сможет получить доступ к зашифрованным данным клиента, но при этом сможет делать запросы по типу EXPLAIN ANALYZE.
Не, я не про права. Например, тот же деплой через докер я убрал из пайплайна. Чисто nginx, postgre и приложение.
Архитектура безопасности все равно так себе, крутить вебсервер и базу данных на одном сервере плохая практика, при компроментации веб сервера, злоумышленник получит данные к базе данных. По хорошему они должны быть изолированы, например по отдельным виртуальным машинам и общаться через виртуальную сeть. Но минус такого решения, что базы данных сильно деградируют в производительности на виртуалках и в контейнерах. Частично эту проблему решает selinux, но многие не грамотные предпочитают его отключать т.к. не могут его правильно настроить и перебороть психологический барьер, когда selinux им кажется слишком избыточным и сложным, но на практике selinux довольно прост.
Например крутить вебсервер с кодом сайта в podman в отдельном контейнере и подключаться к базе данных на основной системе, намного безопаснее. Если злоумышленник прочтет пароли к базе данных, он не сможет к ней подключиться т.к. не сможет записать свои файлы в контейнер, который смонтирован read only.
А можно тут поподробнее? В корне приложения все равно лежит env со всеми ключами. Какая разница, где бд. С этого же взломанного сервера есть доступ к бд, где бы она не находилась. Или я что-то не понимаю.
Контейнеры монтируются read only. Злоумышленник не сможет изменить контейнер, записать свои файлы, например shell скрипт, с помощью которого подключится к бд и слить всю базу. Напрямую к базе он не сможет подключиться, ему не доступна виртуальная сеть. Допустим на сайт загружаются картинки, но даже они хранятся вне кодовой базы сайта, а лежат на примонтированом томе в контейнере на котором запрещено выполнение любых файлов. Даже при SQL инъекции радиус поражения чаще всего ограничен одной таблицей, а не всей базой. Таким образом контейнеризация кода сайта, помогает снизить вероятность угроз. В купе с seccomp и selinux практически сведет на нет. Допустим в контейнере установлена забагованная версия PHP, но и тут он защитит, не даст выйти из контейнера. Можно быстро пересобрать образ контейнера с обновленной версией PHP и перезапустить контейнер. Таким образом если у вас система царя гороха вы всегда можете получить обновления безопасности и не ждать, пока их исправит ваш производитель линукса.
одно из лучших решений которые я видел рабочее - external secret operator+hashcorp vault+mutation webhook и лёгкие доработки по отображению энвов в контейнере. Даже если очень удачливый хакер и смог ворваться в под, пройдя в кластер без интернета, каким-то чудом - всё равно ничего увидеть не сможешь
Почему только открытое, совсем недавно сломали vmmanager
Он насколько закрытый, что похоже даже сисадмины, которые им пользуются не знают в чем эта уязвимость заключается и удаляют все панель полностью
Отмечается, что злоумышленники уже используют методы обратной разработки и перебора вариантов (brute‑force), ускоренные с помощью искусственного интеллекта
Интересно какой бруте-форс использовали в ядре линукс, и как его можно ускорить с помощью ИИ? ИИ находит математический изъян в коде и ускоряет перебор? Какие методы обратной разработки использовались и нужны ли они, если есть исходный код проекта? Может речь все же про автоматизированный fuzzing, sast, dast, ии анализ кода, под руковоством ИИ?
Ядро Linux поднялось со второго на первое место по числу присвоенных CVE‑идентификаторов
А что тогда было на первом и сейчас на втором?
Совсем не по ошибке. Одна из новых полиси - если что-то было найдено с помощью ИИ, надо идти в публичную рассылку, т.к. если твой ИИ-агент может такое найти, значит злоумышленники скорей всего уже нашли эту проблему с помощью тех же ИИ-агентов и уже используют, и лучше сразу объявить о проблеме, чем скрывать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Несколько уязвимостей в ядре Linux по ошибке опубликовали в открытом списке рассылки разработчиков