История о трёх уязвимостях ядра

Оригинал статьи расположен по ссылке.

Недавно Trustwave, фирма специализирующаяся на информационной безопасности, опубликовала анонс отчёта, в котором критикуется, как Linux-сообщество справляется с уязвимостями. В нём сказано: «Разработчики программного обеспечения сильно разнятся в своей способности реагировать и устранять уязвимости нулевого дня. В этом исследовании показано, что у разработчиков Linux худшее время реагирования: с момента обнаружения уязвимости до выхода патча в среднем проходит почти три года». Вне зависимости от того, насколько вы довольны обновлениями безопасности в Linux, три года — это гораздо больше, чем мы обычно ожидаем. Ваш покорный слуга решил исследовать ситуацию, сконцентрировавшись на двух уязвимостях, которые были включены в отчёт Trustwave и на одной, которой там не было.

Три года?

На момент написания статьи, полный отчёт Trustwave ещё не был доступен(сейчас его можно скачать здесь. — Прим. пер.), поэтому детальное изучение представленных утверждений не представляется возможным. Но, судя по этой статье на ZDNet, среднее время ответа было вычислено по этим двум уязвимостям нулевого дня:

• CVE-2009-4307: ошибка деления на ноль в коде файловой системы ext4. Для эксплуатации этой уязвимости необходимо, чтобы пользователь смонтировал специально подготовленный образ файловой системы ext4.

• CVE-2009-4020: переполнение буфера в файловой системе HFS+; эксплуатируется, опять же, путем монтирования специально подготовленного образа файловой системы на целевой системе.

О проблеме, связанной с файловой системой ext4, сообщил R. N. Sastry 1 октября 2009 года, который проводил fuzz-тестирование файловой системы (тип тестирования, при котором поиск ошибок осуществляется с помощью случайных входных данных. — Прим. пер.). Сообщение об ошибке включало в себя и образ файловой системы, провоцирующий баг, что по сути является «эксплойтом» для этой уязвимости, что позволило Trustwave называть это уязвимостью нулевого дня. И, поскольку проблема вызывала всего лишь kernel oops (системная ошибка, после которой часто случается kernel panic — Прим. пер.), а также требовала сотрудничества со стороны жертвы (монтирования файловой системы, подготовленной атакующим), разработчики ext4 не посчитали нужным все бросать и сразу же устранять уязвимость. Ted Ts'o закомиттил исправление в конце ноября. SUSE первой опубликовали обновление с устранением уязвимости, это случилось 17 января 2010 года. Red Hat не выпускала обновление до конца марта, почти пять месяцев с момента появления информации об уязвимости, а Mandriva ждала до февраля 2011.

Можно утверждать, что всё происходило не быстро, даже для бага с чрезвычайно низким приоритетом, но откуда же взялись эти «три года»? Они появились из-за того, что исправление не работало должным образом на x86 архитектуре. Xi Wang сообщил, что проблема по-прежнему существует, 26 декабря 2011 года и прислал толковое исправление 9 января 2012. Этой проблеме был назначен новый номер CVE (CVE-2012-2100), и исправление было оперативно влито в основную ветку. Мэйнтейнеры не были особо проворны, тем не менее Debian выпустил обновление в марте, Ubuntu — в мае, а Red Hat прождал до середины ноября. Потребовалось примерно одиннадцать месяцев после обнаружения уязвимости, чтобы доставить исправление до пользователей. С момента обнаружения проблемы до выхода обновления Red Hat, которое окончательно решило проблему, действительно, прошло больше трех лет.

История с HFS/HFS+ очень похожа. Первый патч, решающий проблему с переполнением буфера в HFS, был опубликован Amerigo Wang в начале декабря 2009 года. Исправление было закоммичено Линусом 15 декабря, а мэйнтейнеры Red Hat начали распространять обновление 19 января 2010 года. Некоторые мэйнтейнеры были ещё более медленными, но эта уязвимость также была признана трудноэксплуатируемой и считалась низкоприоритетной.

Проблема в том, что ядро поддерживает другую (более свежую) файловую систему под названием HFS+. Это отдельная реализация, содержащая изрядное количество кода, скопированного из оригинальной реализации HFS так же, как ext4 была начата с копирования ext3. Опасность такого дублирования кода прекрасно известна: разработчик исправляет проблему в одной копии, даже не подозревая, что такая же проблема может быть и в другой. Естественно, что это случилось и здесь. Реализация HFS+ имела такую же уязвимость переполнения буфера, но никто и не подумал об этом, пока Timo Warns не привлёк внимание нескольких разработчиков ядра в конце апреля 2012 года. Greg Kroah-Hartman опубликовал изменения 4 мая, и проблема получила огласку через несколько дней после этого. И опять был назначен новый номер CVE (CVE-2012-2319), и опять мэйнтейнеры просачковали с исправлениями. OpenSUSE выпустило обновление в июне, в то время как в Red Hat прождали до октября, прошло пять месяцев с момента того, как о проблеме стало известно. С момента обнаружения до публикации исправления в Red Hat прошло чуть менее трёх лет.

Но на эту проблему можно смотреть под разными углами. С одной стороны очевидно, что Trustwave специально выбрали эти уязвимости и затем интерпретировали их так, чтобы показать максимально возможное время исправления. Но ни одна из историй не описывает уязвимость нулевого дня, которая оставалась бы открытой в течение трёх лет; большую часть времени предполагалось, что проблема решена. Это вдвойне верно для HFS+, об уязвимости в которой даже не было известно до мая 2012 года. И, учитывая характер этих уязвимостей, весьма маловероятно, что black hat'ы ревностно скрывали их всё это время, и, скорее всего, ни одна система не была скомпрометирована с их использованием. Претензии Trustwave, если они основаны на этих двух уязвимостях, в лучшем случае являются сомнительными и преувеличенными.

С другой стороны, даже низкоприоритетные уязвимости, требующие действий жертвы, должны быть исправлены, корректно и по-возможности быстро. Но, на самом деле, не всё так просто с тем, что произошло с этими уязвимостями. Реакция на проблему с ext4 была достаточно быстрой, особенно учитывая характер проблемы, но тот факт, что на x86 архитектуре проблема всё ещё была актуальна, показывает что как минимум тестирование было, по меньшей мере, неудовлетворительным. В случае с HFS/HFS+, кто вообще может осуждать кого-нибудь за то, что он не посмотрел, нет ли дубликата бага в каком-то другом месте? На фоне того, что файловые системы HFS и HFS+ почти не используются и, можно сказать, не поддерживаются, претензии не выдерживают критики. Однако атакующие не ограничиваются хорошо поддерживаемым кодом И, для обоих случаев, мэйнтейнеры вообще не озаботились доставкой исправлений своим пользователям. Можно бы было работать и получше.

Тем временем в 2013

Вероятно, медлительность показанная выше — это естественный ответ на уязвимости, которые на самом деле никого не волнуют. Если бы они они были более серьёзными реакция, бесспорно, была бы намного лучше. И как это обычно бывает, во время написания статьи (статья опубликована 19 февраля 2013. — Прим. пер.), существует незакрытая уязимость, так что мы сможем пронаблюдать за тем, насколько хорошо мы можем реигировать. И ответ не обнадёживающий.

20 января дискуссия из приватного списка рассылки по безопасности ядра стала публичной в связи с публикацией патча за авторством Олега Нестерова. Было продемонстрировано, что реализация системного вызова ptrace() в ядре Linux содержит состояния гонки: регистры трассируемого процесса могут быть изменены таким образом, чтобы ядро восстановило содержимое стека этого процесса в произвольном месте. В конечном счёте это приводит к возможности выполнения произвольного кода в режиме ядра. Атака осуществляется локально, поэтому взломщик должен запустить эксплоит на целевой системе. Но получив возможность запустить такую программу, он может пользоваться полным набором привилегий пользователя root. Такого рода уязвимости требуют незамедлительного внимания. Любая система с подобной уязвимостью фактически отдана на милось любого (в т. ч. недоверенного) пользователя, имеющего аккаунт, или любого взломщика, который может скомпрометировать сетевой сервис и запустить произвольную программу.

15 февраля уязвимость была обнаружена и опубликована, причём с весьма качественным кодом для эксплойта, для тех кто не хочет писать свой. Большинство жертв вряд ли применят патч к ядру, чтобы было легче реализовать состояние гонки, также эксплойту нужно работать в режиме реального времени, чтобы надёжнее выиграть гонку. Но даже без патча и работы в реальном времени, достаточно терпеливый атакующий сможет получить результат. Вот как отреагировал на обнаруженную уязвимость Solar Designer:

Я ещё не успел внимательно посмотреть на всё это, но на первый взгляд, это самая худшая уязвимость за несколько лет. Для мэйнтейнеров дистрибутивных ядер (отличных от основной ветки, которую запатчили почти месяц назад) это 0-day.

Вообще-то, это не должна быть уязвимость нулевого дня, поскольку публичному обсуждению исправления уже около месяца, а приватная продолжалась ещё некоторое время до этого. Но на момент написания, ещё ни один дистрибутив не выпустил обновления для этой проблемы. Что приводит нас к некоторым очевидным вопросам. Снова цитируем Solar Designer:

Коммиты Олега Нестерова из Red Hat в попали в основную ветку ещё в январе. Почему в Red Hat проблема не была(?) обработана со всей серьёзностью, ну или в конце концов не была опубликована информация, какие из их ядер подвержены этой уязвимости на данный момент.

Это заявление заставляет предположить, что похожие проблемы возможны и в будущем. А пока пользователям и системным администраторам по всему миру нужно волноваться, уязвимы ли их системы, и том, кто может проэксплуатировать эти уязвимости.

И снова: мы можем работать лучше. С самого начала было известно, что это серьёзная проблема; один из разработчиков, который сообщил о ней (Salman Qazi из Google) также приложил и эксплойт, чтобы показать, насколько ситуация серьёзна. Мэйнтейнеры знали о проблеме и имели достаточно времени, чтобы отреагировать на неё, но всё равно не отреагировали своевременно. Проблема с ptrace() решилась меньше чем за 3 года, но здесь нечем гордиться. Пользователей нельзя оставлять на произвол судьбы на целый месяц (если не больше), с того времени, как мэйнтейнеры узнали об этой проблеме.

Примечание от переводчика: Исправление в Debian было выпущено 25 февраля, в Red Hat — 26 февраля, в Ubuntu — 21 февраля, в OpenSUSE — 25 февраля.