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. Raport Intela wskazuje, że problem pojawia się począwszy od 10. generacji (Ice Lake) procesorów Intel Core oraz trzeciej generacji 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 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 jest spowodowany nieprawidłowym obliczeniem rozmiaru instrukcji „MOVSB”, co prowadzi do naruszenia adresowania instrukcji zapisywanych do bufora ROB po instrukcji MOVSB z nadmiernym prefiksem i przesunięciem wskaźnika instrukcji. Taka desynchronizacja może ograniczać się do naruszenia obliczeń pośrednich z późniejszym przywróceniem stanu spójności. Jednakże, jeśli awaria wystąpi jednocześnie na kilku rdzeniach lub wątkach SMT, możliwe jest osiągnięcie wystarczającego uszkodzenia stanu mikroarchitektury, aby spowodować zatrzymanie awaryjne.
Źródło: opennet.ru
