https://opennet.dev/openforum/vsluhforumID3/119792.html В поставляемом в OpenBSD гипервизоре VMM выявлена уязвимость, позволяющая через манипуляции на стороне гостевой системы добиться перезаписи содержимого областей памяти ядра host-окружения. Проблема вызвана тем, что часть физических адресов гостевой системы (GPA, Guest Physical Address) отражены в виртуальное адресное пространство ядра (KVA). Из-за отсутствия необходимых проверок в функции еvmm_update_pvclock() можно добиться передачи KVA-адресов хост-системы в вызов pmap и переписать содержимое памяти ядра...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=52378<br> https://opennet.dev/openforum/vsluhforumID3/119792.html#148 Sat, 07 Mar 2020 11:28:30 GMT &gt; Всё зависит от того, как именно всё реализовано. Мы этих моментов не уточнили - я не понимаю, как тебе ответить: мы можем придумывать примеры и контрпримеры почти бесконечно.<br><br>Например, переключатель может быть вообще исполнен в железе.<br><br>&gt; Я не знаю, что именно там используется, но представить там PaX я вполне могу.<br>&gt; &gt; Еще разок, если есть ошибка переполнения буфера то PaX с grsecurity может не только убивать один процесс. Может убить все процессы пользователя и запретить ему вход в систему. Может вообще само ядро убить! Мы не знаем какую область памяти перезапишим за пределами буфера.<br>&gt; Што?<br><br>Есть общая теория проактивной защиты. Область применения: гарантии безопасности некретических для жизни человека, экологии, ... ИТ систем. Доступность сервисов в этой теории неважна, важны гарантии безопасности и недопущения вреда самой ИТ системе. Грубо говоря в этой теории выделяют 3 класса активной реакции системы на взлом:<br>1. Убить один процесс который нарушил определенные правила.<br>2. Убить все процессы н https://opennet.dev/openforum/vsluhforumID3/119792.html#147 Sat, 07 Mar 2020 09:40:09 GMT Нет времени спорить и что то доказывать. Это сложные вещи.<br><br>Кратко:<br><br>Сетевой экран, как в DAC таки и MAC включал.<br><br>&gt; К сведению: capabilities - есть типичный DAC. Ибо это дискреционное разграничение доступа на основе атрибутов. Не считать capabilites механизмом DAC - это точно такое же гениальное решение, как и предыдущее.<br><br>Да я лично capabilites механизмом DAC не считаю!<br><br>Повторю еще раз сказание мною выше:<br><br>DAC - да дискретный, как много чего другого. Но DAC дискретный по пользователям, а capabilites дискретный по привилегиям суперпользователя. Это разные вещи по точке их применения!!! DAC применяется последовательно, после Integrity и перед MAC. А capabilites применяются паралельно DAC и MAC, можно считать почти незавтсимо от них.<br><br>Grsecurity контролирует capabilites в RSBAC и/или в независимой от DAC и MAC реализации изоляции процессов.<br><br>Перед постройкой мат модели должно быть понимание в какой последовательности по отношению друг к другу применяются разные модели безопасности. Capabilites https://opennet.dev/openforum/vsluhforumID3/119792.html#146 Fri, 06 Mar 2020 08:12:18 GMT &gt;&gt; Там вполне достаточно чтобы сложить 2+2.<br><br>Да я и не сомневался, что сразу все ясно. <br><br>&gt;&gt; Дополнения для безопасности.<br><br>Решение, безусловно, новаторское. Сначала надо вырвать с мясом из ядра те вещи, которые и так уже работают, поломав по дороге совместимость пользовательского окружения. А потом надо затолкать в ядро непонятно что. И обозвать это непонятное - "расширенными возможностями" и "дополнениями безопасности". Подход тоже ясен, да. <br><br>&gt;&gt; Писал уже, capabilities учитываются как независимые от DAC и MAC. <br><br>Это тоже прорыв. К сведению: capabilities - есть типичный DAC. Ибо это дискреционное разграничение доступа на основе атрибутов. Не считать capabilites механизмом DAC - это точно такое же гениальное решение, как и предыдущее. <br>Кроме того, сам термин "учитываются" - вот он что означает? Как именно множество то капабилитей планировалось формализовать в модели и увязывать с другими механизмами DAC? Ау? Или не планировали все-же? Хотели как то "учесть"? А что такое - "учесть"?<br>Посчитать, сколько https://opennet.dev/openforum/vsluhforumID3/119792.html#145 Thu, 05 Mar 2020 14:06:23 GMT &gt;&gt; Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например.<br>&gt; А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется?<br><br>Всё зависит от того, как именно всё реализовано. Мы этих моментов не уточнили - я не понимаю, как тебе ответить: мы можем придумывать примеры и контрпримеры почти бесконечно.<br>Например, переключатель может быть вообще исполнен в железе.<br><br>&gt; В системах для которых кретически важна безперебойная работа используют другие, более дорогие, техники безопасности. А PAX включают только в режиме softmode для журналирования. <br><br>Я не знаю, что именно там используется, но представить там PaX я вполне могу.<br><br>&gt; Смотри на ситуацию вирусной атаки<br><br>Смотрю: пришёл хакир-вася, поломал мой мега-софт и выключил жизнеобеспечение пациента/систему АЗ АЭС. Потому что может. В логе осталась запись. Успех.<br>(за скобками оставляем вопрос о том, откуда на нашем мега-важном производстве взялся удалённый доступ к https://opennet.dev/openforum/vsluhforumID3/119792.html#144 Thu, 05 Mar 2020 13:31:42 GMT &gt; Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например.<br><br>А кто даст гарантию что не упадет процесс отвечающий за переключения или вообще само ядро, для которого тоже W^X применяется?<br><br>Смотри на ситуацию вирусной атаки - все процессы в памяти имеют уязвимость переполнения буфера и при вирусной атаке ядпо с W^X их всех прибет.<br><br>W^X очень простая, дешовая и эффективная техника безопасности. Она идеальна для рабочей станции секретарши, смартфона, планшета, ноута итп.<br><br>В системах для которых кретически важна безперебойная работа используют другие, более дорогие, техники безопасности. А PAX включают только в режиме softmode для журналирования.<br><br>&gt; Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?<br><br>Тогда виноват не админ с PaX а программист...<br><br>&gt; mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы.<br><br>Это делать можно, например clamav так и делал. Но это неправильно. Лучше https://opennet.dev/openforum/vsluhforumID3/119792.html#143 Wed, 04 Mar 2020 17:44:26 GMT &gt;&gt; Последствия-то какие будут, если пакет какое-то время пробудет без PaX-флагов? Давай, думай, рассуждай.<br>&gt; А это уже как повезёт. Может быть и никаких.<br><br>Рассуждать отказался. Ну, кто бы сомневался.<br><br>&gt; Само по себе позднее выключение prot_exec тоже не приводит ни к каким последствиям.<br><br>И это твоё замечание могло бы иметь смысл, если б меры защиты существовали сами по себе.<br><br>&gt; Это один из возможных векторов атаки, безусловно, не факт, что он будет использован.<br><br>Отрицание реальных рисков безопасности и моделей угроз, основанных на давно известных практиках эксплуатации уязвимостей. Или ты опять что-то другое имел ввиду?<br><br>&gt; Но если его не будет - лучше.<br><br>А лучше или хуже - какими факторами и критериями определяется?<br><br>&gt; Я понимаю, что также как и некоторые решение в pledge (делающие его неидеальным, которые ты приводил в пример, например), pax(ctl)?d - это компромис. <br><br>Неидеальный - это бессодержательная характеристика, потому как ни что не идеально. Решения в pledge, как они есть сейчас, не учитыв https://opennet.dev/openforum/vsluhforumID3/119792.html#142 Wed, 04 Mar 2020 17:42:48 GMT &gt;&gt; Я обратил внимание и уверен, что это не более чем фигура речи. Кроме того, уязвимость, оставленная доступной для эксплуатации не может быть маленькой проблемой, если только речь не идёт о конкретных частных случаях.<br>&gt; Ты можешь быть уверен в чём угодно - я не против.<br><br>Это ты на словах не против. А на деле две недели упражняешься в зарабатывании права на жизнь для своего мнения и претензий на его объективность. Если это не фигура речи, то очередной бесполезный тезис с привлечением чисто субъективного критерия.<br><br>&gt; Во всех ОС общего назначения по-умолчанию аналог PAX MPROTECT не активирован =&gt; уязвимость оставлена для эксплуатации примерно везде.<br><br>Аргумент к опыту миллиона мух не принимается. У них по той же причине "оставлен для эксплуатации" не только данный класс уязвимостей, но и все остальные. В том числе RCE. И это с точки зрения "миллионов мух", видимо, тоже не является "большой проблемой".<br><br>&gt; Ну я сразу писал, почему "удобнее и красивее", а то, что ты прочитал не то, что я написал - это _твои_, https://opennet.dev/openforum/vsluhforumID3/119792.html#141 Wed, 04 Mar 2020 14:58:36 GMT &gt;&gt; Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть.<br>&gt; Классика жанра: <br>&gt; В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным.<br><br>Логика рассуждения мне понятна, спасибо. Мне не понятно, почему бы не резервировать эти процессы на изолированных контурах, например. Процесс может упасть из-за более тривиальной баги, не связанной с безопасностью - что тогда?<br>Или, например, можно не использовать динамических алокаций вообще, если условия задачи позволяют.<br>А PaX не обязательно убивает процесс, тот же PaX MPROTECT, про который тут шла речь, приводит к тому, что mprotect возвращает EPERM (с этим меня тут недалеко поправили) - это можно обрабатывать в коде программы.<br><br>&gt; В случаях когда работа сервиса имеет приоритет над безопас https://opennet.dev/openforum/vsluhforumID3/119792.html#140 Wed, 04 Mar 2020 14:41:23 GMT &gt; Ничто не мешает (теоретически) сразу написать ПО с учётом модели памяти в PaX и смысл в этом есть.<br><br>Классика жанра:<br><br>В спец ПО для райнимации больного допустили ошибку переполнения буфера или даже ядро OS имеет ошибку переполнения буфера. Вирус использует эту уязвимость переполнения буфера и ядро с W^X убивает процесс поддержки жизнедеятельности человека. Человек погибает, а компьютер остается не зараженным.<br><br>В случаях когда работа сервиса имеет приоритет над безопасностью, жесткий контроль за памятью использовать нельзя. Просто журналируются все события некорректного поведения процесса, без каких либо санкций к нему.<br><br>Это надо обязательно понимать и помнить.<br>