[Linguaggi vari] I bug: trovarli e sfruttarli

[~FullSyst3m~]

Leggo sempre di bug che vengono scoperti e falle che vengono sfruttate: da programmi, da virus ecc ecc. Ho pensato cosi, dopo l'ennesimo articolo letto a riguardo, di aprire questo topic.
Si tirano in ballo sempre hacker e ricercatori come le persone che scoprono e sfruttano i bug. Ma come si trova un bug? Come si sfrutta? Che conoscenze si devono avere?

[cdimauro]

Ci vuole parecchia esperienza.

[- Lke -]

Provo a risponderti io in base a quel poco che so in attesa di qualcuno più esperto.
Saprai che ogni "cosa" che usi quando crei un programma è stata concepita per una determinata scopo. Molto banalmente, in questo caso, potresti sfruttare "maliziosamente" questa "cosa" per scopi diversi. Se la "cosa" è sufficientemente potente modificando l'uso che ne viene fatto nel programma potresti intaccare la sicurezza o la stabilità del sistema ecc.

Un esempio stupidissimo? Un ciclo infinito:
Diciamo che all' interno del tuo programma hai un ciclo che ha una determinata condizione che gli fa eseguire un numero di cicli appunto finito. Se questa condizione è regolata da una variabile, e tu per qualche motivo ai accesso a questa variabile, potresti farlo diventare senza fine.

Correggetemi se sbaglio.

[~FullSyst3m~]

Originariamente inviato da cdimauro

Ci vuole parecchia esperienza.

Questo era scontato. Ma come conoscenze? Come strumenti di lavoro? Come procedimento? Soprattutto nei programmi closed source credo sia ancora più difficile che nei programmi open.

Provo a risponderti io in base a quel poco che so in attesa di qualcuno più esperto.
Saprai che ogni "cosa" che usi quando crei un programma è stata concepita per una determinata scopo. Molto banalmente, in questo caso, potresti sfruttare "maliziosamente" questa "cosa" per scopi diversi. Se la "cosa" è sufficientemente potente modificando l'uso che ne viene fatto nel programma potresti intaccare la sicurezza o la stabilità del sistema ecc.

Un esempio stupidissimo? Un ciclo infinito:
Diciamo che all' interno del tuo programma hai un ciclo che ha una determinata condizione che gli fa eseguire un numero di cicli appunto finito. Se questa condizione è regolata da una variabile, e tu per qualche motivo ai accesso a questa variabile, potresti farlo diventare senza fine.

Correggetemi se sbaglio.

Questo si sa, è la base, io intendevo nello specifico.

[- Lke -]

Ma come conoscenze? Come strumenti di lavoro? Come procedimento?

Per le conoscenze direi le stesse o di più di chi ha fatto il programma.
Come strumenti di lavoro il programma stesso e le conoscenze.
Come procedimento direi sperimentale: studi il programma ed immagini come potrebbe essere stato realizzato, se conosci i limiti del codice puoi arrivare a sfruttarli.

[Tommo]

Nello specifico credo ci voglia una conoscenza pazzesca del campo, esperienza, e bisogna studiarsi un singolo programma per molto tempo... dato che ogni bug, per come si manifesta, è unico... non credo che ci sia un "corso di studi" per sapere sta roba, ci vuole solo una solida base ed esperienza come hacker, IMHO.

[~FullSyst3m~]

Originariamente inviato da Tommo

Nello specifico credo ci voglia una conoscenza pazzesca del campo, esperienza, e bisogna studiarsi un singolo programma per molto tempo... dato che ogni bug, per come si manifesta, è unico...

Direi anche conoscenze di assembly e linguaggi di basso livello, questo sicuramente.

[Tommo]

E non a caso gli esperti di sicurezza mi risultano essere pagati decisamente bene

[~FullSyst3m~]

Originariamente inviato da Tommo

E non a caso gli esperti di sicurezza mi risultano essere pagati decisamente bene

