Security Lab

DoS для OpenBSD

Дата публикации:08.10.2001
Всего просмотров:1193
Опасность:
Наличие исправления:
Количество уязвимостей:1
CVE ID: Нет данных
Вектор эксплуатации:
Воздействие:
CWE ID: Нет данных
Наличие эксплоита: Нет данных
Уязвимые продукты:
Описание:

Найдена уязвимость в ядре OpenBSD, которая позволяет любому пользователю, способному к выполнению процесса поставлять SIGURG и SIGIO сигналы к любому процессу (или групп процессов) принадлежащему любому пользователю в системе. Хотя поведение по умолчанию в OpenBSD должно игнорировать эти сигналы, эта проблема может вызывать эффективный DoS механизм для процессов, которые ловят оба сигнала.
Большинство Unix систем обеспечивают асинхронный механизм ввода-вывода: каждый раз данные прибывают в определенный дескриптор файла и операционная система уведомляет владельца с сигналом (SIGIO.) В случае сокетов, процесс уведомлен, когда пакет с флагом Out of Band прибывает с SIGURG сигналом. Этот механизм активизирован через функцию fcntl, с флагом O_ASYNC, или функцию ioctl с флагом FIOASYNC.

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

Управление разрешениями при установке владельца дескриптора файла обрабатывается по-разному в Linux и OpenBSD. В linux, возвращается EPERM ошибка, когда кто-то пытается устанавливать владельца дескриптора файла к процессу другого пользователя. В OpenBSD, функция не возвращает ошибку, вместо этого в этот момент система поставляет сигнал, проверяет разрешения, и выбирает решение.

Выполняя эту регистрацию в случае сокетов, ядро OpenBSD сохраняет структуру каждого сокета: so_siguid и so_sigeuid, с информацией процесса, который устанавливает владельца. Это препятствует неправомочному процессу от открытия, установки асинхронного флага, изменения владельца данного дескриптора файла, и отправки сигнала.

Ошибка существует в процедуре, которая создает новый связанный сокет, sonewconn1. Эта процедура не копирует структуру полей сокетов so_siguid и so_sigeuid. Они повторно устанавливаются в ноль в новом сокете. Т.е. становится возможным создать гнездо, назначать владельца на отличный процесс, принять запрос и заново установить флаги so_siguid и so_sigeuid. Это приведет к тому, что владелец нашего сокета отличен от ID процесса, и проверка времени поставки сигнала всегда будет всегда очищаться.