SELinux e lo sfruttamento delle rilocazioni di testo

Ci sono due punti principali da fare. Il primo è che una delle principali forze della politica di SELinux è quella di prevenire lo sfruttamento delle vulnerabilità sconosciute . Dato che sono sconosciuti, un CVE non esiste.

Il secondo è che consentire il riposizionamento del testo consente anche a un exploit di scrivere ed eseguire qualsiasi codice che vorrebbe eseguire, o di modificare il codice esistente in memoria. Lei fa riferimento al breve blurb di Ulrich che contiene anche il suo articolo "che risolve il problema"; entrambi sono eccellenti e spiegano il problema.

La "necessità di eseguire trasferimenti di testo" non è di per sé una vulnerabilità; rende solo alcune vulnerabilità nel programma o librerie facili da sfruttare.

L'inesistenza di un CVE è una giustificazione orribile per non implementare una misura di sicurezza. Il punto centrale di questo gioco è di stare al passo con i tuoi aggressori e se gli ipotetici aggressori utilizzano solo diffusioni largamente diffuse e pubbliche, in realtà non sono molto bravi in ciò che fanno.

Le rilocazioni di testo sono "cattive" perché rappresentano un caso speciale di codice auto-mutante, il che significa che potenzialmente un utente malintenzionato potrebbe indurre il programma a modificare il suo testo in qualche altro modo. Se le rilocazioni sono richieste, significa che il programma .text (codice) può essere scritto in.

Senza una vulnerabilità effettiva che consente a un utente malintenzionato di manipolare il processo di trasferimento del testo o scrivere direttamente su .text , si tratta di un non problema totale. Ciò richiederebbe sostanzialmente che fossero in grado di aggiungere moduli caricabili, se è per questo che è necessario il trasferimento, o altrimenti di modificare file arbitrari sul sistema sotto attacco; in entrambi i casi hai problemi molto più grandi. Il caso di essere in grado di scrivere roba arbitraria in .text come attaccante è un bug di sicurezza abbastanza grande a sé stante.

Essenzialmente quando lo permetti, perdi il beneficio della protezione W ^ X. Questo è il grande problema.

Ovviamente, non sapere che non esiste una vulnerabilità che consentirebbe a un utente malintenzionato di eseguire queste operazioni. Saresti più sicuro se non riuscissi a concedere questa autorizzazione all'applicazione, ma se la funzionalità lo richiede onestamente, dovresti semplicemente lasciarlo mentre grida strong al fornitore del software.