Pax e protezione buffer overflow...

[iko]

Ciao a tutti, sto cercando di reperire informazioni sulla possibilità di proteggere un sistema linux contro i buffer overflow.
Dovrei sviluppare per l'università un modulo per il kernel che impedisca questo genere di attacchi.
Ho visto che bsd usa un sistema chiamato W^X (che però difficilmente si potrebbe implementare su linux senza controindicazioni) mentre linux PAX.
Tuttavia non ho ben capito se PAX viene incluso nativamente nelle versioni ufficiali del kernel di linux e se è efficace.
Insomma mi piacerebbe fare qualcosa che poi possa essere utile anche agli utenti "normali" di linux e che possa essere incluso direttamente nei futuri kernel.
Qualche opinione/suggerimento? Secondo voi è possibile realizzare una cosa del genere?

Grazie
Ciao
Fede

[makoomba]

pax non è incluso di default: su gentoo, ad esempio, devi utilizzare un profilo hardened.
per quanto concerne la sicurezza, certamente il sistema risulta più "robusto".
tuttavia, sono stati pubblicati dei "proof of concept" in cui pax veniva aggirato e l'exploit otteneva il suo scopo.
oltre a pax, ci sono già altri progetti con lo stesso obiettivo, tipo execshield.
_________________
When all else fails, read the instructions.

[.:chrome:.]

PaX non viene incluso nelle verisoni ufficiali, ma devi applicare la patch (http://pax.grsecurity.net) a mano.
l'alternativa è usare gli hardened-sources che includono le ottime genpatches e l'intero pacchetto GRSecurity (http://www.grsecurity.net) più altri aggeggi carini.

PaX funziona egregiamente, ma non viene incluso per il semplice motivo che taglia le gambe ad un ventaglio di applicazioni enorme.
comincia a considerare che abilitandolo con una policy non troppo permissiva (non dico il massimo di protezione) già non hai più nessun tipo di accesso a /dev/mem e /dev/kmem, e questo rende X11 inutilizzabile. potrei farti una lista di esempi lunga chilometri, ma finirei col farti il lavoro quindi buon divertimento

scherzi a parte... se ti serve una mano, io ci ho lavorato parecchio, ed è stata la mia tesi della triennale, quindi credo di poterti aiutare, se serve

[.:chrome:.]

[makoomba]

[.:chrome:.]

[makoomba]

no, penso che una giusta quantità di paranoia debba necessariamente far parte del bagaglio di ogni sistemista.
diventa eccessiva quando pregiudica i servizi e/o complica il normale processo di manutenzione/aggiornamento.
generalmente, ti salva il culo in più di un'occasione.
_________________
When all else fails, read the instructions.

[!equilibrium]

@k.gothmog: gli hardened-sources hanno PaX di serie oltre a GRSecurity. almeno, io ho l'opzione 'PAX' nel kernel.
_________________
Arch Tester for Gentoo/FreeBSD
Equilibrium's Universe

all my contents are released under the Creative Commons Licence by-nc-nd 2.5

[.:chrome:.]

[!equilibrium]

[.:chrome:.]

era uscita quella versione ~ dopo secoli di inattività. supponevo che fosse a causa della mancanza di release ufficiali di GRSecurity, ma adesso quella c'è stata, eppure gli hardened-sources non si sono mossi da lì...
sono perplesso

[iko]

Ringrazio tutti per le numerose e gradite risposte... Mi sono molto utili in quanto come accennava qualcuno si tratta proprio di un lavoro di tesi...
Mi pare d'avere tuttavia intuito che non c'è molta soddisfazione nell'usare pax e quindi dato che mi piacerebbe che il mio lavoro non restasse solo una tesi ma potesse essere d'aiuto per tutti, stavo pensando alla possibilità di usare altri modi per il riconoscimento e la "prevenzione" (per quanto possa essere possibile...) dei buffer overflow.
In particolare mi riferisco all'uso di ptrace a livello programmazione di sistema... Sarebbe possibile agganciare tutte le chiamate di sistema e fare dei controlli all'interno del codice che viene eseguito? .. In un certo senso penso di no dato che non avendone mai sentito parlare e non conoscendo implementazioni di questo tipo mi stupirebbe pensare che ad una cosa tanto banale non abbia pensato o lavorato ancora nessuno

A parte questo poi vorrei un chiarimento. Leggendo i sorgenti del kernel di linux 1.0 mi è parso di capire che non viene utilizzata la protezione a livello segmentazione in quanto la gdt viene semplicemente inizializzata con un dummy (obbligatorio) e 2 segmenti overlapped dati e codice rispettivamente. A questo proposito è forse come avviene in altri so, una soluzione temporanea di boot e mi sono perso io qualche funzione che poi li setta in modo più appropriato oppure è effettivamente cosi?
E se fosse realmente cosi, questa struttura è rimasta fino ai giorni nostri con il kernel 2.6 ?

grazie
ciao
Fede

[.:chrome:.]

[iko]

grazie x le risposte... ma... non sarebbe meglio provare a sviluppare qualcosa di simile? .. perchè una tesi tipo recensione e uso di quegli strumenti mi pare un po riduttivo o sbaglio?!!?

ciao
Fede

[.:chrome:.]

non per scoraggiarti... ma dubito che tu sia in grado di scrivere qualcosa di simile.
non è semplice programmare ad un livello così basso, specie se quello che si deve realizzare è una patch per implementare meccanismi di sicurezza a dir poco maniacali. non sono molti quelli in grado di farlo

per me comunque non è stata una tesi compilativa, quanto comparativa: implementare diverse soluzioni, confrontare il livello di invasività, configurabilità, flessibilità, e ovviamente difficoltà di implementazione e di integrazione con altri sistemi. studio di soluzioni cumulative (patch cumulative), test (pen-test), ed implementazione.

non è proprio un lavoro di recensione.
e poi perché sviluppare roba nuova...? come se non ce ne fosse già abbastanza in giro

se proprio vuoi programmare manda delle patch al mantainer di un progetto esistente

[iko]

ok grazie, allora proverò a dare 1occhiata alla roba che esiste già
Magari potrei fare anche una comparazione fra sistemi openbsd netbsd e linux dato che hanno una gestione completamente differente per quanto riguarda questo genere di problemi...

ciao
Fede

[Dr.Dran]

Dai una occhiata agli RSBAC-sources nel repositorio di Gentoo perchè hanno la patch comulativa PAX+RSBAC accennata da k.gothmog

Ciauz
_________________
:: [Dr.Dran] Details ::
- Linux User # 286282
- IT FreeLance Consultant
- President of ImoLUG [Imola & Faenza Linux User Group]

[.:chrome:.]

[Dr.Dran]