A proposito di esperti di sicurezza. Le conoscenze che hanno quali sono? A volte vengono mitizzati.

[fero86]

Originariamente inviato da cdimauro

Ci vuole parecchia esperienza.

assieme ad un po' di originalitá. io una volta ho scritto in C (perdonamelo, ero ancora inesperto e non capivo che andava scritto in C++ ^^) un piccolo tool per Windows per esaminare lo stack di un altro processo e trovare potenziali buffer overflows; praticamente non faceva altro che monitorare lo stack (o gli stack) tramite dei page guards in attesa che delle sequenze binarie predefinite ci venissero scritte; l'utente del tool quindi poteva impostare come sequenza binaria una stringa che poi avrebbe ad esempio scritto da qualche parte nel programma per verificare se quella scritta andava a finire sullo stack.

non era un granché come tool perché non tutti i dati che finiscono in quel modo sullo stack sono potenziali buffer overflows: nelle ultime revisioni del C infatti é possibile allocare sullo stack array a dimensione variabile. d'altra parte quando é stato inventato il DEP, che Windows supportava giá da prima che esistesse, il mio tool ha avuto il colpo di grazia e l'ho buttato

peró il principio rimane: enorme esperienza in fatto di programmazione di sistema unita ad un pizzico di fantasia e creativitá.

edit - a proposito, per la serie "Linux é il sistema operativo dei programmatori": su Linux quel tool sarebbe stato irrealizzabile, o quantomeno non realizzabile in maniera ragionevole; se mi sbaglio provatemelo.

[fero86]

Originariamente inviato da - Lke -

Per le conoscenze direi le stesse o di più di chi ha fatto il programma.

tipicamente molte di piu, altrimenti chi ha fatto il programma non avrebbe messo il bug.

Come strumenti di lavoro il programma stesso e le conoscenze.

piu magari un editor esadecimale, un disassemblatore, un buon debugger, e qualche tool sviluppato ad hoc (vedi esempio nel mio post precedente).

[~FullSyst3m~]

Originariamente inviato da fero86

assieme ad un po' di originalitá. io una volta ho scritto in C (perdonamelo, ero ancora inesperto e non capivo che andava scritto in C++ ^^) un piccolo tool per Windows per esaminare lo stack di un altro processo e trovare potenziali buffer overflows; praticamente non faceva altro che monitorare lo stack (o gli stack) tramite dei page guards in attesa che delle sequenze binarie predefinite ci venissero scritte; l'utente del tool quindi poteva impostare come sequenza binaria una stringa che poi avrebbe ad esempio scritto da qualche parte nel programma per verificare se quella scritta andava a finire sullo stack.

non era un granché come tool perché non tutti i dati che finiscono in quel modo sullo stack sono potenziali buffer overflows: nelle ultime revisioni del C infatti é possibile allocare sullo stack array a dimensione variabile. d'altra parte quando é stato inventato il DEP, che Windows supportava giá da prima che esistesse, il mio tool ha avuto il colpo di grazia e l'ho buttato

peró il principio rimane: enorme esperienza in fatto di programmazione di sistema unita ad un pizzico di fantasia e creativitá.

edit - a proposito, per la serie "Linux é il sistema operativo dei programmatori": su Linux quel tool sarebbe stato irrealizzabile, o quantomeno non realizzabile in maniera ragionevole; se mi sbaglio provatemelo.

Menomale che eri ancora inesperto

tipicamente molte di piu, altrimenti chi ha fatto il programma non avrebbe messo il bug.

Non credo che si possa fare di tutta l'erba un fascio. Non è detto che debba avere molte più conoscenze di chi ha scritto il programma eh.

piu magari un editor esadecimale, un disassemblatore, un buon debugger, e qualche tool sviluppato ad hoc (vedi esempio nel mio post precedente).

Ci vogliono tanta esperienza e studio in pratica. Come in tutte le cose del resto.

[Vincenzo1968]

Sui virus, su come agiscono e come s'implementano, due bei libri puoi scaricarli da qui:

