View Full Version : buffer overflow: parliamone
ieri sera si è scatenato il panico per l'ennesima falla di windows, causata da un buffer overflow.
quello che mi chiedo è come mai capitano ancora cose del genere.
ricordo di aver affrontato la questione BO e l'idea che mi ero fatto era quella di un problema serio ma cmq evitabile con qualche accorgimento.
come è possibile che saltino fuori ogni volta problemi del genere?
una volta ho scritto un programmino che poteva essere "bucato" con un attacco tipo BO ma avevo proprio fatto apposta a mettere la strcpy in un certo punto ecc. ecc. e pensavo che ormai si fosse immuni da roba del genere :rolleyes:
Ieri sera a 3 miei amici quasi contemporaneamente hanno avuto problemi di RPC (Remote Procedure Call), ti stai riferendo a quello?
io parlo del buffer overflow in generale. per quel problema di RPC c'è già una discussione in rilievo in "Discussioni Off-Topic".
l'ho messo in questa sezione perché mi piacerebbe parlarne dal punto di vista della programmazione: ovvero cosa genera un buffer overflow, come sfruttare queste falle e soprattutto come fare per creare programmi "sicuri" ;)
Bouba_Diop
15-08-2003, 18:31
ciao
L'overflow di un registro o di un buffer (penso siano più o meno simili...) avviene quando si raggiunge il numero massimo che il registro può contenere. Ad esempio nel microcontrollore PIC16x84 una volta raggiunto il numero 255 (registri da 8 bit), se si incrementa di 1 o più quel numero, il conteggio ritorna da capo, ovvero 0, 1, 2... Nel momento in cui fa il "giro", viene messo a 1 una determinata (il carry se non sbaglio...) flag che ti indica che il registro è andato in overflow.
Penso che intenda una cosa del genere, però non ne sono sicuro, magari è completamente diverso quel caso...aspetto eventuali correzioni.
ciao
Originariamente inviato da Bouba_Diop
Penso che intenda una cosa del genere, però non ne sono sicuro, magari è completamente diverso quel caso...aspetto eventuali correzioni.
quello che hai scritto tu è l'overflow di un registro (o se vogliamo di una variabile).
quello che intendevo io invece riguarda il caso di buffer quindi in genere si parla di array di caratteri.
viene data in pasto a tale array una stringa particolare e questa "sconfina" dai limiti dell'array e finisce con l'intaccare parti di memoria dove risiede il codice sorgente del programma in esecuzione.
in questo modo si può controllarne l'esecuzione, saltando in punti particolari o magari inserendo delle istruzioni che si vogliono eseguire (molto comunemente l'istruzione per aprire una shell)
Non so ... può essere utile?
************
Mi sembra una spiegazione introduttiva non malaccio...Spero sia un indirizzo "lecito" altrimenti lo edito ....
Originariamente inviato da atragon
Non so ... può essere utile?
************
Mi sembra una spiegazione introduttiva non malaccio...Spero sia un indirizzo "lecito" altrimenti lo edito ....
Non ritengo personalmente che si debbano segnalare certe cose
Può sembrare ipocrisia, ma non lo è
Sono perfettamente cosciente che certi siti sono noti a tutti (anche quelli pornografici lo sono), ma questo non significa che li si debba anche pubblicizzare
Lo scopo dichiarato di certi siti non è l'evidenziare certe falle nella sicurezza, ma il suggerire metodi per sfruttarle, quindi da questo punto di vista, a mio avviso, non sono accettabili
Questi i motivi della correzione apportata, mi riservo comunque di chiedere il parere di tutto lo staff e verificare se mi sono sbagliato
--Non ritengo personalmente che si debbano segnalare certe cose
Calma, apposta mi sono autodenunciato, appena inserito il post, presso i mod .... giusto per avere un parere... (non ricordavo tutto il contenuto dell'articolo che in passato avevo preso come base per alcuni test sulla mia rete aziendale) non faccio certe cose a cuor leggero
--Questi i motivi della correzione apportata, mi riservo comunque di chiedere il parere di tutto lo staff e verificare se mi sono sbagliato
Per me è sufficiente questo, anche io ero un po' restio alla pubblicazione del link che peraltro trattava bene quanto in argomento da un punto di vista "anche", o meglio, soprattutto, teorico. Chiudiamo pure qui la questione, esiste altro materiale meno"pesante" sull'argomento che cercherò di mettere a disposizione. Grazie per le puntualizzazioni, anche se forse avrei apprezzato maggiormente un pvt.
cmq io voglio solo una discussione teorica, non mi interessa affatto sapere come sfruttare falle di questo tipo.
semmai è interessante capire come prevenirle e come scrivere codice "sicuro".
una discussione sul buffer overflow può inoltre stimolare ad approfondire argomenti che non riguardano esplicitamente la sicurezza. ad esempio si può capire bene come funziona lo stack, cos'è il record di attivazione di una funzione ecc.
ho proposto l'argomento perché in questa sezione si fanno sempre domandine su come fare questo e quello nel tal linguaggio e non si approfondisce mai nulla :rolleyes:
maxithron
17-08-2003, 13:50
Originariamente inviato da recoil
quello che intendevo io invece riguarda il caso di buffer quindi in genere si parla di array di caratteri....
E' davvero un argomento interessante e merita sicuramente un grande approfondimento.
Spero anche che i moderatori per qualche linea di codice che magari verrà postata, tengano in considerazione che si tratta appunto di uno scambio culturale di vedute ed esperienze e non un invito al cracking etc.....(e magari bastasse solo qualche linea di codice;) )
Cmq....,diamo per scontato di sapere che:
La memoria allocata per un processo si divide in 3 parti:
1) text (a sola lettura )
2) dati statica - divisa in "data" e "bss"
3) dati dinamica - divisa in "stack e "heap"
e dato per scontato che sappiamo anche cosa "ci va" a livello dati in queste 3 parti.....
E, non ultimo, diamo anche per scontato di masticare un pò di C ed un pò di assembly......
per tornare al problema posto da recoil, e cioè relativo al buffer overflow sullo stack, possiamo dire che se ad esempio vogliamo realizzare una semplice applicazione in C, che magari legge una stringa da linea di comando, per poi copiarla in un buffer di "n" caratteri mediante "strcpy()" e poi c'invia il dato su output standard.....qui chiedo esplicitamente ad un mod di sapere appunto se posso postare o meno un pò di codice.....
Originariamente inviato da maxithron
per tornare al problema posto da recoil, e cioè relativo al buffer overflow sullo stack, possiamo dire che se ad esempio vogliamo realizzare una semplice applicazione in C, che magari legge una stringa da linea di comando, per poi copiarla in un buffer di "n" caratteri mediante "strcpy()" e poi c'invia il dato su output standard.....qui chiedo esplicitamente ad un mod di sapere appunto se posso postare o meno un pò di codice.....
dovrei avere del codice che credo sia di pubblico dominio ormai e che riguarda un buffer overflow in windows NT.
per me non c'è niente di illegale, tanto più in un semplice esempio con lo strcpy dato che potrebbe trattarsi di un programma qualunque ;)
purtroppo non ho più la roba che avevo fatto io ma per fare un esempio basta poco direi.
maxithron
17-08-2003, 14:50
beh, hai ragione....se usiamo codice di publico dominio.....
/* esempio tratto da una nota rivista....buffer.c*/
#include <stdio.h>
#include <string.h>
int main(int argc, char *argv[])
{
char buf[48];
printf("indirizzo: 0x%x (%u)\n", buf , buf);
strcpy(buf, argv[1]);
printf("%s\n", buf);
}
........
compilatelo anche con l'opzione -S per il codice assembly.
maxithron
18-08-2003, 00:51
beh?....finito tutto?
appunto, non scrive nessuno :(
diamo colpa alle vacanze
maxithron
18-08-2003, 15:23
Originariamente inviato da recoil
appunto, non scrive nessuno :(
diamo colpa alle vacanze
beati loro......
:( :(
Se riesco a recuperare la documentazione che avevo la posto .... purtroppo sono passati un po' di anni e due traslochi...:rolleyes:
maxithron
18-08-2003, 19:27
possiamo anche partire da quello spunto di qualche post sopra.
E' sicuramente banale ma credo che per la trattazione dell'argomento sia + che sufficiente(almeno per come ho inteso che Recoil voglia).
Originariamente inviato da MM
Non ritengo personalmente che si debbano segnalare certe cose
Può sembrare ipocrisia, ma non lo è
Sono perfettamente cosciente che certi siti sono noti a tutti (anche quelli pornografici lo sono), ma questo non significa che li si debba anche pubblicizzare
Lo scopo dichiarato di certi siti non è l'evidenziare certe falle nella sicurezza, ma il suggerire metodi per sfruttarle, quindi da questo punto di vista, a mio avviso, non sono accettabili
Questi i motivi della correzione apportata, mi riservo comunque di chiedere il parere di tutto lo staff e verificare se mi sono sbagliato
Io penso che non segnalare dei siti perchè sotto ci siano delle questioni moralistiche del tipo "che uso ne faccia un utente" è sbagliato. Io non posso smettere di imparare perchè al mondo ci siano degli imbecilli. Inoltre è noto che per proteggersi bisogna saper attaccare.
Quindi non condivido gli atteggiamenti "questi siti non dovrebbero essere segnalati ecc. ecc."
Anche i coltelli da cucina possono essere usati per uccidere, eppure pare che non siano stati tolti dal commercio.
Inoltre fare un uso malizioso di eventuale codice in rete richiede conoscenze estremamente specialistiche, cioè non sono persone che si vanno a leggere la teoria dei buffer overflow.
Quella di cui parli tu non è ipocrisia ma oscurantismo.
Giocare con queste cose, con le cose che tu dici non debbano essere pubblicizzate, sono gli argomenti che la maggiorparte dei programmatori dovrebbe conoscere dopo le teorie della programmazione.
Lo sviluppo non è fatto solo dalla teoria ma anche dalla tecnica. E' questa è tecnica pura.
Se poi c'è qualcuno che crede che simili argomenti possano essere appresi a dovere con gli esempi deficienti di una rivista che usa male una funzione di libreria ... bhè ...
Lo scopo dichiarato di certi siti non è l'evidenziare certe falle nella sicurezza, ma il suggerire metodi per sfruttarle, quindi da questo punto di vista, a mio avviso, non sono accettabili
Bhè certo, se per te basta solo sapere che ESISTE un bug è un conto. Ma sappi che per creare un bugfix REALE si necessita di come un BUG si verifica. Per sapere COME si verifica bisogna capirne i principi e i funzionamenti. Da quì "il suggerimento su come sfruttarle". Solo sapendo come SFRUTTARLE si può capire come EVITARLE. Altrimenti chiunque si mette a programmare si mette a reinventare la ruota.
Recoil ha detto una cosa giusta. Ha detto che simili problemi pensava fossero risolti una volta per tutti. Ma se nessuno insegna COME FUNZIONANO in fondo le cose e quindi non impara a fondo COME EVITARLE, ci ritroviamo che tutte le generazioni future faranno sempre e solo gli stessi errori.
maxithron
20-08-2003, 14:35
Originariamente inviato da mjordan
Recoil ha detto una cosa giusta. Ha detto che simili problemi pensava fossero risolti una volta per tutti. Ma se nessuno insegna COME FUNZIONANO in fondo le cose e quindi non impara a fondo COME EVITARLE, ci ritroviamo che tutte le generazioni future faranno sempre e solo gli stessi errori.
Infatti! Soprattutto se si pensa che:
maxithron scrive un programma, un sistema operativo a un accidenti qualsiasi. Sarà pieno di bug ma va bene così.
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).
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 ;) )
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.
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. :D
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).
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
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.
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
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 ...
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 :rolleyes:
magari l'hanno scritto i programmatori di windows NT :D
Originariamente inviato da recoil
pensa che era segnalata come una funzione sicura su un documento che parlava di buffer overflow :rolleyes:
magari l'hanno scritto i programmatori di windows NT :D
:D :D
la discussione e' gia' finita? :(
Originariamente inviato da recoil
la discussione e' gia' finita? :(
Ringrazia gli oscurantisti :D
maxithron
22-09-2003, 13:28
Mi è venuto in mente questo post e vorrei che si riaprisse la discussione...
Come considerare che anche "gets" è una funzione "pericolosissima" ?
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
22-09-2003, 14:55
appunto.....eppure come strcpy è utilizzata tantissimo nelle applicazioni
maxithron
22-09-2003, 15:06
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?
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
22-09-2003, 16:19
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....
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
22-09-2003, 17:30
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
23-09-2003, 23:03
anche se è un pò vecchiotta è comunque un altro spunto di discussione(se volete...):
http://puntoinformatico.it/news/?idnews=224
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.