buffer overflow: parliamone

[mjordan]

Il problema nasce quando certi exploit possono essere utilizzati contro software "quotati" scritti da persone che normalmente dovrebbero mangiare pasta e bit, per cui si ritorna inevitabilmente al punto che indicavi prima e cioè che su certe materie c'è sicuramente dell'oscurantismo in quanto.... magari bastasse leggere quegli articoletti che ogni tanto compaiono sulle riviste (come dicevo qualche post + su).

Forse non ho capito bene quello che volevi dire ...
Io con esempi deficienti intendevo dire che la maggior parte delle persone sa come causare un buffer overflow. Del resto lo indica la parola stessa. Riempire un buffer (array, vettore, struttura dati, quello che sia ...) oltre la propria capacità ...
Quello che intendevo io è che sarebbe interessante capire le tecniche che invece ci stanno dietro per ottenere privilegi inautorizzati (ed è questo che è difficilmente ricollegabile al buffer overflow).
Questo potrebbe risultare ovvio nel caso di sistemi operativi che utilizzino la modalità reale, ma per la modalità protetta, dopo un buffer overflow, con quale teoria si "bypassa" la protezione della memoria kernel space e si modificano i trap vector di un SO?

Questa era la domanda a cui sarebbe bello rispondere e documentarsi. E sono sicuro che una volta che si sappia rispondere a questa domanda, la "teoria dei buffer overflow" potrebbe essere conlusa una volta per sempre.

EDIT:

Ho riletto meglio il tuo post e adesso ho capito ciò che volevi dire.
Difatti pensa a quelle riviste stupide che sono uscite ultimamente, non ricordo neanche come si chiamano, tipo Hacker Journal o Hackers & Co.
Per come la vedo io sono riviste totalmente "infondate". Si limitano a descrivere un problema in una maniera talmente informale e banale che dubito anche il + grande genio del pianeta vi possa intuire qualcosa di utile a capire a fondo un argomento. La realtà è che l'oscurantismo che c'è dietro queste cose non sarebbe neanche reale, ma fittizio. Molti che si dichiarano esperti di sicurezza ( e i redattori di quelle riviste dovrebbero esserlo, visto il nome aitante delle stesse ), sono in realtà persone che capiscono il problema solo " dall'esterno" . In parole povere quello che scrivono è tutto ciò che sanno. E tali riviste, difatti, sono le + vendute fra i ragazzi molto giovani, perchè li apprendono qualche nuovo termine con cui fare i fighi al prossimo cocktail party. Ma in realtà parlare di questi argomenti richiede troppe conoscenze di base, effettivamente, per pubblicare una rivista seria sull'argomento. . .(e le persone che saprebbero effettivamente parlarne con autorevolezza e cognizione di causa di certo non accetterebbero di essere redattori di una rivista, tra le altre cose )

[recoil]

bravo mjordan, hai centrato il problema!
io ad esempio non so come si fa ad aggirare la modalità protetta ma magari un modo c'è e sarebbe bello scoprirlo.
il tutto, lo ripeto, per "cultura" personale e per evitare di scrivere un giorno programmi facilmente attaccabili.

[mjordan]

Originariamente inviato da recoil
bravo mjordan, hai centrato il problema!
io ad esempio non so come si fa ad aggirare la modalità protetta ma magari un modo c'è e sarebbe bello scoprirlo.
il tutto, lo ripeto, per "cultura" personale e per evitare di scrivere un giorno programmi facilmente attaccabili.

Meno male, pensavo di essermi spiegato molto male.
Il fatto è che se uno programmasse con questa conoscenza in mente, sarebbe molto difficile commettere errori di questo tipo (o perlomeno non li si farebbe gratuitamente).

[recoil]

Originariamente inviato da mjordan
Il fatto è che se uno programmasse con questa conoscenza in mente, sarebbe molto difficile commettere errori di questo tipo (o perlomeno non li si farebbe gratuitamente).

esempio: se si sa che la strcpy è potenzialmente pericolosa perché la usarla?
eppure mi pare di vedere che la utilizzano tutti

[mjordan]

Originariamente inviato da recoil
esempio: se si sa che la strcpy è potenzialmente pericolosa perché la usarla?
eppure mi pare di vedere che la utilizzano tutti

La strcpy() è pericolosa perchè non fa nessuna assunzione di come siano posizionate in memoria le stringhe, dando origine ad un possibile buffer overflow con un utilizzo sprovveduto.
Questo però è risolvibile considerando tutte le possibili casistiche quando si usano funzioni che non hanno puntatori restrict come default nei relativi prototipi.

[recoil]

io cmq so che per le stringhe è meglio utilizzare strncpy, se non altro si può specificare un limite per il numero di caratteri da copiare

[mjordan]

Originariamente inviato da recoil
io cmq so che per le stringhe è meglio utilizzare strncpy, se non altro si può specificare un limite per il numero di caratteri da copiare