http://vx.netlux.org/lib/vml00.html

http://vx.netlux.org/lib/vml01.html



P.S. Occhio: se scarichi il codice sorgente, il tuo antivirus dovrebbe segnalarti la presenza di un bel po' di virus. Se compili i sorgenti e li mandi in esecuzione, avrai il computer infettato. Scarica solo i libri

[fero86]

quei libri sono troppo vecchi, ritengo che non siano piu validi; gli ho dato un'occhiata e in uno ho trovato prima un appendice che costituisce un surrogato di RBIL (lol) e poi un capitolo che spiega come infettare un EXE... col vecchio formato!! (stra-lol)
per non parlare di quell'altro, dove a una certo punto ho visto un capitolo relativo a COM; allora ho pensato "ah, ma forse solo il primo era vecchio, quest'altro é aggiornato"; vado a leggere... parlava dei files COM, quelli con estensione .com, gli eseguibili senza headers insomma, non il Component Object Model

saranno stati anche estremamente validi nella loro epoca, ma leggendoli oggi ci infetti al massimo un 486

PS: e non credo che l'antivirus segnali alcunché nel vedere quei virus

[Vincenzo1968]

Originariamente inviato da fero86

quei libri sono troppo vecchi, ritengo che non siano piu validi; gli ho dato un'occhiata e in uno ho trovato prima un appendice che costituisce un surrogato di RBIL (lol) e poi un capitolo che spiega come infettare un EXE... col vecchio formato!! (stra-lol)
per non parlare di quell'altro, dove a una certo punto ho visto un capitolo relativo a COM; allora ho pensato "ah, ma forse solo il primo era vecchio, quest'altro é aggiornato"; vado a leggere... parlava dei files COM, quelli con estensione .com, gli eseguibili senza headers insomma, non il Component Object Model

saranno stati anche estremamente validi nella loro epoca, ma leggendoli oggi ci infetti al massimo un 486
...

Si sono un po' vecchi ma non m'è riuscito di trovare niente di più aggiornato. Sempre meglio che niente

Originariamente inviato da fero86

...
PS: e non credo che l'antivirus segnali alcunché nel vedere quei virus

Io ho provato a scaricare i sorgenti e NOD32 mi segnala la presenza di virus.

[~FullSyst3m~]

Originariamente inviato da Vincenzo1968

Si sono un po' vecchi ma non m'è riuscito di trovare niente di più aggiornato. Sempre meglio che niente



Io ho provato a scaricare i sorgenti e NOD32 mi segnala la presenza di virus.

Ecco perchè, usi NOD32

[nico159]

edit - a proposito, per la serie "Linux é il sistema operativo dei programmatori": su Linux quel tool sarebbe stato irrealizzabile, o quantomeno non realizzabile in maniera ragionevole; se mi sbaglio provatemelo.

Prima di tutto cosa significa un OS dei programmatori?
Comunque Valgrind

[~FullSyst3m~]

Originariamente inviato da nico159

Prima di tutto cosa significa un OS dei programmatori?
Comunque Valgrind

Si, infatti. Che significa? Lo volevo chiedere anche io.
Forse si riferisce al fatto che molti lo considerano un OS che usano solo i programmatori.

[fero86]

Originariamente inviato da nico159

Prima di tutto cosa significa un OS dei programmatori?

c'é un famoso luogo comune, si dice (o almeno si diceva) che Linux sia stato fatto dai programmatori per i programmatori, e solo perché qualunque distribuzione include di default la GCC e una buona shell

Comunque Valgrind

che io sappia Valgrind funziona solo se un programma é stato compilato appositamente affinché possa funzionare, non funziona affatto con programmi giá compilati.

[eraser]

Gli ingredienti che servono sono:

- n°1 conoscenza della gestione dello stack/heap
- n°1 conoscenza di assembly
- n°1 conoscenza di linguaggi di programmazione
- n°1 familiarità con disassembler e debugger
- fantasia e un pò di fortuna Q.B