Board.KolibriOS.org

Предлагаю в этой теме писать об уязвимостях ядра, которые, к сожалению, имею место быть.
В этом сообщении будет представлен актуальный список уязвимостей, чтобы с ними можно было бы ознакомиться, не перечитывая всю тему.
Уязвимости ядра:

---

vlnb-kos-s-0-a (Не устранена) 9.10.2010

Spoiler:

Перезаписав файл ядра, можно выполнить любой код, в т.ч. вредоносный, в реальном режиме процессора (т.е. с максимальным уровнем привелегий).

vlnb-kos-s-1-a (Не устранена) 17.04.2011

Spoiler:

Многие сис. функции ядра позволяют прикладным программам писать в память ядра (т.е. в диапазоне 0x80000000-0xFFFFFFFF), тем сам можно "прибить систему" или выполнить пользовательский код с максимальным уровнем привелегий (в 0-вом кольце).

---

Подробнее об слабых местах в защите читайте в последующих сообщениях.


Примечания:
Название уязвимости имеет следующий формат: vlnb-x-y-n-z
vlnb - сокр. от "vulnerability"
x - ОС, в которой имеется дырка (в данном случае kos - KolibriOS)
y - тип уязвимости, "s" - system vulner., "a" - application vulner.
n - номер уязвимости (присваивается в порядке появления бреши)
z - уровень опасности, которую представляет дыра, "a" - самый высокий, "b" - средний, "c" - низкий

Оказывается многие сисфункции позволяют писать в память ядра. В большинстве случаях максимум чего может добиться злобный кодер - это ушатать систему, заставив её зависнуть, но с помощью некоторых сисфункций можно записывать любые данные, включая вредоносный код, и дают шанс выполнить его в kernel mode. Также вирус способен записать свою в загрузочный сектор рамдиска, а пользователь потом, сохранив рамдиск на дискету или винчестер, запустит его в real mode (вероятность не больщая, но она таки есть).
Список функций, которые уязвимы и ранимы: 6, 9, 15.5, 18.11, 18.13, 26.2, 30.2, 36, 48.3, 70. Возможно есть ещё дырявые сисфункции, которые я не нашёл.
Исправить уязвимость не сложно. Есть два способа: a) проверять адреса для записи, которые передаются как параметры, выходят ли они за рамки возможной памяти приложения (диапазон 0x000000000-x7FFFFFFF); б) воспользоваться ядерной функцией check_region, которая проверяет не выходит ли буфер из диапазона используемой процессом памяти (0x000000000-x????????)

Вот эксплойты демонстрирующие использование ядренных дырок:
1st:
Запускаем программу и все букаффки пропадают (не считая консоли) А через полминуты шрифт восстанавливается; 2nd:
Кейлоггер)) взламывает защиту ядра, вылезает в 0-ое кольцо и перехватывает нажатия клавиш, записывая их в файл /sys/.keylog (если пользователь этого пожелает); помимо этого перехватывает функцию 9, скрывая себя из списка процессов (при этом окно отображается), и функции 18.2 и 18.18, не давая прибить себя Неплохо оптимизирован по размеру.
Запускать желательно из под ВМ. Этот эскплойт лишь демонстрирует возможности кейлоггинга, т.к. записывает кейлог только по желанию пользователя. Кейлог включает в себя как текст, так и сканкоды.

Думаю, именно для подобных вещей и существует багзилла.

Не каждый баг - это уязвимость, и не каждая уязвимость - это баг
Думаю, такая серьезная проблема, как огромные дыры в системе, заслуживает внимания - в нынешнем положении любая программа может делать что угодно и иметь систему как ей заблагорасудиться в любых позах.

Может вместо апостольских откровений стоит заняться делом?

Напрасно, что создали эту тему и именно с таким сабжем.

Так называемых "уязвимостей" так много, что можно засыпать ветку до основания.

Серьезный подход к вопросу надежность, устойчивость... ядра был бы в конструктивном названии ветки типа:

"Основные недостатки ядра и варианты их решения"

"Проблемы ядра при работе с ....., как это перспективно улучшить?"

"Архитектурные "упрощения" в ядре Колибри. Не пора ли поэтапно мутировать в "полноценное" ядро?"

и т.п.

Как таковые "Уязвимости" могут быть тогда, когда версия ядра (ОСи) достаточно стабильна, испытана, а изъяны архитектурного плана ядра изложены и перечислены.
Тогда по идее нельзя спутать архитектурный недостаток или ограниченность и именно уязвимость.
Хотя надо признать, реальная "активность ветки" даже такого плана, своего рода индикатор работы и вообще интереса в ядерном плане.
Имхо.

OK, на сабж всем насрать, убедили. Раз тема создана напрасно, можете удалять.

Здравствуйте!

Тема нужная и правильная, просто она не в правильном русле...

Ты поступаешь как добропорядочный хакер: я нашёл уязвимость, вот она вам, сидите и исправляйте...так делает посторонний человек никак не связанный с тем или иным проектом, а ты наш, свой, по идее раз ты смог найти уязвимость, надо постараться её исправить, а не писать программы показывающие как эта уязвимость рушит систему...

Просто сейчас у меня совсем нет времени исправить дырки (к тому же, хотя vlnb-kos-s-0-a я и исправил, реализация фикса мало кому понравиться). Тема была создана в расчёте на то, что человек разбирающийся в ядре и имеющий желание(и время) сможет убрать уязвимости из системы с помощью этой самой темы.

"Чистые руки - чистая совесть"...

Интересно, а хоть одна из вышеописанных уязвимостей была закрыта, пускай даже частично?

Aeol wrote:Интересно, а хоть одна из вышеописанных уязвимостей была закрыта, пускай даже частично?

Aeol = Nasarus?

Раньше - да, я этого и не скрываю.

ОГОГОШЕНЬКИ!! С возвращением!!!)))))))

Leency wrote:ОГОГОШЕНЬКИ!! С возвращением!!!)))))))

Приятно слышать, коли не шутишь)

Ну а если по существу, то я задал этот вопрос не потому, что решил поднять свою, никому не нужную тему, а так как мне на самом деле интересно латал ли, залатал ли кто-либо эти дыры, ибо последние 1,5 года я за проектом следил изредка и весьма поверхностно (в силу обстоятельств, разумеется)