Несколько дней назад мы писали о 0day Local Privilege Escalation (LPE) уязвимости в UEFI-прошивке ноутбуков Lenovo ThinkPad, которой было посвящено интересное исследование security-ресерчера под ником Cr4sh. Продемонстрированный вектор эксплуатации уязвимости позволяет отключить встроенную аппаратную защиту под названием SPI Protected Ranges, которая используется для защиты SPI flash-памяти чипа от записи данных. Сама уязвимость присутствует в одном из UEFI-драйверов прошивки под названием SystemSmmRuntimeRt и позволяет исполнить произвольный привилегированный SMM-код в системе.



В свою очередь, Lenovo выпустила уведомление безопасности, в котором указала, что не занималась разработкой уязвимого драйвера, так как обращается за этим к производителям прошивок BIOS/UEFI, которые, в свою очередь, используют наработки Intel и AMD. После этого стало понятно, что спектр ноутбуков и компьютеров, уязвимых для ThinkPwn, не ограничивается компанией Lenovo. Хотя кроме Lenovo никто из производителей компьютеров и материнских плат не обмолвился об этой уязвимости, стало известно что ей подвержены ноутбуки Hewlett-Packard Pavilion, компьютеры с материнскими платами от GIGABYTE (Z68-UD3H, Z77X-UD5H, Z87MX-D3H, и др), ноутбуки Fujitsu LIFEBOOK, а также Dell.


Рис. Декомпилированный код уязвимого драйвера из flash-памяти чипа материнской платы Gigabyte Z68-UD3H. (твиттер Cr4sh)


Рис. Демонстрация успешной работы эксплойта на ноутбуке Dell Latitude E6430.

Уязвимость ThinkPwn была исправлена Intel еще в 2014 году, однако, производители UEFI до сих пор используют уязвимую версию драйвера при производстве прошивок. Полный масштаб охвата данной уязвимостью компьютеров пока не совсем ясен, так как никто из поставщиков UEFI не прокомментировал данную ситуацию. Очевидно, что речь идет о существенном количестве различных моделей компьютеров разных производителей, среди которых, Lenovo, Hewlett-Packard, GIGABYTE, Fujitsu, и Dell.

Как мы уже указывали ранее, эксплойт ThinkPwn использует 0day уязвимость в SystemSmmRuntimeRt для исполнения своего SMM-кода, который помогает эксплойту обойти защитную меру SMM LockBox, используемую для обеспечения безопасности системной структуры UEFI Boot Script Table. Данная структура является ключевой для сброса регистров SPI Protected Range при эксплуатации режима работы компьютера S3 sleep. Путем модификации полей структуры, которые отвечают за сохранность регистров SPI Protected Range, SMM-кодом, можно добиться последующей их загрузки нулевыми значениями в сами регистры SPI.

ThinkPwn позволяет отключить защиту на запись SPI flash-память чипа, что позволяет атакующим встроить туда свой backdoor или руткит для компрометации работы любой ОС на самом низком уровне. Это, в свою очередь, может привести к обходу технологии безопасной загрузки Secure Boot или таких аутентичных технологий как Virtual Secure Mode и Credential Guard на Windows 10.
Поделиться с друзьями
-->

