Cum sa ma simt cand aflu ca anul trecut a iesit la iveala o problema in procesoarele lumii moderne (calculatoare, telefoane smart, console de jocuri, automobile) veche de peste 20 de ani?
Nu stiu daca sa plang sa ma bucur, dar ma consolez cu speranta ca va scadea pretul la cele mai tari procesoare "afectate" de greseala propagata generatie de generatie si ca imi voi cumpara un calculator-server ceva mai ieftin decat am prevazut.
Problema chiar este veche de 22-24 de ani si este aparuta din vremea procesoarelor Intel Pentium (lansate in martie 1993) si Pentium Pro (noiembrie 1995) si care au reprezentat un pas urias privind trecerea de la procesoarele i486 (80486).
Pe ATS am gasit o lista de discutie privind doua defecte de proiectare in procesoarele din ultimii 20 de ani, vulnerabilitati care pot duce ls accese neautorizate la o memorie protejata (metoda Meltdown - afecteaza Intel si ARM) si posibilitatea ca un program neprivilegiat sa apeleze rutine accesibile numai administratorilor (metoda Spectre - afecteaza Intel, AMD si ARM).
https://meltdownattack.com/ sau https://spectreattack.com/
O lista de resurse privind uriasa problema de securitate care a aparut este la github.
Citind o introducere privind problema sau detalii privind situatia actuala incep sa inteleg cat de mare este problema:
Descoperirea Meltdown: ca problema sa fie rezolvata, o solutie este toate programele (privilegiate si neprivilegiate) sa aiba propria tabela TLB (translation lookaside buffer), o alta solutie este ca nucleul sistemului de operare (executie privilegiata pe inelul 0) sa aiba o tabela TLB si restul de aplicatii (programe neprivilegiate care se executa in inelul 1, 2 sau 3) sa aiba alta tabela TLB comuna, dar orice solutie s-ar folosi, tot ar apare penalitati in viteza de executie a programelor (zona TLB este limitata in functie de procesor), pentru ca se pierde timp cu schimbarea contextului de executie intre instructiuni privilegiate (inelul 0) si neprivilegiate (alte inele).
Un program neprivilegiat care apeleaza rar functii de nucleu se executa cu penalitati de viteza de 2-3%.
Dar un program de test construit (in mod exagerat) ca sa testeze viteza sistemului cand este protejat (la problema Meltdown) si care nu face altceva decat sa apeleze continuu functii din nucleu (cod privilegiat) se executa cu penalitati de 50%, adica apelurile catre nucleu dureaza de doua ori mai mult datorita pierderii de timp cu refacerea TLB program neprivilegiat ca sa nu contina valori din zona nucleului si asta inainte de returnarea rezultatului. Vulnerabilitatea Meltdown consta in faptul ca un program neprivilegiat poate citi prin TLB zone de memorie care nu ar fi trebuit sa fie accesibile.
Asadar penalitatile de executie vor fi, in medie de 25%, dar sistemul va fi protejat la atacurile efectuate dupa metoda Meltdown prin actualizari de sistem (nucleul este recompilat si astfel functiile exportate sunt accesibile in siguranta).
Descoperirea Spectre: executia predictiva din procesoarele moderne (o tehnica de optimizare a executiei instructiunilor si de crestere a vitezei) creaza o oportunitate exploatabila de catre hackeri astfel incat un program neprivilegiat sa execute (sa apeleze rutine) secvente de cod din programe la care nu ar fi trebuit sa aiba acces si de aici rezulta ca un program conceput sa fure date, poate compromite foarte usor un server.
Nu exista o solutie simpla la vulnerabilitatea Spectre, pentru ca toate programele care se doresc a fi protejate trebuie recompilate, iar compilatorul trebuie sa fie pregatit sa genereze cod care sa nu necesite executia predictiva (sa o ocoleasca folosind un algoritm potrivit situatiei) si asta necesita ceva timp pana apare un asemenea compilator, dezactivarea (ocolirea) executiei predictive scade viteza de executie a programelor (se pierde optimizarea de care s-au bucurat toti cei care au inlocuit i486 cu P5, P Pro si MMX) in plus problema apare pe arhitecturi diferite de procesoare (Intel, AMD si ARM) si necesita multa munca de cercetare.
Situatia este ingrijoratoare: se stie de mult ca un program JavaScript care ruleaza in browser poate fura parolele stocate in browser, dar combinat cu vulnerabilitatile descrise de cei doi hackeri, poate fura parole din sistem (din memorie prin TLB) si poate executa secvente privilegiate de cod (pe inelul 0) care sa creeze legaturi cu serverul hackerului: calculatorul "infectat" face singur legatura cu atacatorul (si aproape nimeni nu il poate opri aici, rareori o face firewallul sau antivirusul) si ii comunica parola descoperita sau prin conexiunea creata primeste comenzi de la hacker care sa fie executate in regim de administrator (root sau supervizor).
In plus, nici browserele prin sistemul TOR nu mai sunt sigure, trebuiesc recompilate.
11 ianuarie 2018: Se pare ca OpenBSD, cand este vorba de securitate, este cu 10 ani inaintea celorlalte sisteme de operare: mesaj de la Theo de Raadt din 27 iunie 2007.
Interviu din 8 ianuarie 2018 cu Theo de Raadt, fondatorul OpenBSD.