Skitter Creek Bath Salts pe procesoare AMD 15h/16h: de ce „deja root” nu înseamnă risc zero
AMD descrie o posibilă problemă de aliasing pe procesoarele 15h/16h. Ce este demonstrat, ce rămâne neconfirmat și cum gestionezi hardware-ul fără suport.
AMD a publicat buletinul AMD-SB-7068 despre o problemă de aliasing a memoriei care afectează anumite procesoare din familiile 15h și 16h. Raportul cercetătorului Christopher Domas arată că registrele controlerului de memorie folosite pentru traducerea adreselor pot fi modificate astfel încât zone de DRAM ascunse chiar și nucleului sistemului de operare să devină accesibile.
Proiectul public, numit Skitter Creek Bath Salts, demonstrează accesul la regiuni asociate Platform Security Processor, System Management Mode, starea salvată C6 și copia de microcod păstrată în memorie. Impactul tehnic este profund, dar scenariul nu începe de la un e-mail sau de la un site: AMD spune explicit că atacatorul trebuie să dețină deja privilegii root sau administrator.
Ce este confirmat și ce rămâne doar afirmat
- AMD confirmă evaluarea unui raport despre registre ale controlerului de memorie care ar putea să nu poată fi blocate pe anumite procesoare Family 15h și 16h.
- AMD clasifică procesoarele afectate ca end of security support: nu mai primesc actualizări de securitate și buletinul nu oferă un patch.
- Cercetătorul spune că proiectul a fost dezvoltat și testat pe Family 16h. Extinderea demonstrației la fiecare model Family 15h nu este documentată în aceeași profunzime în repository.
- Repository-ul demonstrează citirea și scrierea unor regiuni protejate, inclusiv PSP, SMM, starea C6 și microcodul salvat în DRAM.
- Nu este publicată dovada unei exploatări active în atacuri reale, iar buletinul AMD nu atribuie problemei un CVE.
- Afirmația cercetătorului că ar exista aproximativ 100 de milioane de procesoare vizate nu este cuantificată sau confirmată în buletinul AMD.
- Afirmația „nu poate fi reparat” trebuie citită în context: AMD nu oferă actualizări pentru produsele ieșite din suport, dar nu afirmă că orice sistem, generație sau arhitectură ulterioară este vulnerabilă.
Cum funcționează, fără rețeta de exploatare
Sistemul de operare lucrează cu adrese fizice, însă controlerul de memorie le transformă mai departe în coordonate DRAM: canal, rang, banc, rând și coloană. Unele regiuni sunt rezervate firmware-ului ori unor moduri foarte privilegiate și, în mod normal, nu pot fi citite de nucleul sistemului de operare.
Demonstrația modifică temporar o setare a acestei traduceri. Aceeași adresă ajunge astfel la o altă zonă din DRAM, creând un alias care ocolește barierele construite pentru harta normală a memoriei. Cercetătorul reconstruiește matematic transformarea, apoi folosește aliasurile pentru a ajunge controlat la regiunile protejate.
Titlul viral despre „o singură instrucțiune” descrie operația care schimbă un bit al controlerului, nu întregul atac. O exploatare stabilă cere pregătirea memoriei, a cache-urilor, a întreruperilor și a mapărilor; executarea necontrolată poate bloca sistemul. Repository-ul conține un lanț tehnic complet, nu un buton universal care funcționează dintr-un cont obișnuit.
De ce contează dacă atacatorul este deja administrator
Un administrator compromis controlează deja sistemul de operare, fișierele și aplicațiile. Skitter Creek Bath Salts schimbă însă întrebarea de recuperare: mai poți avea încredere în componentele de sub sistemul de operare după ce atacatorul a putut modifica zone protejate de hardware?
- Reinstalarea sistemului de operare nu demonstrează singură că starea de nivel inferior a rămas intactă.
- Investigația nu trebuie să se oprească la resetarea parolelor dacă au existat privilegii kernel, încărcare de drivere sau acces administrativ necontrolat.
- Controalele obișnuite ale sistemului de operare pot avea vizibilitate limitată asupra SMM, PSP ori regiunilor de microcod.
- Pe hardware fără suport, lipsa unei actualizări mută decizia de la „când aplicăm patch-ul?” la „cum izolăm, înlocuim și demonstrăm retragerea?”.
Cine trebuie să verifice inventarul
Familiile 15h și 16h includ procesoare lansate aproximativ în perioada 2011–2015 și pot apărea în PC-uri vechi, stații tehnice, sisteme de laborator, echipamente embedded, appliance-uri sau medii operaționale păstrate mult după ciclul obișnuit de viață. Numele comercial nu este suficient pentru confirmare; echipa IT trebuie să verifice familia CPUID și modelul exact.
- Echipa de asset management identifică toate sistemele cu procesoare AMD Family 15h/16h și le asociază unui owner, unei funcții și unei date de retragere.
- Administratorii separă sistemele fără suport de conturile administrative zilnice, de internet și de segmentele cu date sensibile, proporțional cu rolul lor.
- Echipa endpoint verifică politicile pentru încărcarea driverelor, controlul aplicațiilor și folosirea privilegiilor locale; acestea reduc probabilitatea ca atacatorul să atingă condiția inițială.
- SOC-ul stabilește ce evenimente indică obținerea privilegiilor kernel sau instalarea unui driver și cum este păstrată evidența înainte de oprirea sistemului.
- Responsabilul de risc acceptă în scris excepțiile temporare și finanțează înlocuirea. „Este prea vechi pentru patch” nu este o măsură compensatorie.
Deciziile angajatului și ale help desk-ului
- Nu instala un driver, utilitar de diagnostic, instrument de overclocking sau firmware primit prin e-mail, chat ori forum, chiar dacă solicită „doar” drepturi de administrator.
- Nu oferi acces administrativ unui furnizor fără tichet, identitate verificată, fereastră aprobată și monitorizarea sesiunii.
- Raportează imediat dezactivarea neașteptată a protecțiilor endpoint, un driver necunoscut, un restart repetat sau o solicitare neobișnuită de privilegii.
- Help desk-ul nu reconectează automat un sistem vechi după reimaging atunci când compromiterea a ajuns la root/kernel; escaladează decizia către incident response și ownerul hardware.
- Nu încerca demonstrația publică pe echipamente de producție. Modificarea controlerului de memorie poate cauza coruperea memoriei sau blocarea sistemului.
Tabletop: compromiterea unei stații vechi de laborator
Scenariul poate fi rulat cu IT, help desk, SOC, asset management, echipa de laborator sau OT, procurement și management. Pentru fiecare inject se cer decizia, ownerul, termenul și dovada verificabilă.
- Inject 1 — inventarul descoperă o stație AMD Family 16h care controlează un echipament scump și nu poate fi înlocuită imediat. Cine aprobă menținerea și ce izolare se aplică?
- Inject 2 — EDR raportează încărcarea unui driver necunoscut cu privilegii kernel. Ce date sunt colectate și cine decide izolarea?
- Inject 3 — administratorul recunoaște că a executat un utilitar primit de la un furnizor prin chat. Cum este verificată identitatea furnizorului și cum se extinde investigația?
- Inject 4 — echipa reinstalează sistemul, dar nu poate demonstra integritatea componentelor de nivel inferior. Ce criteriu permite revenirea în producție?
- Inject 5 — înlocuirea durează 90 de zile. Ce controale compensatorii, monitorizare, limitări de acces și termen de expirare sunt documentate?
Ce măsurăm după exercițiu
- Procentul activelor pentru care familia procesorului, ownerul și starea de suport sunt cunoscute.
- Numărul sistemelor Family 15h/16h rămase în producție și procentul cu termen de retragere aprobat.
- Timpul dintre alerta de driver privilegiat și izolarea endpointului.
- Procentul sesiunilor de furnizor care au tichet, verificare independentă și jurnalizare.
- Procentul incidentelor root/kernel în care criteriul de revenire include integritatea hardware și firmware, nu doar reinstalarea sistemului de operare.
În Learning Awarely, cazul poate deveni un exercițiu pe roluri: angajatul verifică solicitarea de instalare, help desk-ul recunoaște limita reimagingului, SOC-ul păstrează probele, asset management-ul confirmă familia procesorului, iar managementul decide izolarea și înlocuirea. Obiectivul nu este memorarea unei instrucțiuni, ci evitarea drumului până la root și luarea unei decizii corecte când hardware-ul nu mai poate fi actualizat.
Surse
- AMD — AMD-SB-7068, Memory Aliasing Vulnerability
- Christopher Domas — cercetarea și demonstrația Skitter Creek Bath Salts
- Tom’s Hardware — relatarea independentă despre demonstrație și procesoarele afectate
- AMD — documentația controlerului de memorie pentru Family 16h
- Christopher Domas pe X — anunțul cercetătorului și afirmațiile privind amploarea
- David Manheim pe X — contextul discuției despre limitele remedierii software