Rimane sempre il fatto che se le stringhe si sovrappongono, il comportamento è indefinito ... e questo può generare un buffer overflow ... Credo che la migliore funzione per copiare stringhe sia la memmove(), dove se le aree di memoria copiare subiscono un overlap, questa funzione sta attenta a copiare la roba nei posti giusti. Ove disponibile (sistemi Unix basati su glibc) sarebbe ancora meglio usare la funzione mempcpy():

void * mempcpy(void * restrict to, const void * restrict from, size_t size);

che garantisce grazie al qualificatore restrict la non sovrapponibilità di due oggetti in memoria. Questa funzione è un'estensione GNU, ma non è difficile trovare qualche implementazione similare per altri sistemi ...

[recoil]

Originariamente inviato da mjordan
Rimane sempre il fatto che se le stringhe si sovrappongono, il comportamento è indefinito ... e questo può generare un buffer overflow ...

pensa che era segnalata come una funzione sicura su un documento che parlava di buffer overflow
magari l'hanno scritto i programmatori di windows NT

[mjordan]

Originariamente inviato da recoil
pensa che era segnalata come una funzione sicura su un documento che parlava di buffer overflow
magari l'hanno scritto i programmatori di windows NT

[recoil]

la discussione e' gia' finita?

[mjordan]

Originariamente inviato da recoil
la discussione e' gia' finita?

Ringrazia gli oscurantisti

[maxithron]

Mi è venuto in mente questo post e vorrei che si riaprisse la discussione...

Come considerare che anche "gets" è una funzione "pericolosissima" ?

[recoil]

la pericolosita' e' data dal fatto che gets manda la stringa di caratteri direttamente nel buffer, limitandosi a sostituire il carattere che manda a capo con lo 0 e senza controllare che le dimensioni siano inferiori a quelle del buffer.

[maxithron]

appunto.....eppure come strcpy è utilizzata tantissimo nelle applicazioni

[maxithron]

in genere sarebbe meglio fgets ma lo sconcerto rimane lo stesso...
se non ti vai a cercare determinate soluzioni, difficilmente (anche sui libri) c'è un approfondimento sul tema, più che altro qualche nozione basilare...manco si stesse parlando di....di.....ehm....ma esistono ancora tabù al giorno d'oggi?

[cionci]

Mandare in esecuzione programmi a rischio exploit con un user con pochissimi privilegi è la cosa migliore da fare per proteggersi contro eventuali buffer overflow... Guardate come fa qmail ad esempio...

[maxithron]

Ehilà Cionci...come va?

Il problema è un altro.....cioè, dato che al giorno d'oggi, la maggior parte degli exploit, si conoscono e ci si può difendere(giustamente citavi un caso come qmail), ma è assurdo che nella maggior parte dei casi si sfruttano sempre gli stessi "errori" anche in software quotati.

Dato che noi ci poniamo questo problema,mi sembra strano (o almeno non ci arrivo) poter pensare che in software "quotati" non ci si pensi a priori.

Chiaro che è impossibile scrivere qualcosa di così perfetto da non essere soggetto a niente,ma.....qua si parla sempre degli stessi tipi di overflow........

ed è anche vero quanto detto + su da recoil e mjordan....sembra che in materia ci sia davvero dell'oscurantismo....

[cionci]

Ciao maxithron

Molte volte si tratta anche di errori un po' più complessi rispetto alla presenza di fgets, strcpy o altre funzioni che non controllano la dimensione e la sovrapposizione delle aree di memoria conivolte... Magari si può trattare di un "errore" di programmazione nella libreria xyz che veniva usata dalla libreria zyx che veniva utilizzata dalla libreria zxy che noi utilizzavamo direttamente...

Quindi diciamo che è molto difficile (quasi impossibile) affermare che un programma sia immune da qualsiasi exploit...ed in ogni caso è bene limitarne gli effetti eseguendo i vari demoni come utenti ad hoc con permessi mooolto limitati... E' difficile in questo modo che si possa prendere il controllo dell'intera macchina...ma solo dell'utente con cui abbiamo lanciato il demone... Da lì a raggiungere i permessi di root ci vuole un bel po'

Ad esempio di recente anche per mysql ne hanno trovato uno (sul cambio della password da parte di un qualsiasi utente): http://www.k-otik.com/exploits/09.14.mysql.c.php

[maxithron]

E' giustissimo ciò che dici riguardo alla maggior complessità di alcuni exploit, ma in quei casi, trovarne uno è davvero un lavoro di fino....ed oltretutto (credo) si possono scoprire anche e solo per caso.

Invece mi riferisco a tutti gli exploit che si potrebbero evitare se solo chi scrive codice, si documentasse un pò + in materia, proprio per evitare che almeno sulle "funzioncine" strcpy & Co., incappi nell'overflow.

[maxithron]

anche se è un pò vecchiotta è comunque un altro spunto di discussione(se volete...):

http://puntoinformatico.it/news/?idnews=224