leggo spesso che le falle nei programmi inficiano la sicurezza di un sistema. Il dubbio che ho e' se i programmi devono essere necessariamente programmi che nel loro codice hanno a che fare con la rete internet. Io credo che sia cosi': bug in un programma con sezioni che interagiscono verso nodi remoti = rischio per il pc su cui corre.
Per fare un tavolo ci vuole un fiore.
E' ovvio che se il programma vulnerabile interagisce con la rete si palesa concretamente la possibilità di un attacco da remoto... in tal senso sarebbe possibile attaccare il sistema stando fisicamente altrove.
Considera però il seguente caso: hai un programma vulnerabile che non interagisce con la rete. Ma il sistema è comunque collegato in rete. Ciò significa che il programma vulnerabile non è direttamente attaccabile da una postazione remota.
Supponi che tale programma sia ad esempio un visualizzatore di immagini, di documenti pdf oppure un editor di testo come Word o un foglio di calcolo come Excel.
Dal punto di vista del funzionamento base tali programmi non hanno bisogno di comunicare con la rete.
Immagina ora di riceve via email, ma anche via chiavetta usb, una immagine, un pdf o un documento word etc...
Se il programma incaricato di aprire il file è vulnerabile è possibile che fornendo una versione "corrotta" del documento si possa innescare un processo nel programma vulnerabile che porti all'esecuzione di codice arbitrario stabilito da chi ha creato il documento.
Questo codice arbitrario potrebbe a sua volta instaurare un connessione verso il sistema dell'attaccante.
Come vedi il programma vulnerabile per sua natura non interagisce con la rete ma l'apertura di un documento da fonte non affidabile ha innescato un processo che coinvolge la rete. A questo punto il pirata può prendere il controllo della macchina attraverso il canale sulla rete che il malware contenuto del documento ha creato.
Come vedi una innocua immagine o un pdf che per loro natura non sono programmi ma semplici documenti hanno reso possibile l'infezione.
E' per questo motivo che le vulnerabilità di Adobe Reader, ad esempio, sono molto ricercate in un certo ambiente...
Leggi il REGOLAMENTO!
E' molto complicato, un mucchio di input e output, una quantità di informazioni, un mucchio di elementi da considerare, ho una quantità di elementi da tener presente...
Drugo
1) da quanto dici devo dedurre che il codice (la parte "corrotta") che innesca il processo di attivazione di altro codice nocivo sia criptato e annidato (assieme al codice da eseguire) all interno del file immagine o altro (ad esclusione dei file di testo). Ora io mi chiedo come sia possibile innestare un programma all interno del codice di una foto o di un pdf.. dovranno quindi esistere software per fare questo.. (so p.es. che si puo' nascondere una password in un file immagine)Originariamente inviata da Habanero
2) ma come e' possibile che un creatore di virus sappia quali sono i punti deboli di programmi innocui? cosa fa, si studia tutto il codice dell applicazione? e dove lo va a prendere? c'entrano per caso i software per disassemblare i prodotti commerciali? anche in questo caso credo che occorra comunque un notevole studio e dispendio di energie e tempo..
Ultima modifica di filips; 06-08-2014 a 20:41
Per fare un tavolo ci vuole un fiore.
Il discorso è tanto semplice quanto difficile da spiegare, se non disponi di basi di programmazione.1) da quanto dici devo dedurre che il codice (la parte "corrotta") che innesca il processo di attivazione di altro codice nocivo sia criptato e annidato (assieme al codice da eseguire) all interno del file immagine o altro (ad esclusione dei file di testo). Ora io mi chiedo come sia possibile innestare un programma all interno del codice di una foto o di un pdf.. dovranno quindi esistere software per fare questo..
Il problema sorge quando in un visualizzatore di immagini (ad esempio) ci sono dei bug che consentono l'esecuzione di codice arbitrario.
Un malintenzionato può sfruttare questi bug, per fare in modo che sia lo stesso visualizzatore ad eseguire il codice presente sull'immagine. Questo discorso può essere applicato potenzialmente ad ogni programma che si occupa di aprire file.
In generale, per alterare un file in questo modo ci si serve di un linguaggio di programmazione, per realizzare script ad hoc.
Non esiste un metodo universale ma, in generale, per scoprire un bug di questo tipo, si cerca in primis di alterare il formato del file, per testare la presenza di eventuali errori. Solo successivamente si passa, se c'è bisogno, ad un'analisi più approfondita.2) ma come e' possibile che un creatore di virus sappia quali sono i punti deboli di programmi innocui? cosa fa, si studia tutto il codice dell applicazione? e dove lo va a prendere? c'entrano per caso i software per disassemblare i prodotti commerciali? anche in questo caso credo che occorra comunque un notevole studio e dispendio di energie e tempo..
Si chiama steganografia e non centra nulla.(so p.es. che si puo' nascondere una password in un file immagine)
Experience is what you get when you don’t get what you want
@Xaratroom...capisco che l'argomento sia complesso, ma ecco una curiosità che forse si può risolvere: da quel che dici sembra che il bug essenziale debba risiedere nell'apertura di file... ciò significa che in fase di programmazione il programmatore deve tener conto di aperture indiscriminate? Mi chiedo anche come possa essere presente codice difettoso che permetta esecuzioni arbitrarie... E perche alterando il formato si possa individuare un bug (con cosa si attuerbbe tale alterazione?)
Per fare un tavolo ci vuole un fiore.
Non necessariamente. Io l'ho messa giù nel modo più semplice che mi veniva. Un bug altro non è che un errore di programmazione... può risiedere ovunque e non è detto che possa essere sfruttato direttamente.
In fase di programmazione non si dovrebbe lasciare nulla al caso.
Vengono chiamati errori di programmazione per un motivo. Purtroppo (o per fortuna) i software vengono scritti ancora dalle persone.
Riprendiamo l'esempio di prima.
Mettiamo il caso che il formato del file sia il seguente:
* 1 intero da 0 a 255 per il colore rosso
* 1 intero da 0 a 255 per il colore verde
* 1 intero da 0 a 255 per il colore blu
* 1 intero di controllo che indica la terminazione del pixel corrente
Quindi avremo un file strutturato in questo modo: 1,2,3,-1,2,3,4,-1,... ovvero il primo pixel è di colore r=1,g=2,b=3 il secondo r=2,g=3,b=4 etc etc.
Se la routine che si occupa di leggere questo formato, fosse strutturata nel seguente modo:
Alterando il formato file (rimuovendo un -1 e generando quasi sicuramente un crash dell'applicazione) potremmo accorgerci della presenza di questo bug.codice:/*In realtà nessun programmatore sano di mente, farebbe mai qualcosa di simile*/ void printNextPixel(int* pixels) { int buffer[3]; int i = 0; //Bug while(pixel[i] != -1) { //Finchè non raggiungo l'intero di controllo //Copio il pixel nel buffer buffer[i] = pixel[i]; } print(buffer[0], buffer[1], buffer[2]); }
Experience is what you get when you don’t get what you want
@xaratroom...ne approfitto visto che su libri di programmazione non ho mai trovato niente in materia virus e sicurezza, ad eccezione guida linguaggi .net in cui si tratta il browsing security. Ma di virus in quanto tali mai niente. Allora, il tuo esempio finale è molto eloquente, tuttavia
1) capisco da quanto hai detto che i bug che si possono prendere in considerazione sono svariati (non credo però tutti)
2) riferendomi al bug che hai esemplificato in quel codice, cioè a un impallamento dell'applicazione nel caso di file non conforme, non riesco proprio a vedere il nesso col discorso codice malizioso; in altre parole non capisco come risulti possibile sfruttare un exploit sul tipo di falla in run-time del tipo indicato
Per fare un tavolo ci vuole un fiore.
La maggior parte dei bug (quelli più diffusi perlomeno) viene generata da una serie di errori concettuali ricorrenti e noti.
Un file immagine "malizioso" può sovrascrivere l'indirizzo di ritorno della funzione (presente sullo stack) e modificare "a piacimento" il normale flusso del programma. Se vuoi un esempio di vulnerabilità da buffer overflow, il più celebre esempio che mi viene in mente è lo shellcode.
Vorrei fare un ultimo esempio usando la funzione printNextPixel (attenzione che nel while mancava l'incremento dell'indice):
Se vai a sostituire l'indirizzo presente nell'array pixels, con un qualsiasi indirizzo valido, potrai modificare il flusso dell'applicazione.codice:#include <cstdio> using namespace std; int pixels[8] = {123, 123, 123, 3/*Valore di i*/, 1, 1, 0x4005c6/*indirizzo del main*/, -1}; void printNextPixel(int* pixels); void wellcome(); main() { //Saluto wellcome(); //Stampo i pixel printNextPixel(pixels); } void printNextPixel(int* pixels) { int buffer[3]; int i = 0; while(pixels[i] != -1) { buffer[i] = pixels[i]; i++; //Questo mancava mannaggia alla miseria } //print(buffer[0], buffer[1], buffer[2]); } void wellcome() { printf("Hello the main address is: %p\n", &main); }
Io ho inserito l'indirizzo del main realizzando una sottospecie di chiamata ricorsiva.
test.jpg
Le informazioni necessarie ad un programmatore terminano qui. Spero che tutto questo possa bastare a soddisfare la tua curiosità, perché vorrei evitare di essere calciorotato da Habanero
Ultima modifica di Xaratroom; 22-08-2014 a 10:06
Experience is what you get when you don’t get what you want
@xaratroom...leggo solo ora: complimenti, ottimo esrmpio! In pratica si può indirizzare dove si vuole sfruttando la falla! Questo è il primo esempio effettivo che vedo, al di là delle solite presentazioni a sfondo divulgativo del fenomeno
Ricordo che nelle regole del forum è fatto divieto postare ecc., ma a scopo puramente didattico o per curiosità intellettuale mi piacetebbe trovare un testo o documento web in cui sia delineata quella serie di errori concettuali ricorrenti e moti
Per fare un tavolo ci vuole un fiore.
@xaratroom...leggo solo ora: complimenti, ottimo esempio! In pratica si può indirizzare dove si vuole sfruttando la falla! Questo è il primo esempio effettivo che vedo, al di là delle solite presentazioni a sfondo divulgativo del fenomeno
Ricordo che nelle regole del forum è fatto divieto postare ecc., ma a scopo puramente didattico o per curiosità intellettuale mi piacetebbe trovare un testo o documento web in cui sia delineata quella serie di errori concettuali ricorrenti e noti
Per fare un tavolo ci vuole un fiore.
Permessi di invio
Rispondi quotando