Luka Reptar wpływająca na procesory Intel

Tavis Ormandy, badacz bezpieczeństwa w Google, zidentyfikował nową lukę (CVE-2023-23583) w procesorach Intela o kryptonimie Reptar, która stwarza głównie zagrożenie dla systemów chmurowych, w których działają maszyny wirtualne różnych użytkowników. Luka umożliwia zawieszenie się lub awarię systemu w przypadku wykonywania pewnych operacji na nieuprzywilejowanych systemach-gościach. Aby przetestować systemy, opublikowano narzędzie, które stwarza warunki do ujawnienia się luk.

Teoretycznie lukę można wykorzystać do eskalacji uprawnień z trzeciego do zerowego pierścienia ochronnego (CPL0) i ucieczki z izolowanych środowisk, jednak scenariusz ten nie został jeszcze potwierdzony w praktyce ze względu na trudności w debugowaniu na poziomie mikroarchitektury. Wewnętrzna analiza przeprowadzona w firmie Intel wykazała również możliwość wykorzystania tej luki w celu eskalacji uprawnień pod pewnymi warunkami.

Według badacza luka występuje w rodzinach procesorów Intel Ice Lake, Rocket Lake, Tiger Lake, Raptor Lake, Alder Lake i Sapphire Rapids. W raporcie Intela wspomina się, że problem pojawia się począwszy od 10. generacji (Ice Lake) procesorów Intel Core i trzeciej generacji procesorów Xeon Scalable, a także w procesorach Xeon E/D/W (Ice Lake, Skylake, Haswell, Broadwell , Skylake, Sapphire Rapids, Emerald Rapids, Cascade Lake, Cooper Lake, Comet Lake, Rocket Lake) i Atom (Apollo Lake, Jasper Lake, Arizona Beach, Alder Lake, Parker Ridge, Snow Ridge, Elkhart Lake i Denverton). Luka, o której mowa, została naprawiona we wczorajszej aktualizacji mikrokodu 20231114.

Luka wynika z faktu, że w pewnych okolicznościach mikroarchitektonicznych wykonanie instrukcji „REP MOVSB” jest kodowane z nadmiernym przedrostkiem „REX”, co prowadzi do niezdefiniowanego zachowania. Problem został wykryty podczas testowania zbędnych prefiksów, które w teorii powinny być ignorowane, ale w praktyce prowadziły do ​​dziwnych efektów, takich jak ignorowanie bezwarunkowych gałęzi i przerywanie zapisywania wskaźników w instrukcjach xsave i call. Dalsza analiza wykazała, że ​​dodanie redundantnego przedrostka do instrukcji „REP MOVSB” powoduje uszkodzenie zawartości bufora ROB (ReOrder Buffer) służącego do porządkowania instrukcji.

Uważa się, że błąd wynika z nieprawidłowego obliczenia rozmiaru instrukcji „MOVSB”, co prowadzi do naruszenia adresowania instrukcji zapisywanych do bufora ROB po MOVSB ​​z nadmiernym przedrostkiem i przesunięciem wskaźnika instrukcji. Taka desynchronizacja może ograniczać się do zakłócenia obliczeń pośrednich i późniejszego przywrócenia stanu całkowego. Jeśli jednak jednocześnie ulegnie awarii wiele rdzeni lub wątków SMT, możesz uszkodzić stan mikroarchitektury na tyle, aby spowodować awarię.

Źródło: opennet.ru

Dodaj komentarz