Intel TDX / AMD SEV. использование защищённых анклавов для прятания от аверов?

[Dread Pirate Roberts]

есть такие интересные технологии, как Intel TDX https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
или AMD SEV https://www.amd.com/en/developer/sev.html
или заброшенный Intel SGX.

эти технологии предназначены для создания защищённых анклавов в оперативной памяти компьютера, куда не может залезть никто, кроме владельца/создателя анклава. технологии ориентированы на сферу веб-хостинга, а именно - создание виртуальных машин с зашифрованной оперативной памятью (в анклаве хранится только ключ шифрования, потому что объём анклава очень маленький)
теоретически, гипервизор с включённым TDX/SEV не сможет получить данные внутри виртуальной машины. то есть хостер не сможет украсть данные клиента, купившего у этого хостера VDS.
а теперь посмотрим на это с другой стороны: получается, что SEV/TDX/SGX - это восхитительная технология для прятания всякого добра, потому что никакой антивиндус не сможет залезть внутрь защищённого анклава. конечно, всякие шкафчики, стилеры и HVNC работать не будут, потому что из анклава не вылезти в хостовую систему, но для софта, которому хостовая система не нужна - типа сокс или дудос ботов - это идеальное место жительства.

дискасс.
Последнее редактирование: 11.09.2023

 

[Dread Pirate Roberts]

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

 

[coder]

coder сказал(а):
Даже если ты спрячешь что то в анклаве, полезная нагрузка всё равно должна будет в том или ином виде существовать на машине, чтобы реализовать анклав

coder сказал(а):
Ну хз, чего мы добьёмся этим, спасёт разве что от мемдетектов того что будет крутиться в анклаве, не более

естественно. но на функцию создания анклава ни один авер не заикнётся, в отличие от обычных функций всякой малвари.

бесконечно живущих ботов?

 

[Dread Pirate Roberts]

Dread Pirate Roberts сказал(а):
естественно. но на функцию создания анклава ни один авер не заикнётся, в отличие от обычных функций всякой малвари.

бесконечно живущих ботов?

Пожалуйста, обратите внимание, что пользователь заблокирован

Нет. Нагрузку должно что-то исполнять в контексте анклава, как и любой другой код, её нужно будет криптовать, я профита не вижу в этом. Я говорю про софтварный анклав, хардварный анклав ты не сможешь реализовать на большой выборке в связи с тем что технология очень новая и "старое" железо её не поддерживает, ну и направлена она на серверные решения, а не на домашние.

 

[DildoFagins]

coder сказал(а):
её нужно будет криптовать

зачем? в том-то и прикол, что не надо ничего криптовать - внутри защищённой виртуальной машины нет антивиндуса, и снаружи он никак не узнает, что там запущено внутри.

 

[Dread Pirate Roberts]

Dread Pirate Roberts сказал(а):
внутри защищённой виртуальной машины нет антивиндуса

Внутри защищенной "виртуальной машины" нет сисколлов, для взаимодействия со внешним миром нужен код вне анклава.

 

[DildoFagins]

DildoFagins сказал(а):
Внутри защищенной "виртуальной машины" нет сисколлов, для взаимодействия со внешним миром нужен код вне анклава.

если создать не просто мини-хранилище для данных с помощью SGX, а полноценную виртуальную машину с помощью TDX, то там целую операционную систему запустить можно.

короче, нужен кто-то, кто уже работал с этими технологиями, и может объяснить на пальцах, как они работают, а особенно как работает сеть (между хостом и гостем и между гостем и миром).
Последнее редактирование: 24.09.2023

 

[Dread Pirate Roberts]

coder сказал(а):
софтварный анклав

Правильно ли я понимаю что речь о enclaveapi.h? Встроенном апи для винды

 

[coree]

coree сказал(а):
Правильно ли я понимаю что речь о enclaveapi.h? Встроенном апи для винды

Пожалуйста, обратите внимание, что пользователь заблокирован

Я говорил о реализации софтварного анклава, которая описывалась инди. В реализацию на винапи я не вникал, по ней инчего сказать не могу

 

[coder]

Dread Pirate Roberts сказал(а):
there are such interesting technologies as Intel TDX https://www.intel.com/content/www/u.../technical/intel-trust-domain-extensions.html
or AMD SEV https://www.amd.com/en/developer/sev.html
or the abandoned Intel SGX.

These technologies are designed to create secure enclaves in the computer's RAM, which no one except the owner/creator of the enclave can access. technologies are focused on the web hosting industry, namely the creation of virtual machines with encrypted RAM (only the encryption key is stored in the enclave, because the volume of the enclave is very small)
theoretically, a hypervisor with TDX/SEV enabled will not be able to receive data inside the virtual machine. that is, the hoster will not be able to steal the data of a client who purchased a VDS from this hoster.
and now let's look at it from the other side: it turns out that SEV/TDX/SGX is an amazing technology for hiding all sorts of goodness, because no anti-Windows can get inside a protected enclave. Of course, all sorts of lockers, stealers and HVNC will not work, because you cannot get out of the enclave into the host system, but for software that does not need a host system - such as Sox or Dudos bots - this is an ideal place of residence.

discass.
Нажмите, чтобы раскрыть...

socks? the code would still need to get out of the enclave and perform syscalls for those socket operations.
best they can do is hide the `setup` (eg the protocol) inside the encrypted memory, but at the end of the day, everything will be out in the open once it interacts with the OS syscalls.