Комментарии (36)


  1. Ivan_83
    07.07.2016 23:54

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


    1. d_olex
      08.07.2016 08:40
      +8

      Причем здесь юзеры, они и так могут делать на своих компах что захотят используя аппаратный программатор. Данная уязвимость позволяет обойти flash write protection, это в свою очередь позволяет создать вредоносный код который будет заражать firmware что даст ему возможность выживать при переустановке ОС и замене жестких дисков.


      1. horlon
        08.07.2016 10:36

        Давно пора отказаться от перепрошиваемых компонентов в компьютерах вместо них создать стандартный минимальный функционал.


        1. d_olex
          08.07.2016 12:40
          +1

          В случае с железом существующим в настоящий момент это нереально от слова совсем. Большие машины (сервера, рабочие станции, лептопы) это очень сложные штуки для инициализации которых нужен очень сложный код который не может быть частью ОС. Объем кодовой базы сферической UEFI совместимой прошивки от современной машины сравним с объемом кода ядра Linux, в таком проекте просто по-определению будут баги связанные с нарушением стабильности или производительности работы которые производителю нужно уметь фиксить уже после выхода продукта на рынок.
          That's why we can't have a nice things.


          1. horlon
            08.07.2016 13:46

            Это не правда. В случае с CPU прошивку не перезаливают в процессор, а используют микрокод, который заливают в BIOS или ОС. Не знаю как обстоят дела сейчас, но раньше Linux использовал BIOS только для загрузки и микрокод, который был в BIOS не работал. Всеравно используются драйвера — все можно залить в них.


            1. d_olex
              08.07.2016 13:51
              +1

              > Это не правда.

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


            1. d_olex
              08.07.2016 13:57
              +1

              > Всеравно используются драйвера — все можно залить в них.

              Прям сплю и вижу драйвер уровня ОС который инициализирует контроллер памяти или, там, PCI-e шину. Что бы возможность загрузить ОС вообще была — нужно провернуть чертову гору различных телодвижений по низкоуровневой инициализации оборудования.


            1. MacIn
              08.07.2016 19:26
              +1

              но раньше Linux использовал BIOS только для загрузки

              Ага. Всего-то.
              «Загрузка» это длиннющий и сложный процесс, за которым скрывается… всё — вся инициализация оборудования. Сервис для чтения, которым пользуется загрузчик — это по сути уже драйвер жесткого диска. А если он на PCI шине, если это SATA…


        1. ValdikSS
          08.07.2016 16:41

          Так делают во всяких ARM, где все нужно инициализировать из загрузчика, например, u-boot, и это отвратительно.


          1. horlon
            08.07.2016 19:43

            Согласен. ARM — это совершенно другой случай. Мне нравится концепцыя RISK, но ARM совершенно не тот случай — этот процессор перепрошиваемый, а это уже не то о чем я говорю. Перепрошиваемый процессор для меня это не процессор, а контроллер… Мало того от RISK в этом процессоре почти ничего не осталось.


      1. Ivan_83
        08.07.2016 10:39

        Я смотрю на это как на джелбрейк у фуфлонов: когда с помощью софта можно получить полный контроль над железом.
        В данном случае владельцам ноутов у которых отключены какие то процовые фичи типа AES-NI не придётся разбирать ноут и возится с программатором.

        Секурбут мне нафик не нужен.
        Технологии безопасности венды, ровно как и интела идут в одном направлении: аппаратная защита для DRM.

        Вредоносный код который будет выживать — его же обычно для венды делают и NTFS, сделать для зоопарка BSD и зоопарка файловых систем и упихать в жалкие пару мб это ещё постараться надо и не факт что получится.


        1. d_olex
          08.07.2016 13:08
          +1

          > В данном случае владельцам ноутов у которых отключены какие то процовые фичи типа AES-NI не придётся разбирать ноут и возится с программатором.

          Вообще-то перешить флэш программатором таки на порядки проще чем взять 0day/1day уязвимость в прошивке, написать для нее полнофункциональный эксплойт и отладить его на своей конкретной железке.

          > Вредоносный код который будет выживать — его же обычно для венды делают и NTFS

          Его делают под конкретный кейс, firmware руткиты это NSA-level штуки для целевых атак, а не мейнстримная технология которая используется в говномалваре массового распространения.


          1. Ivan_83
            08.07.2016 13:43
            +1

            UEFI же типа стандартная хрень, всунуть туда ещё один стандартный модуль с нужным функционалом через эту дырку.

            «Большие машины (сервера, рабочие станции, лептопы) это очень сложные штуки для инициализации которых нужен очень сложный код который не может быть частью ОС. Объем кодовой базы сферической UEFI совместимой прошивки от современной машины сравним с объемом кода ядра Linux»
            Где тут меня пытаются обмануть.
            1. Раньше эти «очень сложные» хрени инитил биос в пару мегабайт максимум, обычно от 512 кбайт.
            2. С тех пор там ничего кардинально не изменилось (за 8 лет или менее)
            3. В ядре линуха 100500 разных дров под 10005000 разных железок, притом что платформы на которых UEFI не отличаются большим разнообразием.


            1. d_olex
              08.07.2016 13:49
              +1

              > UEFI же типа стандартная хрень, всунуть туда ещё один стандартный модуль с нужным функционалом через эту дырку.

              Ну вот «всуньте» и расскажите насколько легко вам это далось.

              > Раньше эти «очень сложные» хрени инитил биос в пару мегабайт максимум

              Во времена Pentium Pro, ага.

              > С тех пор там ничего кардинально не изменилось

              Сool story, bro.


              1. Ivan_83
                08.07.2016 15:07

                Кто бы это профинансировал, я бы занялся.

                Со времён как минимум коредуо, матери к которому я брал в 2008, 2010 годах.
                Вот со времён коредуо в железе кардинальных изменений не было.


                1. d_olex
                  08.07.2016 15:37
                  +1

                  Глупости говорите, вот список фич которых не было в core duo образца конца 00-х с которыми я сталкивался лично: IOMMU, EPT, STM, SGX. Сюда же плюсуйте существенно перепиленную ME подсистему, штуки вроде quad-channel DDR4, PCI-e старше 3-й версии и xHCI. Все это в сумме тянет на ОФИГЕТЬ какие серьезные изменения, и это только то, что с ходу в голову пришло.


                  1. Ivan_83
                    08.07.2016 19:16
                    +2

                    IOMMU был у амд уже давно.
                    EPT, STM — хз что такое.
                    SGX — это же вроде изолированные анклавы памяти для приложений, биосу оно побоку.
                    ME подсистема вообще почти никому не нужна, а на амд её нет.
                    Контроллер ддр4 вроде же в проце, думаю много кода для инита ему не надо, ровно как и PCI-e.
                    xHCI он не сильно то от ECHI отличается, и для него обычно свой «микробиос», как и для всяких сетевух.

                    Кроме того UEFI же вообще позволяет не инить целую кучу всего для фастбута.

                    Пора уже признать что UEFI это говнокод от МС и сочувствующих, ничего нужного пользователю это не дало.
                    Отказ от CMOS для хранения настроек — заговор производителей с целью добавления закладки для ограничения времени жизни плат.
                    Плюс они создали платформу для DRM основанную на железе.
                    Плюс туда можно теперь пихать всякий шпионский софт.

                    Юзеру было вполне достаточно обычного биоса и перемычки запрещающей перепрограммирование.

                    Сейчас вполне очевидно что х86 и венда катятся на деньги юзеров и волею монополистов (интел + мс) в мир где комп будет контролироваться корпорациями и копирастами а юзер будет дойной коровой.


                    1. d_olex
                      08.07.2016 23:22

                      > EPT, STM — хз что такое.

                      Дальше не читал.


      1. sasha4043
        08.07.2016 10:50

        Плюсую


  1. lola_term
    08.07.2016 13:19

    Когда мы уже дождемся open source биос который можно было бы билдить на любой ноут/пк?
    Думаю многим уже надоели эти legacy/secure уефи и ефи которые не защищают, калечат, деградируют и запрещают использование половины настроек, через которые производители железки могут удаленно управлять вашим пк/настройками через интел амт и др фичи.
    Которые мне нафиг не нужны, можно было бы отключить на уровне биоса. Пример если вы покупаете ноутбук lenovo лицензированным на win с дискретной видеокартой, установив отличную операционную систему вы не сможете использовать дискретную карточку (!) так как ее блокируют на уровне биоса, а доступ к настройкам Advanced не даетсяz, а так же отключается функция быстрой зарядки ноутбука при работе, только поддержка питания. приходится выключать ставить на зарядку и ждать несколько часов. Вот вам корпорации.


    1. xvilka
      08.07.2016 13:38

      1. lola_term
        08.07.2016 14:46

        оно не встанет куда попало, надо поддерживаемую модель и много проблем кирпичных…


        1. bigfatbrowncat
          09.07.2016 01:54

          Так начинались все open-source — проекты. Это можно было сказать когда-то про Linux, сейчас — про ReactOS, например…


      1. CodeRush
        09.07.2016 00:23

        После того, как SAGE загнулась, я очень переживаю за судьбу этого во всех отношениях замечательного проекта. Когда-то давно некие люди из AMD обещали нам клятвенно поддержку coreboot в каждом релизе AGESA. Где она теперь…


    1. Konachan700
      08.07.2016 14:34

      Но это рынок… Попытка делать открытые доки да код на все то железо, что производится сейчас, приведет к удорожанию этого железа. Хорошему такому удорожанию, потому как многая пропиетарщина закрыта не по причине каких-то инноваций в ней, а потому, что код некачественный, содержит тонны легаси и местами откровенно краденый с открытых проектов. Чтобы это перелопатить и переписать, надо угрохать много человекочасов, что адски дорого. Выдать же то, что есть, будет сильным ударом по репутации компаний, да и откроет невиданные количества уязвимостей, закрывать которые тоже накладно, а часто и невозможно. Документация, отвязанная от коммерческой тайны и понятная потребителю, тоже стоит приличных денег. Плюс код пишет не одна контора, а много, отсюда будут лицензионные ограничения, которые тоже не всегда можно обойти.
      Но кому открытость платформы нужна? Паре тысяч гиков, которым хочется контролировать всё? Потому и нет ничего. Злого умысла в ситуации нет, есть лишь обычный расчет коммерческой выгоды. Когда броадкому надо было пустить в массы малину (то есть продать чипы), без проблем открыли всё, что нужно.


      1. xvilka
        08.07.2016 14:47

        Уже есть инициатива OpenPOWER.


      1. d_olex
        08.07.2016 15:00
        +1

        > откроет невиданные количества уязвимостей

        Распространенное заблуждение среди людей которые не занимаются поиском уязвимостей :) Не думаю что наличие сорцов от Lenovo помогло бы мне найти ThinkPwn прям реально существенно быстрее, UEFI совместимые прошивки вообще одна из самых дружественных для реверс-инжиниринга бинарных штук с которыми мне доводилось работать.


        1. CodeRush
          09.07.2016 00:26

          Не, Дим, по исходнику все же искать проще, поверь моему опыту. :) Если знать, что искать, на обнаружение совсем уж вопиющих случаев вроде твоего уйдет меньше пары минут, ибо синхронные SMI — все-таки пока еще звери довольно редкие, а во времена EDK1+ — вообще штук 5 на всю прошивку.


          1. d_olex
            09.07.2016 05:53

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


      1. d_olex
        08.07.2016 15:07
        +1

        > откровенно краденый с открытых проектов

        В контексте firmware для Intel совместимых машин это вообще глупость. Из каких таких open source проектов могут красть код в AMI/Phoenix/Insyde, из coreboot? Не смешите мои тапки.


        1. CodeRush
          09.07.2016 00:26

          Из TianoCore, очевидно же. ;)


          1. d_olex
            09.07.2016 06:06
            +1

            Это годное, общественно полезное воровство :)


  1. lola_term
    08.07.2016 13:27
    -1

    То же самое происходит при замене поврежденной материнской платы, которая с завода Foxconn стоит 200-250$ при чем не себестоимость, а сервисный центр толкает ее вам за 40к ~~630$ без процессора и тд, просто материнка с интегрированным видео стоимостью чипа в 30-50$. Я раньше любил брендовую качественную технику леновы, после такого я как пользователь люто ненавижу их, и считаю что переплатил достаточно денег просто за бренд, а не качество, хотя мне нужно было обратное. Новое время и веяния совсем растлевают умы производителей. Уефи еще не конец…


  1. CodeRush
    09.07.2016 00:15
    +2

    Ученый в очередной раз изнасиловал журналиста, к сожалению.
    Я не спорю, что баг серьезный, и этот конкретный баг — только первая ласточка среди всех проблем с синхронными SMI, которые ждут своего часа. Дело в том, что, как и в свое время а ассинхронными SMI, никто из разработчиков технологии не воспринимал её как вектор атаки, и потому ревью кода обработчиков синхронных SMI практически не проводилось, ибо все считали, что вызвать эти самые обработчики атакующий не сможет, он ведь не знает нужного хендла (SmmBase->Communicate) или GUIDа (SmmCommunicate->Communicate), и формат буфера ему тоже неизвестен, да и вообще, кому это надо все. А потом пришел Дима и не просто все сломал, а еще и выложил все карты на стол.
    Но вернемся к изнасилованию: в нынешнем виде эксплоит является приложением для UEFI shell, т.е. этот шелл нужно еще запустить как-то, т.е. нужен физический доступ к машине и отключенный SecureBoot (привет коментаторам, которые его костерят). Чтобы обойти это ограничение, нужна собственная реализация Communicate, которая тоже будет работать только из UEFI OS (для legacy OS обработчики синхронных SMI диспетчером не вызываются вообще, такая своеобразная защита от дурака). Сделать это можно, и я не сомневаюсь ни на секунду, что Дима это рано или поздно сделает, но сейчас поводов для паники нет никаких.
    Более того, на платах Gigabyte, Asrock, ASUS, и прочих десктопных платах такого рода этот конкретный эксплоит вообще не имеет значения, ибо там можно достичь того же эффекта (получить полный доступ к SPI flash) значительно более простыми способами, так что эксплоит, даже если он на этих устаревших платах и работает, опасности для них не представляет, ибо нет смысла просачиваться через вентиляцию, когда у тебя либо двери вообще нет, либо ключ от нее — под ковриком.
    Отдельно хочу возразить людям, которые в очередной раз убеждают меня в том, что современное железо буквально само инициализируется и там хватит микрокода на пару килобайт, а остальное все Великий и Открытый Линукс сделает за нас. Почти год, ребята. Почти год своей жизни, работая 40 часов в неделю, я потратил на то, чтобы довести плату conga-TR3 из состояния голое мертвое железо до состояния прошла все тесты и готова к массовому производству, имея при этом всю документацию, референсную реализацию UEFI и поддержку со стороны AMI и AMD. Если вы можете сделать то же самое хотя бы за полгода — подавайте резюме в любую компанию, Apple/Microsoft/Dell/HP/Lenovo/etc, любую — и вас там оторвут с руками, предложив не меньше $200к в год, релокацию, жилье, шахматы и поэтесс. И напишите мне оттуда потом, чтобы я еще сильнее загрустил, что тормоз такой.


    1. monah_tuk
      11.07.2016 13:40
      +1

      Кто бы оплатил эти полгода :)


      ЗЫ это я не к спору, что всё просто… взять простой ADV7619, взять документацию, а потом материться: оказывается нужно ещё такой-то AppNote найти — там есть список магических констант для программирования регистров, причём для трех режимов: UHD, HD и SD — он разный. Случайно найти на форуме, что одна буковка на корпусе чипа может многое сказать о поддержке HDCP, причём если вдруг откуда-то он возьмётся — чип через документированный регистр для этого вам ничего не скажет… Короче, спеки тоже людьми пишутся, и хардвар тоже глючить может — он тоже, внезапно, людьми разрабатывается.


      1. CodeRush
        11.07.2016 14:41

        И это только один чип, а не SoC с десятком встроенных устройств, двумя IOAPIC, IOMMU, контролером DDR4, который инициализирует встроенное ARM-ядро PMU с закрытой и подписанной прошивкой, с мостом PCI2PCI на каждой внешней PCIe-линии, и так далее, и тому подобное…
        По поводу оплаты — Ланиту, я слышал, очень нужны сейчас специалисты по прошивкам, UEFI, U-boot'у и вот этому всему.