@a13xp0p0v We're still planning to reenable it, but it would require
a per-user / project setting, or better moderation tools.
Still looking for more human resources to address both.
Не очень понимаю, почему зеркалирование на собственный сервер не устроило, а зеркалирование на платформы, пользующиеся, мягко говоря, скромной популярностью, устроило :)
По моим наблюдениям, именно на Codeberg переезжают разработчики, которых не устроила покупка платформы GitHub, юридические проблемы с GitHub Copilot и ряд других событий.
Безусловно, Codeberg сильно меньше, чем GitHub. И все-таки переезд туда в случае ЧП для меня дает точно больше плюсов, чем переезд на изолированный сервер.
Кроме того, чем больше будет проектов (ну хотя бы зеркал проектов) на Codeberg и российском GitFlic, тем более популярными они будут становиться. А иначе вообще без шансов.
И да, а что с GitLab for Open Source Prorgam, присоединиться к которой GitLab предлагает на первой же картинке в посте? Вроде, у Вас проекты open source, обещают бесплатно все фишки Ultimate подписки.
Это правильная мысль, и я в первую очередь посмотрел на эту их "GitLab for Open Source Program".
Что обнаружил:
Все детали по заявке проверяет их "доверенный партнер", компания SheerID, которая имеет право запросить у тебя любую дополнительную информацию.
Такую проверку ты должен проходить каждый год.
Помимо требований по открытости лицензий ты подписываешь обязательства "NOT SEEKING PROFIT" для всех проектов в namespace.
В конце формы регистрации стоит вот эта главная фраза:
Решил не ввязываться в эту муть.
К тому же, как показала моя практика, GitLab может на ходу поменять свои правила.
Наверное вы имели в виду то, что функциональность моего демонстрационного руткита совсем простая.
Я особенно не стремился написать продвинутый руткит. При этом мне кажется, что все возможности для этого есть.
По адресу assert_fail_msg() я записал сам код хука руткита и затем данные для него (строку, которая распечатывается в ядерном журнале). В этом хуке можно читать и писать любую память, я знаю адрес его расположения.
Я думаю, это достаточная основа для написания любого руткита.
SLAB_QUARANTINE рандомизирован. Он намного больше, под него отводится 1/32 часть всей динамической памяти ядра. Поэтому для того, чтобы вытолкнуть из карантина объект, нужен спрей существенно большего объема.
При этом freelist в slab-кэше, мне кажется, может быть совсем коротким. Поэтому изменение положения объекта в нем не сильно повлияет на работу эксплойта.
На странице make-linux-fast-again перечислены только параметры командной строки ядра, которые относятся к transient execution CPU vulnerabilities.
Этот сайт шуточный. Если падение производительности на 1% — это очень больно для вас в ваших условиях, то стоит заняться профилировкой ядра и юзерспейса под ваш тип рабочей нагрузки.
Кстати, копировать все параметры со странички make-linux-fast-again бессмысленно. Все защиты от уязвимостей CPU и так будут отключены, если просто написать "mitigations=off" :)
Эксперименты с фаззингом ядра я веду непрерывно, параллельно с другими задачами.
Особое внимание при этом уделяю подсистемам ядра, которые предоставляют в пользовательское пространство интерфейсы, не требующие дополнительных привилегий. Это периметр атаки. При эксплуатации уязвимостей в таких подсистемах есть возможность для повышения привилегий.
Касательно времени исследования — детально есть в презентации:
5 сентября мой syzkaller выдал интересный crash;
13 сентября я начал разбираться (в основном в свободное время и на выходных);
на Linux Security Summit ударными темпами доделал эксплойт, порадовался и 1 ноября отправил патч и PoC crasher на security@kernel.org.
То есть исследование этой конкретной уязвимости заняло 1.5 месяца. Не очень быстро.
Добавил ссылку на модель угроз LKRG.
И добавил LKRG в карту. Это объект «Out-of-tree Defence», который противодействует методам эксплуатации «Metadata Corruption» и «Changing Kernel Image».
Средства защиты, которые требуют аппаратной поддержки, в легенде обозначены как «HW Defences» бирюзового цвета.
Среди них:
— SMEP (Supervisor Mode Execution Protection) для X86 и ее аналог PXN (Privileged eXecute-Never) для ARM,
— SMAP (Supervisor Mode Access Prevention) для X86 и ее аналог PAN (Privileged Access-Never) для ARM.
некоторые конфигурации ядра, которые увеличивают поверхность атаки, одновременно могут использоваться для безопасности. Такие примеры включают uprobes и kprobes, модули ядра и BPF/eBPF. Наша рекомендация состоит в том, чтобы использовать вышеуказанные механизмы для обеспечения реальной защиты, поскольку они нетривиальны для использования, а их эксплуатация предполагает, что вредоносные субъекты уже закрепились в системе. Но если эти параметры включены, системный администратор должен активно следить за злоупотреблениями.
Неудачный перевод очень интересного абзаца про анализ опций безопасности ядра.
Действительно, есть ряд опций ядра Linux, при включении которых поверхность атаки для ядра увеличивается. При этом данные опции могут использоваться для предоставления дополнительных средств безопасности для пользовательского пространства, а именно: CONFIG_USER_NS для контейнерной изоляции, ftrace для live patching, eBPF для фильтрации трафика и пр.
Рекомендация автора оригинальной статьи в том, что следует включать данный функционал, только если польза для общей безопасности системы превышает потенциальную угрозу эксплуатации уязвимостей в нем.
На вашем снимке экрана настройка push-mirroring. Это зеркалирование с Codeberg куда-то.
А для зеркалирования с GitHub на Codeberg нужна функция pull mirroring. Она отключена.
Вот, что Codeberg ответил мне в mastodon по поводу ее включения:
Помимо этого, похоже, Bitbucket не умеет импортировать информацию из issues и pull requests на GitHub:
https://community.atlassian.com/t5/Bitbucket-questions/We-want-to-migrate-from-github-to-bitbucket-with-PR-s-issues-e-t/qaq-p/1748902
Нет, конечно, все меняют правила.
Но тот же Codeberg, когда закрыл функцию pull mirroring, при этом не отказался от обслуживания уже созданных пользователями зеркал. Мое уважение.
А GitLab в аналогичной ситуации просто сломал зеркалирование в моих репозиториях. На мой вкус, это некомильфо.
По моим наблюдениям, именно на Codeberg переезжают разработчики, которых не устроила покупка платформы GitHub, юридические проблемы с GitHub Copilot и ряд других событий.
Безусловно, Codeberg сильно меньше, чем GitHub. И все-таки переезд туда в случае ЧП для меня дает точно больше плюсов, чем переезд на изолированный сервер.
Кроме того, чем больше будет проектов (ну хотя бы зеркал проектов) на Codeberg и российском GitFlic, тем более популярными они будут становиться. А иначе вообще без шансов.
Это правильная мысль, и я в первую очередь посмотрел на эту их "GitLab for Open Source Program".
Что обнаружил:
Все детали по заявке проверяет их "доверенный партнер", компания SheerID, которая имеет право запросить у тебя любую дополнительную информацию.
Такую проверку ты должен проходить каждый год.
Помимо требований по открытости лицензий ты подписываешь обязательства "NOT SEEKING PROFIT" для всех проектов в namespace.
В конце формы регистрации стоит вот эта главная фраза:
Решил не ввязываться в эту муть.
К тому же, как показала моя практика, GitLab может на ходу поменять свои правила.
Безусловно, проблемы нет.
Пока что не хочется без крайней надобности использовать в GitHub Actions токен с разрешением коммитить в репозиторий.
Pull request с обновлениями
issues.mdв свою очередь сам изменяетissues.md:)Поэтому решил не заморачиваться с преждевременной автоматизацией.
Да, эксплуатация повреждения памяти в куче очень сильно зависит от поведения аллокатора.
Есть множество различных средств безопасности, которые противодействуют этому типу уязвимостей. Посмотрите мою карту средств защиты ядра Linux: https://github.com/a13xp0p0v/linux-kernel-defence-map
В ней даются связи между классами уязвимостей, методами их эксплуатации и средствами защиты.
Вот список железа, на котором работает Fuchsia:
https://fuchsia.dev/fuchsia-src/development/hardware
Там устройства:
Intel NUC,
Chromebooks,
Khadas VIM3 (на ARM Cortex-A73)
В продаже у Google сейчас два устройства, на которых установлена Fuchsia:
Nest Hub
Nest Hub Max
Ходят слухи про прототипы смартфонов под управлением Fuchsia:
https://screenrant.com/future-samsung-smartphones-might-ship-with-fuchsia-os-instead-of-android/
В разделе
Zircon fundamentalsможно почитать про основные свойства Zircon : https://fuchsia.dev/fuchsia-src/get-started/sdk/learn/intro/zircon?hl=enЦитата:
Не, все нормально :) Он здорово разбирается в теме и, как я понял, имеет опыт разработки эксплойтов.
Спасибо! На самом деле, это было быстрое исследование. Всего полтора месяца, плюс две недели на написание статьи.
Да, верно. Я решил не жадничать и оставить поиск 0-day на следующий раз.
Кстати, syzkaller для Fuchsia на днях починили: https://github.com/google/syzkaller/pull/3205
Наверное вы имели в виду то, что функциональность моего демонстрационного руткита совсем простая.
Я особенно не стремился написать продвинутый руткит. При этом мне кажется, что все возможности для этого есть.
По адресу
assert_fail_msg()я записал сам код хука руткита и затем данные для него (строку, которая распечатывается в ядерном журнале). В этом хуке можно читать и писать любую память, я знаю адрес его расположения.Я думаю, это достаточная основа для написания любого руткита.
Отличий много.
SLAB_QUARANTINEрандомизирован. Он намного больше, под него отводится 1/32 часть всей динамической памяти ядра. Поэтому для того, чтобы вытолкнуть из карантина объект, нужен спрей существенно большего объема.При этом freelist в slab-кэше, мне кажется, может быть совсем коротким. Поэтому изменение положения объекта в нем не сильно повлияет на работу эксплойта.
На странице make-linux-fast-again перечислены только параметры командной строки ядра, которые относятся к
transient execution CPU vulnerabilities.Этот сайт шуточный. Если падение производительности на 1% — это очень больно для вас в ваших условиях, то стоит заняться профилировкой ядра и юзерспейса под ваш тип рабочей нагрузки.
Кстати, копировать все параметры со странички make-linux-fast-again бессмысленно. Все защиты от уязвимостей CPU и так будут отключены, если просто написать "mitigations=off" :)
Да, верно, я упоминал CVE-2019-18683 в своем выступлении "Фаззинг ядра Linux на практике" на ISPRASOPEN.
Есть, кстати, видеозапись доклада и ответов на вопросы:
http://0x1.tv/20191206AG
Спасибо за вопросы.
Эксперименты с фаззингом ядра я веду непрерывно, параллельно с другими задачами.
Особое внимание при этом уделяю подсистемам ядра, которые предоставляют в пользовательское пространство интерфейсы, не требующие дополнительных привилегий. Это периметр атаки. При эксплуатации уязвимостей в таких подсистемах есть возможность для повышения привилегий.
Касательно времени исследования — детально есть в презентации:
То есть исследование этой конкретной уязвимости заняло 1.5 месяца. Не очень быстро.
Добавил ссылку на модель угроз LKRG.
И добавил LKRG в карту. Это объект «Out-of-tree Defence», который противодействует методам эксплуатации «Metadata Corruption» и «Changing Kernel Image».
github.com/a13xp0p0v/linux-kernel-defence-map/commit/8749c74f68963967ceafd3c760cb259ce9851143
Уже применил:
github.com/a13xp0p0v/linux-kernel-defence-map/commit/eab4d2ba3e3d7d5f22e28381b733220f70d8b443
(если у вас есть учетка на github, пришлите, пожалуйста, для ссылки)
Среди них:
— SMEP (Supervisor Mode Execution Protection) для X86 и ее аналог PXN (Privileged eXecute-Never) для ARM,
— SMAP (Supervisor Mode Access Prevention) для X86 и ее аналог PAN (Privileged Access-Never) для ARM.
Да, карта наглядно показывает, насколько большой вклад grsecurity внесли в безопасность ядра. Эти парни отлично знают, что делают.
Только с тем, чтобы купить у них поддержку, есть огромные сложности.
Неудачный перевод очень интересного абзаца про анализ опций безопасности ядра.
Действительно, есть ряд опций ядра Linux, при включении которых поверхность атаки для ядра увеличивается. При этом данные опции могут использоваться для предоставления дополнительных средств безопасности для пользовательского пространства, а именно: CONFIG_USER_NS для контейнерной изоляции, ftrace для live patching, eBPF для фильтрации трафика и пр.
Рекомендация автора оригинальной статьи в том, что следует включать данный функционал, только если польза для общей безопасности системы превышает потенциальную угрозу эксплуатации уязвимостей в нем.