from my understanding, these technologies are only useful to add safeguards on specific pieces of the code which people may consider sensitive, sort of like using code virtualization techniques, but on another level.

 

[SadisticApe]

SadisticApe сказал(а):
socks? the code would still need to get out of the enclave and perform syscalls for those socket operations.
best they can do is hide the `setup` (eg the protocol) inside the encrypted memory, but at the end of the day, everything will be out in the open once it interacts with the OS syscalls.

from my understanding, these technologies are only useful to add safeguards on specific pieces of the code which people may consider sensitive, sort of like using code virtualization techniques, but on another level.

you did not get it: we could create a virtual machine with a completely different operating system inside, and hide its memory from the host operating system using SEV/TDX.
the software inside the virtualized OS will use syscalls of the virtualized OS, not of the host OS; the host OS will see only virtualization syscalls, 100% legit and clean for antiviruses. of course the AVs will also see the network communication, but if the target domains/IPs are clean then AVs will not react.

 

[Dread Pirate Roberts]

Customers of cloud services have to trust the cloud providers, as they control the building blocks that form the cloud. This includes the hypervisor enabling the sharing of a single hardware platform among multiple tenants. AMD Secure Encrypted Virtualization (SEV) claims a new level of protection in cloud scenarios. AMD SEV encrypts the main memory of virtual machines with VM-specific keys, thereby denying the higher-privileged hypervisor access to a guest's memory. To enable the cloud customer to verify the correct deployment of his virtual machine, SEV additionally introduces a remote attestation protocol.This paper analyzes the firmware components that implement the SEV remote attestation protocol on the current AMD Epyc Naples CPU series. We demonstrate that it is possible to extract critical CPU-specific keys that are fundamental for the security of the remote attestation protocol.Building on the extracted keys, we propose attacks that allow a malicious cloud provider a complete circumvention of the SEV protection mechanisms. Although the underlying firmware issues were already fixed by AMD, we show that the current series of AMD Epyc CPUs, i.e., the Naples series, does not prevent the installation of previous firmware versions. We show that the severity of our proposed attacks is very high as no purely software-based mitigations are possible. This effectively renders the SEV technology on current AMD Epyc CPUs useless when confronted with an untrusted cloud provider. To overcome these issues, we also propose robust changes to the SEV design that allow future generations of the SEV technology to mitigate the proposed attacks.

[1908.11680] Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation
"Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation"

 

[Dread Pirate Roberts]

Dread Pirate Roberts сказал(а):
[1908.11680] Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation
"Insecure Until Proven Updated: Analyzing AMD SEV's Remote Attestation"

thanks for the info ^_^ i really enjoyed reading this...keep on <3

 

[coder]

Dread Pirate Roberts сказал(а):
это идеальное место жительства

Это все хорошо звучит на бумаге, но во-первых нужна поддержка на аппаратном уровне (как для SGX, так для VBS анклавов, если мы говорим о венде, как о хосте), а во-вторых даже в аппаратной реализации бывают уязвимости, для примера (я нихера из этого не понял, но уязвимости - это в принципе неизбежно): https://arstechnica.com/information...me-intel-cpus-is-more-bad-news-for-sgx-users/

 

[Dread Pirate Roberts]

Исследователи Центра Гельмгольца по информационной безопасности (CISPA) опубликовали новый метод атаки CacheWarp, позволяющий скомпрометировать механизм защиты AMD SEV (Secure Encrypted Virtualization), применяемый в системах виртуализации для защиты виртуальных машин от вмешательства со стороны гипервизора или администратора хост-системы. Предложенный метод позволяет злоумышленнику, имеющему доступ к гипервизору, добиться выполнения стороннего кода и повышения привилегий в виртуальной машине, защищённой при помощи AMD SEV.
Атака основана на использовании уязвимости (CVE-2023-20592), вызванной некорректной работой с кэшем во время выполнения процессорной инструкции INVD, при помощи которой можно добиться рассогласования данных в памяти и кэше, и обойти механизмы поддержания целостности памяти виртуальных машин, реализованные на базе расширений SEV-ES и SEV-SNP. Уязвимость затрагивает процессоры AMD EPYC с первого по третье поколения.

Для проверки своих систем на наличие уязвимости опубликован прототип эксплоита, позволяющий выполнить подстановку исключения в виртуальную машину, защищённую через AMD SEV, и откатить в старое состояние несброшенные в память изменения в VM. Откат изменения может быть использован для изменения хода выполнения программы через возвращение старого адреса возврата в стеке или для использования при входе параметров старого сеанса, для которого ранее была выполнена аутентификация, через возвращение значения признака аутентификации.
Например, исследователями продемонстрирована возможность применения метода CacheWarp для совершения атаки Bellcore на реализацию алгоритма RSA-CRT в библиотеке ipp-crypto, позволившей восстановить закрытый ключ через подстановку ошибок при вычислении цифровой подписи. Также показано как можно подменить параметры проверки сеанса к OpenSSH при удалённом подключении к гостевой системе, а затем изменить состояние проверки при выполнении утилиты sudo для получения прав root в Ubuntu 20.04. Работа эксплоита проверена на системах с процессорами AMD EPYC 7252, 7313P и 7443.

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


...