The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Уязвимость в AMD SEV, позволяющая определить ключи шифрования

26.06.2019 10:21

Разработчики из команды Google Cloud выявили уязвимость (CVE-2019-9836) в реализации технологии AMD SEV (Secure Encrypted Virtualization), позволяющую скомпрометировать защищённые при помощи данной технологии данные. AMD SEV на аппаратном уровне обеспечивает прозрачное шифрование памяти виртуальных машин, при которой доступ к расшифрованным данным имеет только текущая гостевая система, а остальные виртуальные машины и гипервизор при попытке обращения к этой памяти получают зашифрованный набор данных.

Выявленная проблема позволяет полностью восстановить содержимое закрытого PDH-ключа, обрабатываемого на уровне отдельного защищённого процессора PSP (AMD Security Processor), недоступного для основной ОС. Имея PDH-ключ атакующий затем может восстановить сессионный ключ и секретную последовательность, заданную при создании виртуальной машины, и получить доступ к зашифрованным данным.

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

Защищённость протокола ECDH напрямую зависит от порядка генерируемой начальной точки кривой, дискретное логарифмирование которой представляет собой очень сложную задачу. На одном из шагов инициализации окружения AMD SEV в вычислениях с закрытым ключом используются параметры, полученные от пользователя. По сути выполняется операция умножения двух точек, одна из которых соответствует закрытому ключу. Если вторая точка относится к простым числам низкого порядка, то атакующий может определить параметры первой точки (биты модуля, используемого в операции возведения в степень по модулю) через перебор всех возможных значений. Для определения закрытого ключа подобранные фрагменты простых чисел затем могут быть собраны воедино при помощи Китайской теоремы об остатках.

