Modelul de amenințări și aspectele evaluării vulnerabilităților în nucleul Linux

Linus Torvalds a inclus în nucleu un document care reglementează procesul de gestionare a erorilor legate de securitate, stabilind un model de amenințare și explicând care erori din nucleu sunt interpretate ca vulnerabilități, precum și modalitățile de gestionare a erorilor identificate cu ajutorul AI. Documentul a fost pregătit de Willy Tarreau, autorul HAProxy și un dezvoltator de lungă durată al nucleului Linux, responsabil cu întreținerea mai multor ramuri stabile ale nucleului. Ca bază s-au folosit înțelegerile atinse în urma discuțiilor despre vulnerabilitățile critice recent descoperite în nucleu (1, 2, 3, 4), dezvăluite înainte de publicarea corecțiilor și pentru care, grație AI, s-au putut crea imediat exploatabile funcționale.

Majoritatea erorilor legate de securitate ar trebui să fie tratate public, pentru a atrage un public cât mai larg și a găsi soluția optimă. Pe un listă privată de distribuție se propune să fie trimise doar notificări de urgență despre vulnerabilitățile ușor exploatabile, care prezintă o amenințare pentru mulți utilizatori și permit obținerea de privilegii extinse sau capacități.

Vulnerabilitățile identificate cu ajutorul asistenților AI ar trebui discutate întotdeauna public, deoarece astfel de probleme sunt adesea descoperite simultan de mai mulți cercetători. În raport nu trebuie să fie divulgat exploit-ul - este suficient să se menționeze că acesta este disponibil și să fie oferit în mod privat ca răspuns la o solicitare a persoanei responsabilă.

Regulile de raportare pentru rapoartele create cu ajutorul asistenților AI sunt descrise separat. Se primesc foarte multe astfel de rapoarte și, datorită lor, se reușește în mod periodic să se identifice erori în părți de cod slab recenzate, dar persoanele responsabile le ignoră adesea din cauza calității scăzute și inexactităților. Cerințele principale pentru rapoartele create cu participarea AI sunt:

  • Să fie concise, fără informații inutile și cu indicarea esenței și detaliilor importante de la început.
  • Doar text simplu, fără etichete Markdown și fără decorare.
  • Înțelegerea modelului de amenințare și indicarea faptelor verificate (de exemplu, „eroarea permite oricărui utilizator să obțină CAP_NET_ADMIN”), nu idei teoretice și speculații despre consecințele vulnerabilității.
  • Înainte de a trimite raportul, este esențial să testăm cu atenție funcționalitatea exploit-ului generat prin AI și să ne asigurăm că problema poate fi reprodusă.
  • Implicarea AI pentru dezvoltarea și testarea remedierii problemei identificate.

Conform statisticilor acompaniatoare, majoritatea rapoartelor de erori trimise sub formă de remediere a vulnerabilităților nu sunt, de fapt, vulnerabilități și ar trebui procesate în mod obișnuit ca erori obișnuite. Pentru separarea vulnerabilităților de erorile obișnuite, a fost descris un model de amenințare pentru kernelul Linux. Printre posibilitățile și garanțiile, a căror încălcare poate fi considerată o vulnerabilitate:

  • Izolația la nivelul utilizatorilor: acces la fișiere doar pentru proprietar, memoria procesului este inaccesibilă altor utilizatori, ptrace este interzis pentru procesele externe, izolația IPC și a comunicațiilor de rețea.
  • Protecția bazată pe capabilities: fără CAP_SYS_ADMIN nu se poate schimba configurația kernelului, memoria, starea sistemului; fără CAP_NET_ADMIN nu se pot schimba setările de rețea sau intercepta traficul; fără CAP_SYS_PTRACE nu se pot urmări procesele altor utilizatori.
  • Spațiul numelui identificatorilor utilizatorilor (CONFIG_USER_NS) permite utilizatorilor neprivilegiați să creeze propriile medii izolate, din care nu se poate influența spațiul numelui global, de exemplu, prin schimbarea timpului, încărcarea modulelor sau montarea dispozitivelor bloc.
  • Interfețele de depanare (/proc/kmsg, perf, debugfs), prin care se poate accesa informația confidențială, sunt disponibile doar după ce administratorul a acordat explicit acces.

Funcționalitățile care nu sunt considerate vulnerabilități:

  • Folosirea ramurilor de kernel învechite.
  • Compilarea cu opțiuni de dezvoltare sau cu opțiuni care reduc securitatea (de exemplu, CONFIG_NOMMU).
  • Setarea configurațiilor sysctl nesigure, opțiunilor din linia de comandă, drepturilor de acces în FS, capabilities sau deschiderea accesului pentru utilizatorii neprivilegiați către interfețele privilegiate (de exemplu, accesul de scriere în procfs și debugfs).
  • Probleme în funcțiile destinate exclusiv dezvoltării și depanării kernelului, cum ar fi LOCKDEP, KASAN și FAULT_INJECTION, care nu sunt destinate a fi incluse în configurațiile de lucru.
  • Probleme în drivere, module și subsisteme aflate în secțiunea STAGING sau marcate ca experimentale, nesigure sau nefuncționale.
  • Utilizarea modulelor de nucleu terțe sau a forks-urilor neoficiale ale nucleului.
  • Cerința de privilegii excesive, cum ar fi necesitatea de a efectua acțiuni cu drepturi de root sau de la un utilizator cu drepturi CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_SYS_RAWIO și CAP_SYS_MODULE.
  • Atacuri teoretice care necesită condiții de laborator, miliarde de încercări, emulări sau modificări de hardware, costuri disproporționate și configurații nerealiste (de exemplu, sisteme cu zeci de mii de nuclei CPU).
  • Ocolirea mecanismelor de protecție (de exemplu, ASLR) fără a demonstra un exploit. Lipsa verificărilor argumentelor și a codurilor de eroare returnate, care nu au consecințe evidente.
  • Scurgeri de informații întâmplătoare, necontrolate de atacatori, cum ar fi date reziduale în mesajele de eroare și scurgeri de adrese/pointere în memorie a nucleului fără posibilitate directă de exploatare.
  • Erori la montarea imaginilor de disc deteriorate, dacă driverul nu este declarat ca fiind potrivit pentru utilizarea cu medii nesigure. Probleme cu imaginile de disc, detectabile și soluționabile prin rularea utilitarului fsck.
  • Atacuri care necesită acces fizic la hardware, modificarea hardware-ului sau conectarea dispozitivelor hardware, cum ar fi plăcile pentru atacuri DMA și analizorii logici, dacă sistemul nu este configurat special pentru a proteja împotriva unor asemenea atacuri (IOMMU).
  • Regresii în funcționalitate și performanță, soluționabile prin configurarea drepturilor și limitelor.

Sursa: opennet.ro

Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS 🔥 Cumpără un hosting fiabil pentru site-uri cu protecție DDoS, servere VPS VDS | ProHoster