Описание: |
Найдена уязвимость в ядре 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 процесса, и проверка времени поставки
сигнала всегда будет всегда очищаться.
|