Проблеме подвержены серверные платформы AMD EPYC, использующие прошивки SEV вплоть до версии 0.17 build 11. Компания AMD уже опубликовала обновление прошивки, в котором добавлена блокировка использования точек, не соответствующих кривой NIST. При этом ранее сгенерированные сертификаты для ключей PDH остаются валидными, что позволяет злоумышленнику провести атаку по миграции виртуальных машин из окружений, защищённых от уязвимости, в окружения, подверженные проблеме. Также упоминается возможность совершения атаки по откату версии прошивки на старый уязвимый выпуск, но данная возможность пока не подтверждена.

  1. Главная ссылка к новости (https://seclists.org/fulldiscl...)
  2. OpenNews: Найден метод обхода механизма защиты AMD Secure Encrypted Virtualization
  3. OpenNews: Компания AMD подтвердила наличие уязвимостей в своих чипах
  4. OpenNews: Уязвимость в процессорах AMD, позволяющая получить контроль над TPM-окружением
  5. OpenNews: Опубликована техника скрытия вредоносного кода в анклавах Intel SGX
  6. OpenNews: Уязвимость в чипах Qualcomm, позволяющая извлечь закрытые ключи из хранилища TrustZone
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50969-amd
Ключевые слова: amd, sev, crypt
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (48) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 11:02, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Только вчера подумал, AMD SEV ещё не взломали?
     
     
  • 2.7, ыы (?), 11:54, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +40 +/
    Не думай больше...ненадо...
     
  • 2.26, Дегенератор (ok), 17:25, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты подумал, а они уже исправили. Это не Интел с попытками подкупов исследователей.
     
     
  • 3.29, Генератор (?), 18:58, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    В интеле такой уязвимости быть не может потому что KISS.
     
     
  • 4.36, Аноним (36), 22:07, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Штеуд - KISS? #Ржунемогу
     
     
  • 5.47, Аноним (47), 20:54, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Там не просто KISS, а KISS MY ARSE
     

  • 1.2, Аноним (2), 11:04, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Пофиг, из нашей матрицы-песочницы в реальную Вселенную не выйдет.
     
     
     
    Часть нити удалена модератором

  • 3.15, Аноним (15), 13:33, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тогда всего выйдет
     
     
  • 4.16, Аноним (15), 13:33, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    *скорее всего
     
  • 3.37, Аноним (37), 23:08, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Вот и выросло поколение, которое не знает про матрицу, агента Смита и разницу между красной и синей таблетками.

    Зато знает про наркотики...

     
     
  • 4.45, Michael Shigorin (ok), 10:36, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ну так торчок же, ещё и без собственного имени.

    PS: но да, про intel и kiss там выше знатно позабавили -- хорошо хоть "генератор", а не "декодер"...

     

  • 1.3, Аноним (3), 11:14, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Прошивку уже обновили.
     
     
  • 2.23, Crazy Alex (ok), 14:26, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    а толку?
     
     
  • 3.50, анонимусище (?), 13:17, 28/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    со следующей агесой исправится же
     

  • 1.4, InuYasha (?), 11:18, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    "Ничего фатального, расходимся, здесь не на что смотреть..."
    В общем, проблема лишь в случае плохих входных данных от пользователя, так что, это такая себе "уязвимость".
     
     
  • 2.18, Аноним (18), 13:50, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +7 +/
    > В общем, проблема лишь в случае плохих входных данных от пользователя, так что, это такая себе "уязвимость".

    В данном случае "пользователем" может являться, например, хостер, от которого ты захотел что-то спрятать.

     
     
  • 3.32, InuYasha (?), 20:14, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> В общем, проблема лишь в случае плохих входных данных от пользователя, так что, это такая себе "уязвимость".
    > В данном случае "пользователем" может являться, например, хостер, от которого ты захотел
    > что-то спрятать.

    Т.е. root изначально не должен иметь возможность обладать этим ключом? Если так, то да, печаль.
    Но в любом случае, уже пропатчили.
    Гораздо интереснее было бы вытащить и изучить эту ПСП-прошивку...

     
  • 2.22, nrndda (ok), 14:20, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Не совсем так, а точнее совсем не так. При последовательных запусках виртуалок хакером, он может восстановить закрытый ключ, которым подписываются все виртуалки на хосте.  Это как если бы существовал мастер вход в ssh и при входе с одной из учёток можно было бы его восстановить.
    Спасает только то, что этот SEV мало кому интересен.
     
     
  • 3.33, InuYasha (?), 20:15, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Не совсем так, а точнее совсем не так. При последовательных запусках виртуалок
    > хакером, он может восстановить закрытый ключ, которым подписываются все виртуалки на
    > хосте.  Это как если бы существовал мастер вход в ssh
    > и при входе с одной из учёток можно было бы его
    > восстановить.
    > Спасает только то, что этот SEV мало кому интересен.

    Спасибо за пояснение.

     

  • 1.5, Аноним (5), 11:20, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Во время выполнения команды запуска защищённой виртуальной машины атакующий может отправить параметры кривой

    хм

     
     
  • 2.6, Andrey Mitrofanov_N0 (??), 11:42, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Во время выполнения команды запуска защищённой виртуальной машины атакующий может отправить параметры кривой
    > хм

    Вот так ещё лучще:

    "" A new security vulnerability has been made public over AMD's Secure Encrypted Virtualization (SEV) having insecure cryptographic implementations. ""

    Переводчики тут прост не смогли передать накал страстей --

    [U]   security vulnerability Secure Encrypted insecure cryptographic   [/U]

    -- , когда с фороникса тащили.  Намасливать масло маслом может лишь не только любой....  Диплом по специальности нужен.  По писательству, журналистике, маркетингу, болтологии.  Либо опыт работы на ринге?

     
     
  • 3.12, Аноним (12), 12:32, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Это только в русском языке паническая боязнь тавтологии, подкреплённая школьной муштрой. Англичане к этому проще относятся.

    >Диплом по специальности нужен.  По писательству, журналистике, маркетингу, болтологии.  Либо опыт работы на ринге?

    А ты сам, кстати, не цирковое училище заканчивал часом?

     
     
  • 4.13, mfa (?), 13:13, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "Англичане к этому проще относятся."
    англичане относятся проще ко всему кто/что не англичанен. тяжёлое прошлое нации связанное с норманнами...
     
  • 4.17, Andrey Mitrofanov_N0 (??), 13:50, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >не цирковое училище

    Конечно!

     
  • 4.30, анонн (?), 19:02, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это только в русском языке паническая боязнь тавтологии, подкреплённая школьной муштрой.
    > Англичане к этому проще относятся.

    Откуда дровишки? Школу тамошнюю оканчивал? И владение языком на уровне "native" есть?
    Или классическое опеннетное "я тут подумал и решил …"?

     

  • 1.8, Аноним (-), 12:11, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Братцы, переходим на telnet/http/irc/unencrypted?
     
     
  • 2.9, Аноним (9), 12:21, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Товарищ майор, а как же Магма, Стрибог и Кузнечик?
     

  • 1.11, Аноним (11), 12:24, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если у меня нет шифрования виртуальных машин, то мне ничего не угрожает? =)
    По дефолту же в квм не шифруется ничего?
     
     
  • 2.19, AnonPlus (?), 13:53, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А у тебя серверная платформа EPYC? Если нет, тогда глубоко пофиг, шифруешь ты или нет.
     
     
  • 3.20, Аноним (3), 14:06, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Так и в интеле есть дыры в шифровании озу
     
     
  • 4.42, хотел спросить (?), 03:45, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    у интел есть шифрование ОЗУ на уровне кирпича?

    для хость системы и для виртуалок?

     
     
  • 5.44, Аноним (44), 08:42, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    https://www.google.com/amp/s/amp.tomshardware.com/news/intel-mktme-amd-memory-

    https://en.m.wikipedia.org/wiki/Software_Guard_Extensions

     
     
  • 6.46, хотел спросить (?), 14:04, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > https://www.google.com/amp/s/amp.tomshardware.com/news/intel-mktme-amd-memory-
    > https://en.m.wikipedia.org/wiki/Software_Guard_Extensions

    Первая статья:
    Intel следует за лидерством AMD в полном шифровании памяти
    Это же вроде только планы ))

    Анклавы это другая история... Это же не сквозное шифрование.
    И кстати в анклавах вроде находили какую-то дыру.

     

  • 1.21, Аноним (21), 14:14, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    >при помощи Китайской теоремы об остатках.

    Все газеты завтра: "КИТАЙЦЫ ВЗЛОМАЛИ И КОНТРОЛИРУЮТ ВСЕ ПРОЦЕССОРЫ АМД"

     
  • 1.24, Аноним (-), 14:27, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    В OpenSSH добавлена защита от атак по сторонним каналам... (мастер-ключ в ОЗУ) это же совпадение, правда? правда?
     
     
  • 2.25, анон (?), 16:26, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > мастер-ключ в ОЗУ

    обычно он там лежать и должен для расшифровки, в зашифрованном блоке, чтобы никто его физически не достал.

     

  • 1.27, Гуг Хайль (?), 17:38, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    >на аппаратном уровне обеспечивает прозрачное шифрование памяти

    Прозрачные 7 нанометров?

     
  • 1.28, Аноним (28), 18:52, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >кривой NIST

    А у Curve25519 такие опасные точки есть?

     
     
  • 2.40, Ivan_83 (ok), 02:25, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    да
     

  • 1.31, Онаним (?), 19:21, 26/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Два главных пункта:
    1. Редко используемая фича
    2. Лечится прошивкой
    Любые дыры - это плохо, но здесь, к счастью, никаких потерь производительности, и аппаратных фиксов не требуется.
     
     
  • 2.34, анонимус (??), 20:21, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > 2. Лечится прошивкой

    Тут проблема в том, что SEV в том числе позиционируется как "SEV thus represents a new virtualization security paradigm that is particularly applicable to cloud  computing where  virtual  machines  need  not  fully  trust  the  hypervisor  and  administrator  of  their  host system."

    А поскольку уже изначально существовала уязвимая прошивка, то никаких гарантий теперь SEV фактически не дает. Ты же не знаешь, обновил прошивку хостер/облачный провайдер, или нет. И кто ему мешает её откатить? Поэтому тут на самом деле всего один пункт:

    > 1. Редко используемая фича

     
     
  • 3.35, Онаним (?), 21:12, 26/06/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А, хостер/"облачный провайдер" никогда не даёт никаких гарантий. Это надо просто за аксиому брать.
     
  • 3.38, me (??), 00:33, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Тем кто сидят в облаках еще больше пофигу, потому что все понимают что хостер вполне может скомпилировать qemu под Эльбрус-16С и отдавать x86 виртуалки с записью всей мякушки прямо на ноутбук Яровой.

    SEV интересна когда ты строишь on-prem, а там это вполне себе обновляется и работает дальше как должно.

     
  • 3.39, Аноним (39), 00:39, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > никаких гарантий теперь SEV фактически не дает

    А как ты изнутри виртуалки вообще узнаешь, используется SEV или нет? Всё равно приходится хостеру на слово верить.

     
     
  • 4.43, Онаним (?), 08:07, 27/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Узнать-то ещё можно, виртуалка участвует в генерации параметров. Но вот узнать, что это SEV, а не эмуляция такового... :)

    Короче дыра имеет место быть, но актуальна она в основном для тех, у кого очень жёсткие требования к безопасности, как правильно написали, on-premises, с целью защиты от проникновений со стороны хоста.

     

  • 1.41, Ivan_83 (ok), 02:29, 27/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Очередной RyzenFall - по факту газификация луж.
    Чтобы оно стало опасно нужно:
    - чтобы ты критически полагался на шифрование виртуалок
    - чтобы вертуалка нарочно сгенерировала плохой ключ
    - чтобы хост очень захотел почитать память виртуалки

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

     
  • 1.48, анонимка (?), 10:59, 28/06/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >при помощи Китайской теоремы об остатках.

    мало их Трамп прессует

     
     
  • 2.49, Andrey Mitrofanov_N0 (??), 11:03, 28/06/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >>при помощи Китайской теоремы об остатках.
    > мало их Трамп прессует

    Не напреследовал   на теорему имени себя  ?   Сла-бак!

    ///теперь "китайцы учат вьетнамцев в американских универах"?...

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру