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

Original author: Jonathan Corbet
  • Translation
Недавно 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 февраля.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 24

    –12
    Не пользуйтесь бинарными дистрибутивами.
      +13
      Заведите себе больше одного компьютера.
        +2
        Держу 2 десктопа и 2 сервера на source-based и испытываю сложности только иногда с домашним десктопом ибо много экспирементирую и сижу на нестабильной ветке. Бинарные дистрибутивы не дают такой свежести пакетов и гибкости, увы.
          –2
          Почти ничего(кроме редких ситуаций, когда чтобы бэкпортировать пакет нужно ввести больше 4-5 команд) не мешает нужные пакеты собирать аналогично с source-based
            +1
            И тем не менее, в бинарных дистрибутивах это делать ужасно неудобно, по сравнению с тем, как это сделано в Gentoo. В ней — как лёгкая прогулка.
          0
          Откройте себе binhost и аналоги.
            –1
            То есть сделать себе свой собственный бинарный дистрибутив?
              0
              Подозреваю имели ввиду это, поправьте если ошибся.
        +10
        с момента обнаружения уязвимости до выхода патча в среднем проходит почти три года
        Статистика — такая статистика: делать такую далекоидущую оценку по двум фиксам — это имхо верх идиотизма!
        Граничит с взятием среднего от двух boolean (true и false) — в среднем получается и правда и ложь.
          0
          Я думаю они специально нашли два крайних случая чтобы показать как всё плохо. Единственное что они передёргивают, что это «среднее» время.
            0
            Вот как раз со средним временем всё в порядке.

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

            Ответ: никакой разницы ибо обе никуда не годятся. Они обе могут быть взломаны злоумышленником в любой момент. Умереть можно только один раз.

            А вот то, что обе уязвимости весьма и весьма непросто использовать там, где Linux, в общем-то только и используют (на сервере) — другой вопрос. PTRACE-уязвимость в этом смысле куда сурьёзнее.
              0
              А вот то, что обе уязвимости весьма и весьма непросто использовать там, где Linux, в общем-то только и используют (на сервере) — другой вопрос.


              Да и на десктопе тоже (может быть это может сработать с флешкой, форматированной в ext4, но даже тут придется повозиться ибо с ext4 на внешних флешках все, насколько я знаю, не очень гладко)
                +2
                Всё нормально с флешками и ext4. Журнал лишь отключить для лучшей производительности.
                  +1
                  Я смутно помню что флешка c ext (3 или 4 не помню) у меня на десктопной Ubuntu монтироваться без дополнительных зуботычин не желала. Я решил не заморачиваться и переделал флешку обратно в FAT.

                  Но таки да, в принципе да, флеш с таким вот «заряженным» ext4 — вполне себе могла быть орудием пролетариата все эти три года.
                    +1
                    До первого компьютера с Windows
                      +5
                      А ей и не надо «пререживать комп с Windows». Это прицельный булыжник, который оставляется вблизи мест обитания любопытной линуксоносной жертвы.
                      Конечно, такой сценарий предполагает наличие еще одной уязвимости — в wetware жертвы. Однако, практика показывает что у большинства людей (даже бородатых дяденек с подготовкой в области ИБ) желание узнать «что же на флешечке со стразиками и котиком» легко пересиливает здравый смысл и чувство самосохранения.

          +19
          Боже, какая махровая заказуха от Trustwave! Никогда не стоит доверять этой шарашке.
            +3
            Вот поэтому я и предпочитаю rolling-релиз дистрибутивы
              0
              А есть разница? Патчи безопасности в обычных бинарных дистрах имхо накатываются так же оперативно, как и выпускаются новые релизы с этими патчами в rolling. Другое дело source-based. Кинул ебилд в оверлей, скачал патчик, все, у тебя готов свой собственный релиз, который через binhost разливается на все нужные хосты.
                +1
                кинул патч в deb-src, собрал пакет, обновил на хостах. В чем разница-то?
                  0
                  В фане ;)
                    0
                    У бинарных и сурсовых дистро разные m4|automake|autoconf|configure|make|gcc|ld и прочая?
              0
              Не стоит ныть «аааа, ядро уязвимо! мы скоро все умрём!». Беспокоит проблема? Patch и make вам в помощь. А если мешает лень, то может не такая уж и критическая уязвимость?

              «А как же моя бабушка? Она не умеет собирать ядро!»
              А ваша бабушка умеет файлы использовать в качестве блочных устройств? Да и на флешках такая fs будет жить до первого компьютера с Windows.
                +1
                >: с момента обнаружения уязвимости до выхода патча в среднем проходит почти три года

                Вот насчет в среднем не понял: значит должны быть уязвимости, которые должны фиксится больше чем три года, причем их должно быть довольно много. Что это игра со статистикой? заказуха от микрософта?
                Есть в отчете такие уязвимости?

                Only users with full accounts can post comments. Log in, please.