Comments 18
Приложения идентифицируются с помощью URL и скачиваются системой непосредственно перед их запуском. Такое архитектурное решение было выбрано для того, чтобы программные пакеты в Fuchsia всегда были в актуальном состоянии (наподобие веб-страниц).
Что-то у меня боязнь таких новаций.
Интересно насколько это ядро Zircon похоже на минималистичное L4.
В разделе Zircon fundamentals можно почитать про основные свойства Zircon : https://fuchsia.dev/fuchsia-src/get-started/sdk/learn/intro/zircon?hl=en
Цитата:
Although Zircon applies many of the concepts popularized by microkernels,
it does not strive to be minimal.
В итоге по адресу assert_fail_msg вы записали указатель на функцию, которая не особо зависит от смещений. Интересно, как это можно эксплуатировать в реальных условиях, например запуск внешнего кода или процесса с привилегиями ядра? С учётом того, что файловая система ограничена и ядру напрямую видимо запрещено ходить в интернет. Просто ваш пример эксплуатации немного искусственный. Условно говоря, запись в лог ядра - это не эксплуатация, тем более что вызов assert_fail_msg вы не контролируете.
Наверное вы имели в виду то, что функциональность моего демонстрационного руткита совсем простая.
Я особенно не стремился написать продвинутый руткит. При этом мне кажется, что все возможности для этого есть.
По адресу assert_fail_msg() я записал сам код хука руткита и затем данные для него (строку, которая распечатывается в ядерном журнале). В этом хуке можно читать и писать любую память, я знаю адрес его расположения.
Я думаю, это достаточная основа для написания любого руткита.
В качестве первого эксперимента я перезаписал всю таблицу системных вызовов значением 0x41, получив управление в моей функции pwn()
Я правильно понял, это все сделано в условиях вашей «синтетической» уязвимости?
Спасибо! На самом деле, это было быстрое исследование. Всего полтора месяца, плюс две недели на написание статьи.
Я правильно понял, это все сделано в условиях вашей «синтетической» уязвимости?
Да, верно. Я решил не жадничать и оставить поиск 0-day на следующий раз.
Кстати, syzkaller для Fuchsia на днях починили: https://github.com/google/syzkaller/pull/3205
По словам архитектора безопасности Fuchsia OS, он бы атаковал систему так же, как и я
Но почему-то этого не сделал.
А насколько много сейчас устройств на базе этой ОС? Вроде только Nest же, не?
Вот список железа, на котором работает 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/
В Fuchsia даже нет глобальной файловой системы. Вместо этого каждому компоненту выдается отдельное пространство для работы с файлами.
Cудя по документации, файловая система построена очень интересно. Извне – все readonly, интересные циклы общения между компонентами.
Возникает вопрос: насколько затратно выходит работа такой схемы?
Правильно ли я понял, что успех атаки сильно зависит от успеха heap spraying?
Помогли бы в этом случае секьюрные аллокаторы вроде:
?
Да, эксплуатация повреждения памяти в куче очень сильно зависит от поведения аллокатора.
Есть множество различных средств безопасности, которые противодействуют этому типу уязвимостей. Посмотрите мою карту средств защиты ядра Linux: https://github.com/a13xp0p0v/linux-kernel-defence-map
В ней даются связи между классами уязвимостей, методами их эксплуатации и средствами защиты.
Статья - огонь!!
После просмотра нескольких листингов на C++ идеология написания ядра Linux на чистом C больше не кажется архаичной.
Статья отличная, даже просто как тур по Zircon интересно читается!
Fuchsia OS глазами атакующего