Explotació de referències null al kernel de Linux
Fa poc es va donar a conèixer la notícia que els investigadors de l'equip de Google Project Zero han desenvolupat un mètode per explotar vulnerabilitats al nucli de Linux causades per la desreferenciació del punter NULL.
Fins ara, els problemes al nucli relacionats amb la desreferenciació de punters NULL no han rebut la deguda atenció , ja que es considerava poc realista convertir aquests problemes en atacs que conduïssin a l'escalada de privilegis o l'execució de codi propi (prohibit mapejar processos sense privilegis a la regió inferior de l'espai d'adreces).
Com a regla general, aquests errors condueixen a la generació d'advertiments d'oops per part del nucli, després de tot això es completen les tasques problemàtiques i es restaura l'estat sense necessitat d'aturar el sistema.
El nou mètode d'atac es basa en el maneig d'estats oops , que poden resultar en un augment en el valor del comptador de referència (refcount), cosa que pot provocar el desbordament del comptador i alliberar la memòria associada amb el refcount.
En aquest cas, l‟explotació es redueix a manipulacions típiques dels atacs use-after-free (sorgeix una situació en què el recompte de referències de l‟objecte es torna zero, la memòria s‟allibera, però de fet hi ha enllaços en funcionament que apunten a la memòria alliberada).
En l'actualitat, quan el nucli de Linux activa una anul·lació de referència nul·la des de dins d'un context de procés, genera un oops , que és diferent d'un nucli panic. Es produeix un pànic quan el nucli determina que no hi ha una manera segura de continuar amb l'execució i que, per tant, ha de cessar tota execució. Tot i això, el kernel no atura tota l'execució durant un oops; en canvi, el nucli intenta recuperar-se tan bé com pot i continua amb l'execució.
La desreferenciació d'un punter NULL es fa servir aquí com una manera de generar l'estat «oops» de manera controlada. El problema és que es necessiten al voltant de 232 trucades d'estat oops per assolir un desbordament de refcount de 32 bits.
Des d'un punt de vista pràctic, calen al voltant de 8 dies de generació contínua d'estats oops per fer un atac utilitzant l'exploit proposat. Si teniu èxit, l'exploit us permet aconseguir l'execució del vostre codi a nivell de kernel.
La desreferència del punter NULL utilitzada a l'exploit es va solucionar a l'octubre, però atès que problemes similars no són infreqüents i anteriorment es tractaven com a errors, no com a vulnerabilitats, els desenvolupadors afegiran protecció general al nucli de Linux per evitar atacs que manipulen la generació de oops.
En el cas d'una tasca, això implica descartar la pila del nucli existent i anar directament a make_task_dead que crida a do_exit. El kernel també publicarà a dmesg un registre de «bloqueig» i un seguiment del kernel que mostra en quin estat es trobava el kernel quan va passar l'error. Aquesta pot semblar una elecció estranya quan s'ha produït clarament una corrupció de la memòria; no obstant això, la intenció és permetre que els errors del nucli siguin més fàcils de detectar i registrar sota la filosofia que un sistema en funcionament és molt més fàcil de depurar que un d'inactiu.
En particular , el Kernel 6.2 inclou canvis per limitar el nombre màxim d'oops . Després d'assolir el límit, que està establert en 10 mil oops per defecte (si voleu, podeu canviar-lo mitjançant el paràmetre oops_limit), el nucli iniciarà una transició a l'estat de «pànic», seguit d'un reinici, que no permetrà el nombre d'iteracions necessàries per restablir refcount a zero.
També està previst que la restricció es transfereixi a les branques del nucli llançades anteriorment, però encara admeses, així com als paquets del nucli de les distribucions populars.
Finalment si estàs interessat en poder conèixer més sobre això , pots consultar els detalls al següent enllaç.