Comments 87
Раз в год.
Разработчики не могут справится с sudo который в 99.9% случаев просто вызывается из консоли, но при этом имеет возможность интегрироваться в десятки разных систем. Через эти интеграции его и ломают.
Давно уже надо не его ставить по умолчанию, а утилиту, которая может только запускаться из консоли и всё. Благо их уже с десяток написано.
Благо их уже с десяток написано.
В них не находят дыр потому, что они лучше написаны, или потому, что они суть «неуловимые Джо»?
…и эта утилита просто не будет работать там, где интеграции необходимы.
Что за бред? В заметке английским языком написано - проблема в реализации chroot.
Какие ещё "интеграции" вам? Первый вопрос, нужно ли вообще интерпретировать расширения резолвера доменов (AD?), а второй, что просто протупили.
Сейчас в chroot, до этого в Kerberos, до этого ещё в чём то. Суть в том, что sudo настолько большой, что в нём всё время находят, где затупить. Не нужен в системе по умолчанию такой комбаин. Чтобы дать юзеру запускать от рута apt и nano достаточно программы в пару страниц, вылизанной как у кота. А кому нужен этот комбаин - пусть ставят его как любой другой пакет.
«Сидеть в системе под рутом через su небезопасно!», — говорили они. «Гораздо безопаснее использовать sudo !», — говорили они.
потенциально затрагивает все выпуски утилиты, начиная с номера 1.8.33
У меня на убунте 20.04 версия 1.8.31, apt upgrade делал. То есть они уже после добавили дырку. Что скажут апологеты немедленных, всеобщих и безусловных обновлений?
У каждого есть знакомый с заглушкой в ремне безопасности, ибо слышал о случае, когда человек выжил в ДТП благодаря тому, что вылетел через лобовое, будучи непрестегнутым
Вы считаете, что добавление новой уязвимости - настолько же редкий и уникальный случай?
Нет, но при регулярных обновлениях обнаруженные уязвимости оперативно фиксятся. Ни одна из стратегий не идеальна, но оптимум на мой взгляд - регулярное обновление последней стабильной версии дистрибутива. И здоровый консерватизм там проявляют мантейнеры, чей экспертизе в этих вопросах я доверяю больше чем своей.
Если под всеобщими обновлениями вы имеете в виду rolling до bleeding edge, то естественно в проде этому не место.
Ни одна из стратегий не идеальна
Эх, если бы кто-то провел исследование и посчитал вероятности, было бы любопытно взглянуть на результаты.
оптимум на мой взгляд
Это оптимум только в плане затрат усилий, ведь проще всего регулярно вбивать команду обновления, полагая что "там наверху не дураки сидят".
Я сам так делаю, но здоровый консерватизм во мне не очень доволен, особенно в свете таких новостей.
Чтобы поломать свежую систему - нужно иметь на руках уязвимость нулевого дня.
Чтобы поломать старую необновляемую систему - достаточно почитать публичные багтрекеры.
Думаю, очевидно, что из этого легче.
Предположим, хакер сам нашел или как-то заполучил уязвимость нулевого дня. Есть две системы - назовем их "старая", и "новая".
Вероятность наличия уязвимости в новой системе Pn = 1.
Вероятность наличия уязвимости в старой системе Po < 1, так как уязвимость могла быть внесена после последнего времени обновления старой системы.
Таким образом, против новых, ранее неизвестных уязвимостей, старая система будет безопаснее.
Спустя какое-то время, уязвимость станет известна, софт будет пропатчен, новая система обновится, и станет неуязвимой. А вот старая либо так и останется с дыркой, либо нет.
Но вот период между нахождением уязвимости, и выходом патча, может быть весьма продолжительным, если не бесконечным.
Поэтому наиболее безопасной я вижу стратегию обновлять только софт, для которого достоверно известно о наличии в нем критических уязвимостей. Ну или закрывать эти уязвимости другими способами.
Сам так считал до первого майнера. Уязвимость, через которую зашли, была публично известна полгода.
Поддержка 20.04 была прекращена по срокам, если по каким-то причинам нужно сидеть на 20.04 и религия запрещает обновиться штатно через do-release-upgrade, то подключи esm и обновления будут на критичные вещи приходить еще 5 лет
Кто тебе идиот, что ты сидишь на EOL-системе? Кто за тебя должен следить за этим? Марк Шаттлворт? Я с ним пиво пил, он классный чувак, но за тебя обновлять твои компы он не обязан
sudo: you are not permitted to use the -R option with woot
sudo 1.9.5p2
-R directory, --chroot=directory
Change to the specified root directory (see chroot(8)) before
running the command. The security policy may return an error if
the user does not have permission to specify the root directory.
Ну что - какое mitigation поставить - мы уже знаем. (искать runchroot в man sudoers)
Разрешать юзеру запускать левые бинарники или компилятор – вообще так себе практика с точки зрения защиты информации.
аминь брат
в конторах где безопасность рассматривают не только на бумажке юзвери не знают пароль от sudo и даже /home обычно монтируется с noexec
но всего не учтёшь, например недавно я открыл таким ребятам глаза на то что существует /run/user/$UID о существовании которого они конечно же забыли, и там и exec возможен и selinux не против.. короче добавил им работы.
Бинарник не обязательно компилировать, его можно просто скачать, так что запрет компилятора никак не защитит от этой атаки. Запрет запуска левых бинарников не защитит тоже, потому что бинарник тут - библиотека, его не запускают, а загружают.
В режиме замкнутой программной среды необходимо подписывать в том числе и библиотеки.
so – технически такой же файл ELF, как и загрузочный модуль.
Вы, конечно же, можете рассказать как это делается?
Да, блин. Астра. Её кто только не ломал уже. А самое главное - пользуйтесь только сертифицированными репозиториями. Правда они не содержат критических исправлений за последний год, но вы пользуйтесь.
Защищённые дистрибутивы существуют именно по той причине, что обычные дистрибутивы уязвимы. Тут уж одно из двух.
Её кто только не ломал уже.
Кто?
Астру. Проблема всех российский "защищённых" дистрибутивов в том, что они требуют сертификации, которая обновляется раз в год. И пофиг, что за это время там накапливается пара десятков критических уязвимостей.
Любая уязвимость актуальна только в определённых условиях, необходимых для своей применимости. При соблюдении требований, предъявляемых для обеспечения штатных режимов безопасности Astra Linux, обычные критические уязвимости Linux не имеют возможности быть использованными. Как, например, в данном случае критическая уязвимость, заключающаяся в подгрузке созданной пользователем зловредной библиотеки, не может эксплуатироваться в режиме замкнутой программной среды, так как такая библиотека не будет подписана администратором безопасности.
А если иметь компилятор и право подписи исполняемых модулей (или не включать ЗПС), то Astra Linux сломать так же легко, как и любой другой дистрибутив.
Когда была такая необходимость, то ломал Астру через какое-то древнее переполнение буфера.
А в данном случае можно найти в системе уже имеющуюся библиотеку, которая при инициализации делает что-то "эдакое", скопировать её и использовать. Много системных библиотек при старте управляются переменными среды или используют текущую директорию. Я уверен, что при должном старании это не будет большой проблемой. Разве что, совершенно и полностью запретить скриптовый шелл. Но, во-первых, ничего хорошего и сложного на такой систем не построишь. А, во-вторых, просто нужно будет добавить ещё один этап к взлому через какое-нибудь переполнение буфера или что-то подобное.
В общем, все эти тотальные подписи - так себе идея и работают плохо. Тот же LinuxSE (его астровский клон) и то более реально использовать, чем эти тотальные подписи и режим ЗПС.
Когда была такая необходимость, то ломал Астру через какое-то древнее переполнение буфера.
Чтобы это сделать, вам для начала нужно убедить подписать свою программу. Если не подключать защиту в полном объёме, то, конечно, сломать возможно.
В общем, все эти тотальные подписи - так себе идея и работают плохо. Тот же LinuxSE (его астровский клон) и то более реально использовать, чем эти тотальные подписи и режим ЗПС
Имею опыт использования и не вижу особых проблем. Для легального разработчика несложно подписывать свои программы. А тащить со стороны в защищённую систему всякую бяку – конечно, не удастся, да и не нужно.
Точно по такому же принципу работает айфон, и все довольны.
ЗПС на системе, ясен перец включён не был, так как сложный софт под ним запускать слишком больно (или даже невозможно) и подходит он для очень узкого круга задач. А многие задачи требуют использования bash или какого-нибудь питона.
И, кстати, самый большой зад был в том, что "для легального разработчика несложно подписывать свои программ" - всё верно. Но когда этому "легальному разработчику" ставят условие, чтобы эти программы так же собирались (и даже разрабатывались!!!) в безопасном контуре, то оказывается, что настроить "безопасную" (по данным требованиям) систему под сборку сложно проекта с двумя гигабайтами кода практически невозможно.
Точнее нужна выделенная система, которую админ неделю с кровавыми слезами на глазах будет конфигурировать, и которая должна будет выполнить одну единственную задачу сборки проекта. Больше ничего это система делать не сможет. И не факт даже, что её удастся отконфигурировать нужным образом, так как где-то кто-то что-то обновил, и сиди заново разбирайся, как это всё заставить собираться.
Ну, или использовать тот говно-софт, что комплекте с системой идёт, примитивные кривые тулчейны и клепать то говно, которое 99% российских разработчиков сертифицированного софта клепает.
Короче, после опыта работы с этим, настроен я крайне скептически. Более того в результате идиотских требований, идиотский указаний по контролю и идиотских путей исполнения этих требований абсолютно во всех защищённых системах, что я видел, совершенно всегда был какой-то тайный-секретный активно-используемый способ доступа к данным в обход всей защиты, что сводило всю безопасность к показухе.
Ну жизнь вообще боль, а безопасность в особенности.
совершенно всегда был какой-то тайный-секретный активно-используемый способ доступа к данным в обход всей защиты, что сводило всю безопасность к показухе.
Тут надо разобраться для начала с моделью нарушителя. От эксплуатирующего персонала, в особенности выполняющего сложные операции, защититься действительно очень сложно. И от каких-нибудь супер-пупер спецслужб, наверное, тоже. Но от мамкиного хакера Пети, запускающего стандартный скрипт, эксплуатирующий CVE, вполне реально.
Само-собой. Но проблема в том, что текущая модель безопасности настолько кривая, что она не исполнима и потому совершенно всегда требуется/имеется возможность несанкционированого доступа. Вот вы хоть одну реальную систему, которую бы эксплуатировали сугубо в рамках требований к безопасности, видели? Я нет. Совершенно всегда были какие-то мутные флэшки, бэкдоры, тайные компиляторы/интерпретаторы и прочее пути переноса дынных в обход официальной модели безопасности.
Ну, а разработка в безопасном контуре просто невозможна по очевидным причинам и вся безопасность при разработке совершенно всегда показушная. В реальности программисты используют обычные ОС и обычные среды. Но для галочки всегда говорится, что это всё было разработано под сертифицированными системами в безопасном окружении
Разработка естественно проводится за пределами безопасного контура. Хотя бы по той причине, что средства разработки сами не сертифицированы по требованиям безопасности (и в том же Astra Linux находятся на отдельном диске, не входящем в "безопасный" комплект).
На этот предмет существует статический и динамический аудит результата разработки.
Так если она сертифицирована, значит полностью безопасна
Вы издеваетесь или как? Причём тут вообще пакеты, когда речь шла о бинарниках? Это во-первых.
А во-вторых, по приведённой вами ссылке нет ни единого слова про настройку проверки подписей библиотек. Вот чтобы вызов dlopen на неподписанную библиотеку не сработал. Иначе все эти подписи никак не защитят вас от описанной в статье атаки.
Вы правда всё время тупите или специально юродствуете?
https://wiki.astralinux.ru/pages/viewpage.action?pageId=61574460
https://wiki.astralinux.ru/pages/viewpage.action?pageId=41190634
А вы правда считаете, что все вокруг работали с Астрой и знают внутреннюю терминологию?
Что же до режима замкнутой программной среды - судя по документации, он предельно ограничен. Все эти запреты интерпретаторов и прочее, фактически, нарушают стандарт POSIX - а потому есть шанс, что требуемое для работы приложение просто не запустится. Да блин, банальное приложение на Электроне или вовсе браузер уже ставят вопрос "либо режим ЗПС, либо я". Так что подобный режим никак не подходит для использования просто по умолчанию.
Я считаю, что когда вам что-то сообщают, то надо бы задуматься об этом, а не считать себя самым умным на свете и обладателем окончательного знания во всех областях.
Естественно, режим ЗПС в том виде, как он реализован в Astra Linux (т.е. с учётом всех установленных законом требований по защите конфиденциальной информации), не подходит для использования по умолчанию. Но допускать на свой компьютер злонамеренных пользователей – это вообще нифига не режим по умолчанию.
Тем не менее, браузер в режиме ЗПС в Astra Linux работает. Но, разумеется, он не будет при этом позволять запускать плагины со стороны.
Хотя, например, в macOS (а особенно в iOS) по умолчанию используется более мягкий режим ЗПС. И тоже непривилегированный пользователь лишнего не запустит.
Я считаю, что когда вам что-то сообщают, то надо бы задуматься об этом, а не считать себя самым умным на свете и обладателем окончательного знания во всех областях.
А я считаю, что когда у вас просят подробностей - надо эти самые подробности давать, а не вставать в позицию "догадайтесь что именно я имел в виду".
Но допускать на свой компьютер злонамеренных пользователей – это вообще нифига не режим по умолчанию.
Это стандартная ситуация в корпоративных сетях вообще-то. Любой сотрудник по умолчанию считается злонамеренным, но ему всё ещё требуется работать и выполнять должностные обязанности.
Тем не менее, браузер в режиме ЗПС в Astra Linux работает.
Значит, режим недоделан. В документации вполне прозрачно написано про запрет любых интерпретаторов, а в браузере есть интерпретатор JavaScript.
Это стандартная ситуация в корпоративных сетях вообще-то. Любой сотрудник по умолчанию считается злонамеренным, но ему всё ещё требуется работать и выполнять должностные обязанности.
Не дай бог попасть в такую корпоративную структуру. На полиграфе проверить сотрудников для установления доверия не дешевле обойдётся?
Как правило, в корпоративной сети есть общие ресурсы на серверах, в которых рядовому сотруднику не то что без ЗПС, а и вообще в шелле по определению делать нечего. И есть персональные рабочие станции, где ограничение привилегий по существу условно, и носит во многом демонстрационный характер. Ничего страшного не произойдёт, если Вася Пупкин получит права локального админа на своём рабочем месте.
В документации вполне прозрачно написано про запрет любых интерпретаторов,
Запрет любых интерпретаторов не является обязательным. Это вопрос баланса простоты настроек между запуском интерпретатора в целом, разрешения тех или иных скриптов или разрешения отдельных операций.
И есть персональные рабочие станции, где ограничение привилегий по существу условно, и носит во многом демонстрационный характер. Ничего страшного не произойдёт, если Вася Пупкин получит права локального админа на своём рабочем месте.
Получив права админа, он сможет поставить левый софт, через который утекут данные. Возможно, это случится даже намеренно.
А ещё права админа позволяют организовать некоторые relay-атаки на доменных админов (или как они там в линуксе называются). Или просто поставить кейлоггер, сломать систему и дождаться пока админ придёт её чинить.
Вообще, как-то даже символично, что человек рассказывавший про пользу ЗПС не видит ничего страшного в правах админа у рядового пользователя...
Запрет любых интерпретаторов не является обязательным.
А в документации ничего про необязательность не говорилось. Кому верить?
Вообще, как-то даже символично, что человек рассказывавший про пользу ЗПС не видит ничего страшного в правах админа у рядового пользователя...
Конечно символично. Именно потому, что я чуть-чуть вникал в тему безопасности, я и понимаю, что права локального админа у рядового пользователя ничего принципиально не ухудшают по сравнению с принесённым на работу ноутбуком или смартфоном.
Чтобы эффективно ограничить доступ к локальной сети от злоумышленников среди персонала, вам надо будет установить на предприятии такой жёсткий режим, что там вопрос об использовании или неиспользовании ЗПС просто не будет на этом фоне стоять.
А в документации ничего про необязательность не говорилось. Кому верить?
В каком месте документации вы нашли обязательность запрета интерпретаторов?
Именно потому, что я чуть-чуть вникал в тему безопасности, я и понимаю, что права локального админа у рядового пользователя ничего принципиально не ухудшают по сравнению с принесённым на работу ноутбуком или смартфоном.
Иногда и это строго запрещено. Или же такие устройства попадают в гостевую сеть.
Чтобы эффективно ограничить доступ к локальной сети от злоумышленников среди персонала, вам надо будет установить на предприятии такой жёсткий режим [...]
Да нет, достаточно настроить IEEE 802.1X. Не вижу причин по которым это могло бы считаться особо жёстким режимом.
Иногда и это строго запрещено.
Взламывать сеть вообще запрещено. Но вы же пользователя считаете злоумышленником.
Да нет, достаточно настроить IEEE 802.1X.
Про взлом 802.1X только ленивый не писал. Не бывает так, чтобы безопасность автоматом без труда.
Угу. И доступ к файловой системе. И можно заставить браузер выполнять произвольный локальный скриптовый файл. И никак это не подпишешь, так как даже если попытаться, то всё обходится инъекцией в кэш браузера.
Чтобы делать инъекции в кеш браузера, нужно иметь на это права. Не забывайте, что в Astra Linux используется контроль целостности. Обычный пользователь работает с низким уровнем целостности (на синем экране), и в работу сетевых служб не может вмешаться.
Кэш на диске у пользователя хранится и непрерывно динамически меняется. Это я к тому, что нет проблемы заставить браузер исполнять произвольный код и использовать, его как некий интерпретатор общего назначения, если другие интерпретаторы запрещены. Как поднять привилегии браузера, это уже другой вопрос. Но наличие доступного пользователю браузера равно наличию мощного интерпретатора, из-за чего пропадет смысл в блокировании всяких башей и питонов.
Но наличие доступного пользователю браузера равно наличию мощного интерпретатора, из-за чего пропадет смысл в блокировании всяких башей и питонов.
Не равно, так как штатный браузер (как и другие штатные сетевые сервисы) сам допилен на предмет безопасности. Контроль целостности не позволяет запускающему браузер пользователю (и выполняемому скрипту) получить все те права, которыми обладает собственный код браузера.
Если бы браузер Astra Linux ничего не знал о мандатном доступе, либо вообще если бы опирался только на дискреционную модель доступа user/group, тогда вы были бы правы.
Проблема замкнутой программой среды в том, что она настолько замкнутая, что в ней нет ничего :) Реальная эксплуатация приводит к необходимости установки дополнительного ПО
Эмммм. Но ведь shared library, лежащую где-то под точкой монтирования с явным noexec нельзя динамически слинковать в запускаемый бинарник. Даже косвенно. Даже если на сам бинарник noexec флаг не распространяется. Иначе во флаге noexec просто нет никакого смысла. Вы просто подставляете свою очень хитрую хакерскую реализацию условного getpid в вызываемый совершенно легальный бинарник, вызывающий сию функцию, при помощи нехитрогоLD_PRELOAD=/путь/до/pwned.so. И всё, вы на коне.
Не, я, конечно, ещё не проверял конкретно в случае модулей nss, может быть там очень своя атмосфера (хотя, ЕМНИП, там обычная динамическая линковка). Но глобально shared library вы из-под mountpoint с noexec в лоб не загрузите. Только если через жонглирование mmap() и mprotect(). Но для этого вам нужно чтобы на системе уже был странный бинарь, который грузит в память через mmap любой файл по произвольно указанному пути, а потом через mprotect вешает на эту память PROT_EXEC и прыгает туда с целью исполнения этого произвольного чего-то. Несложно догадаться насколько велик шанс на наличие такого очевидного технологического отверстия на обычной системе.
UPD. Хотя можно попробовать обойти noexec ещё через memfd и ковыряние в /proc/self/mem, но это скорее актуально если вы прям целиком исполняемый код так в память запихиваете и отстреливаете. Я слабо представляю как это может помочь произвольную библиотеку стороннему процессу незаметно подложить.
Хм, не знал про такую особенность noexec флага, думал он просто не даёт ставить eXecutable бит (а этот бит у библиотек игнорируется совершенно точно). Ну, бууд знать.
Однако, тут именно что обычной динамической линковки и не происходит - это попросту невозможно для библиотеки, имя которой лежит в конфиге. Вместо этого любая программа обращающаяся к NSS открывает библиотеку через dlopen, А этот dlopen именно что загружает библиотеку средствами mmap и mprotect. судя по тому что я увидел в коде glibc. Правда, там в коде чёрт ногу сломит и до конца я его не досмотрел.
Проверяет ли dlopen флаг noxec?
Ну я не просто так приседал насчет mmap и mprotect) Мой комментарий по поводу того, что noexec не даст загрузить библиотеку относился к:
Запрет запуска левых бинарников не защитит тоже, потому что бинарник тут - библиотека, его не запускают, а загружают
А вот это замечание:
это попросту невозможно для библиотеки, имя которой лежит в конфиге. Вместо этого любая программа
абсолютно справедливо и логично. Правда тогда получается, что эта уязвимость - не камень в огород sudo, а камень в огород glibc. Но разбираться некогда, нужно обвинять sudo!
Что-то не соображу, а в какой момент на сцене появилась точка монтирования с noexec?
В тот момент, когда @vadimr предложил запретить запуск левых бинарников не упоминая Астру. Потому что на обычном линуксе этот самый запрет реализуется через отдельный раздел для домашней директории с noxec.
И в то же время очень много софта сейчас размещают свои бинарные файлы в директории пользователя, что логично и правильно. Если у вас различные окружения для разных пользователей, то может быть правильный путь.
В большинстве случае noexec на домашней директории кончается болью сейчас. Ну, кроме случаев, когда пользователь создан пол узкоспецилизированную задачу.
И фокус с LD_PORELOAD отлично работает в большинстве случаев, поэтому нужно контролировать переменные окружения для критически-важного софта. И подгрузка библиотек, кстати, запрещена Для файлов с setuig/setgid и потому не работает для sudo.
Но вообще говоря, это катастрофа, так как на всех Ubuntu сейчас sudo версии как раз "с 1.9.14 по 1.9.17". Можно смело ломать любую систему, к которой есть локальный доступ.
Для этого в ALSE, есть мкц, и даже если взламывают судо, то у пользователя остается низкая целостность, и его действия ничего не дают.
Даже файлик hosts не поправит, а уж тем более про установку пакетов, перезапуск служб и т.д.
Так, что вот и плюсы отечественного ПО
Это просто означает, что sudo у вас не работает. Потому что sudo как раз затем и нужен, чтобы админ мог править hosts и ставить пакеты.
именно что "админ", в астре админ от пользователя отличается разрешенной "целостностью", 63 против 0, и админ входит в систему выставив себе 63, после чего суд даёт ему рута с достаточной целостностью, чтобы и пакеты ставить и всё остальное системное править. Если пользователь вошел в систему и ломанул судо, целостность у него останется 0 и ядро (точнее парсек) не даст ему изменять файлы с более высокой настроенной целостностью.
Тут фокус в том, что уязвимость находится "внутри" sudo (код nsswitch исполняется от имени sudo) и большой вопрос, что там с атрибутами безопасности будет, "так как обработка NSS производится до сброса привилегий". Не говоря уже о том, что sudo может использоваться и для временной смены ролей пользователя, и в этом случае можно с новой ролью исполнять произвольный код.
Надо испытать
А почему до сих пор используют? Уже лет 10 есть doas. Одна из причин создания была как раз критика кода sudo.
Ubuntu 25.10 переходит на https://github.com/trifectatechfoundation/sudo-rs
Видимо не зря.
Попробовал этот эксплоит на версии sudo 1.9.9 - не работает.
Выдает такую ошибку:
sudo: you are not permitted to use the -R option with woot
Выявлена критическая уязвимость в утилите sudo, позволяющая получить права root в системе