{"id":160597,"date":"2026-02-11T17:11:57","date_gmt":"2026-02-11T15:11:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx"},"modified":"2026-02-11T17:11:57","modified_gmt":"2026-02-11T15:11:57","slug":"uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/uyazvimost-pozvolyayushhaya-obojti-mehanizm-zashhity-intel-tdx","title":{"rendered":"Vulnerability allowing bypass of Intel TDX protection mechanism","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Firmy Google i Intel ujawni\u0142y wyniki wsp\u00f3lnej pracy nad audytem bezpiecze\u0144stwa mechanizmu Intel TDX 1.5 (Trusted Domain Extensions). Technologia Intel TDX umo\u017cliwia szyfrowanie pami\u0119ci maszyn wirtualnych, aby chroni\u0107 je przed ingerencj\u0105 i analiz\u0105 ze strony administrator\u00f3w systemu hosta oraz fizycznymi atakami na sprz\u0119t. W wyniku audytu zidentyfikowano 6 luk bezpiecze\u0144stwa oraz 35 b\u0142\u0119d\u00f3w, kt\u00f3re nie wp\u0142ywaj\u0105 na bezpiecze\u0144stwo. <\/p>\n

Problemy dotycz\u0105 procesor\u00f3w Intel Xeon 6, a tak\u017ce czwartej i pi\u0105tej generacji procesor\u00f3w Intel Xeon Scalable. Luki bezpiecze\u0144stwa zosta\u0142y naprawione wczorajsz\u0105 aktualizacj\u0105 mikrokodu. Na GitHubie opublikowano narz\u0119dzia do eksploatacji luk w Intel TDX oraz prototypy exploit\u00f3w dla dw\u00f3ch luk (CVE-2025-30513, CVE-2025-32007). <\/p>\n

Najbardziej niebezpieczna luka (CVE-2025-30513) umo\u017cliwia niegodnemu zaufania administratorowi z dost\u0119pem do systemu hosta uzyskanie podwy\u017cszonych uprawnie\u0144 i ca\u0142kowite skompromitowanie gwarancji bezpiecze\u0144stwa oferowanych przez technologi\u0119 Intel TDX. Luka ta jest spowodowana wy\u015bcigiem warunk\u00f3w w jednym z modu\u0142\u00f3w TDX, co pozwala w momencie migracji maszyny wirtualnej przenie\u015b\u0107 chronione \u015brodowisko (TD \u2014 Trusted Domain) ze stanu wspieraj\u0105cego migracj\u0119 do stanu, kt\u00f3ry dopuszcza przej\u015bcie w tryb debugowania. <\/p>\n

Problem wynika z mo\u017cliwo\u015bci podmiany atrybut\u00f3w \u015brodowiska w chwili po ich weryfikacji, ale przed ich przekszta\u0142ceniem w stan niezmienny w przeniesionym \u015brodowisku. Po ustawieniu atrybutu debugowania administrator systemu hosta mo\u017ce w czasie rzeczywistym \u015bledzi\u0107 aktywno\u015b\u0107 chronionego systemu go\u015bcia i uzyska\u0107 dost\u0119p do odszyfrowanego stanu pami\u0119ci. <\/p>\n

Luka jest do\u015b\u0107 prosta w eksploatacji, poniewa\u017c administrator w ka\u017cdej chwili mo\u017ce zainicjowa\u0107 proces live-migracji chronionej maszyny wirtualnej. Problem zosta\u0142 odkryty przez badaczy z firmy Google, kt\u00f3rzy podczas badania API zwr\u00f3cili uwag\u0119 na rozbie\u017cno\u015b\u0107 mi\u0119dzy tym, jak w FSM (Finite State Machine) \u015bledzony jest stan operacji, jak przetwarzane jest przerwanie operacji importu oraz jak zmienia si\u0119, ale nie wraca do pierwotnego stanu po awarii, stan chronionego \u015brodowiska. <\/p>\n

Mniej niebezpieczne luki: <\/p>\n