Comments 20
продано!
Xfce интересно выглядит на скриншоте
Что бы ни говорили критики, OpenBSD по праву считается одной из самых безопасных ОС,
Ага, по принципу "неуловимого Джо".
Адепты Линукса тоже самое говорили. Пока не появился Андроид, огромная установочная база среди казуалов, а стало быть возможность кражи денег/перс данных/слежки за людьми. И хлынул мощнейший поток найденных багов, что хорошо видно по количеству назначенных CVE с разбивкой по годам. При этом стоит учитывать, что мейнтейнеры ядра очень неохотно идут на присвоение CVE, предпочитая сделать молчаливый фикс, не всегда удачный (эпичный пример DirtyCow) а когда-то все баги даже получали статус DDoS, хотя на самом деле являлись гораздо более опасными LPE или RCE. Такое отношение сильно усложняет жизнь вендорам, т.к. они могут не бекпортить коммиты, которые не содержат отсылок к CVE По словам одного из исследователей безопасности, для поиска свежего и актуального 1-day для Линукса, достаточно пройтись по списку последних коммитов, и внимательно их изучить,, не обращая внимания на текст. Найденная таким образом уязвимость будет, с очень большой вероятностью, отсутствовать в специализированных сборках ядра.
Ага, по принципу "неуловимого Джо".
Это совсем не так. В статье нет ни слова от том, что Тео сотоварищами в начале 2000-х полностью перепахали весь код системы и всех системных утилит и исправили какую-то страшную гору потенциальных уязвимостей (BoF, использование неинициализированного указатетеля и т.д.). Так же выкинули массу сомнительного legacy кода. В этом смысле исходный код OpenBSD уникален и является эталоном для подражания.
в Линукс тоже все "перепадали" и написали "с нуля"
Любой свеженаписанный код может содержать уязвимости. Собственно именно так основная масса и появляется. Уязвимости класса "since 2.x" очень редки сейчас. Гораздо более типична ситуация, когда уязвимость появилась за несколько месяцев до фикса.
Поэтому извините, но "переписанность" плохой аргумент. Старый код, пусть некрасивый, но выдержавший годы изучения, фаззинга, да и просто работы на миллиардах систем - выглядит более надёжно.
И много в том же андройде уязвимостей уровня ядра? Или под линуксом вы подразумеваете и весь юзер спэйс? Так в андройде из линуксового юзер спейса почти нет ничего.
Да как бы все они там. Если уязвимость не в редком драйвере. И с учётом что версии на Андроиде существенно отстают. Самые новые уязвимости туда попадать не успевают. Интересный пример CVE-2019-2215 (да, биндер, но он давно в mainstream) - хапнули только те устройства, которые старались сделать ядро посвежее.
Посмотрите бюллетени, обычно одна, или даже парочка ежемесячно, даже сейчас. А вы думали как рутовалки типа KingRoot работают ?
Да как бы все они там. Если уязвимость не в редком драйвере. И с учётом что версии на
Как бы нет, основные уязвимости андройда это эскалация привилегий исполняемого кода до уровня рута или другого привилегированного процесс, что помогает обойти ограничения java песочницы. К примеру: https://habr.com/ru/company/otus/blog/547160/
Андроиде существенно отстают. Самые новые уязвимости туда попадать не успевают.
Отстает, так же как и большинство серьезных дистрибутивов, никто особо в бой, самые свежие версии не пускает.
Интересный пример CVE-2019-2215 (да, биндер, но он давно в mainstream) -
хапнули только те устройства, которые старались сделать ядро посвежее.
Как всегда вопрос количества уязвимостей и темпа их появления. То что попадает в CVE ядра ежемесячно, по факту не эксплуатируемо, большинство это race conditions (ошибки синхронизации) или что-то где-то в древнем драйвере. Если CVE эксплуатируемо, должен быть как минимум рабочий эксплойт.
А вы думали как рутовалки типа KingRoot работают ?
Подозреваю, что механизм эскалации привилегий, там имеет к ядру достаточно опосредованное отношение. Всякие системные процессы выполняемые с рут привилегиями в андройде, дают гораздо большую поверхность для атаки.
То что попадает в CVE ядра ежемесячно, по факту не эксплуатируемо, большинство это race conditions (ошибки синхронизации) или что-то где-то в древнем драйвере.
Открываю новости за октябрь:
уязвимость в подсистеме io_uring ядра Linux, позволяющая повысить привилегии в системе (эксплоит есть, пока сознательно не публикуют)
уязвимости в беспроводном стеке ядра Linux, допускающие удалённое выполнение кода (опубликованы примеры кадров).
август:
уязвимость в ядре Linux, позволяющая изменить содержимое tmpfs (есть эксплоит)
эксплуатируемые уязвимости в POSIX CPU timer, cls_route и nf_tables (опубликованы рабочие прототипы эксплоитов)
июнь:
уязвимость в подсистеме Netfilter, позволяющая получить рута
и следом ещё одна
И что из этого можно использовать для успешной атаки на тот же андройд?
Открываем бюллетень за октябрь, идём в секцию Kernel:
CVE-2022-1786 A-230867044
Upstream kernel [2] EoP High io_uring
CVE-2022-20421 A-239630375
Upstream kernel EoP High Binder driver
CVE-2022-20422 A-237540956
Upstream kernel EoP High armv8 emulation
CVE-2022-20423 A-239842288
Upstream kernel [2] EoP High USB
за сентябрь, август, июль, июнь и т.д. можете глянуть самостоятельно.
основные уязвимости андройда это эскалация привилегий исполняемого кода до уровня рута или другого привилегированного процесс, что помогает обойти ограничения java песочницы.
Что значит "основные" ? То что есть уязвимости кроме ядра, никоим образом на уязвимости ядра не влияют. Это для любой системы справедливо.
То что попадает в CVE ядра ежемесячно, по факту не эксплуатируемо,
Совершенно верно. Но какая разница, если есть и то, что эксплуатируемо ? А самое главное - есть то, что эксплуатируемо, но не попало в CVE.
большинство это race conditions (ошибки синхронизации)
Не надо ндооценивать гонки))
CVE-2017-7533 эпичная по простоте гонка, которая великолепно давала LPE хоть на десктопе, хоть на Андроиде.
или что-то где-то в древнем драйвере.
Ещё один камень в огород Линукса на десктопе. Какая разница компании, утащили у неё данные пробив через новомодную систему виртуализации, или через древний драйвер для перфокарт ?
Если CVE эксплуатируемо, должен быть как минимум рабочий эксплойт.
За один 2022 год их уже несколько дейстков. Эксплоитов, не CVE.
Подозреваю, что механизм эскалации привилегий, там имеет к ядру достаточно опосредованное отношение.
А я не подозреваю, а знаю. KingRoot - набор ядерных эксплоитов.
Всякие системные процессы
выполняемые с рут привилегиями в андройде, дают гораздо большую поверхность для атаки.
С андроидным юзерспейсом всё "плохо" в ключе атаки, поверхности атаки уменьшены настолько, насколько это возможно. Я поясню:
рут имеет минимум процессов
[Caps] все процессы сразу же ограничивают capabilities. Т.е. их рут - так себе рут.
[SELinux ]есть жёстко настроенные политики SELinux. Например - ещё в 7ом адроиде буквально несколько системных процессов могли выделять исполняемую память. Подозреваю, что сейчас всё стало намного жёстче.
[seccomp] чётко очерчен круг разрешённых к вызову syscalls
[SecBoot] - доверенная загрузка. Целостность всех разделов (кроме /data, но он шифрован) И проверяется в ходе доверенной загрузки. Скомпрометировать загрузку системы невозможно.
[RO mount] - все разделы, кроме /data являются readonly. Это сразу отметает все атаки с подменой файлов.
[RKP] вендоры типа Qualcomm/Samsung/Huawei реализуют собственные мониторы целостности ядра, которые весьма непросто обойти, даже имея мощный post-exploitation примитив типа Arbitrary KRW[X].
Ещё один камень в огород Линукса на десктопе. Какая разница компании, утащили у неё данные пробив через новомодную систему виртуализации, или через древний драйвер для перфокарт ?
Для этого как минимум надо этот считыватель перфокарт иметь.
С андроидным юзерспейсом всё "плохо" в ключе атаки, поверхности атаки уменьшены настолько, насколько это возможно. Я поясню:
Только почему-то подавляющее большинство уязвимостей из того же бюллетеня (https://source.android.com/docs/security/bulletin) именно из юзер спейса, а не ядра. (собственно об этом и был мой изначальный тезис)
PS: и интересно какой ни буть прув по поводу KingRoot, единственное что я нашел, что он подтягивает зашифрованный пэйлоад с сервера, вообще без какого либо анализа, что за эксплойты там используются.
На языках семейства X/XXX принципиально невозможно написать надёжную программу (если её сложность несколько выше Хело вёрда. Между прочим это математически доказывается). А если ещё вспомнить о том что ныне и железо дырявое как сыр ... О какой безопасности можно говорить! Хотя, не поспоришь, ОС семейства BSD, отличаются надёжностью и качеством от других ОС.
А так, моя любая OC. Стоит на нескольких серверах дома и на работе. Пользуюсь также и на десктопе и ноуте.
Интересно здесь также же стройность, качество документации, не подверженность панки нумераций (то, мажорные версии меняются на каждый чих, то скачок на несколько штук, то вдруг решают, что год лучше всего подходит для версий) отсутствие излишеств, выход релизов прям по расписанию в течение этих 27 лет…
Использую как fw, как собственный почтовый сервер, как хостинг для друзей, как хостинг для карточек, как сервер репозиториев (hg) для своих проектов и документов.
Отдельно стоит отметить такую жемчужину как pf, также отмечу уже упомянутый OpenSMTPD, с нуля написанный smtp-сревер, без тяжкого наследия предков. Синтаксис его конфигов также человечен как и pf (и встречается ещё в нескольких разработках команды OpoenBSD).
С интересом узнал, что Тео жил в Юконе; всегда думал, что он только в Калгари был после ЮАР. Теперь понятно, откуда такая Северная надёжность и обязательность.
Добавлю, что на vultr.com можно сделать себе vps на OpenBSD без проблем.
Pledge/unveil это то, чего сильно не хватает ядру Линукс.
Пользуемся, благодарим. 💪
27 лет назад появилась OpenBSD