Olimpo Informatico

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

Caro SverX

dato un processo perfettamente rispettabile, per esempio un processo di sistema, o anche un antivirus che gira, esso "inghiotte" dei dati che gli vengono offerti in input. Questi dati possono essere preparati con malizia, e indurre il rispettabile processo che funziona perfettamente e che ha i proprie (bassi) privilegi ad eseguire istruzioni, diciamo, non previste, le quali come ormai dovresti sospettare andranno a fare tutto il resto.

Ho visto un bell'esempio di questo su VMS (se non e' blindato quello li'!!!) non fa niente di male, scrive solo "Box was hacked". Se vuoi posso provare a ripescarlo, mi ci vorra' un po' di tempo pero'.

ciao

d.

SverX

Cara DanielaX2,

Quote:
dato un processo perfettamente rispettabile, per esempio un processo di sistema, o anche un antivirus che gira, esso "inghiotte" dei dati che gli vengono offerti in input.

Verissimo.

Quote:
Questi dati possono essere preparati con malizia, e indurre il rispettabile processo che funziona perfettamente e che ha i proprie (bassi) privilegi ad eseguire istruzioni, diciamo, non previste, le quali come ormai dovresti sospettare andranno a fare tutto il resto.

Capisco che ti vuoi riferire ai buffer overflow / stack smash e similari. Conta che però questo avviene quando i dati

A) sono "più" del previsto ( buffer overflow classico)

B) vengono "interpretati" (come l'header di una BMP) e se contengono "valori preparati con malizia" allora possono dar luogo nuovamente a buffer overflow / stack smash con successiva -possibile- esecuzione di codice "maligno".

Però un antivirus funziona -alla base- come un programmino di ricerca di sottostringhe: le "signature" dei virus sono le stringhe "cercate" e i file, uno dopo l'altro, sono le stringhe in cui cercare. E tali dati non vengono "interpretati" nè vengono forniti in sovrannumero (è l'antivirus stesso che li legge...) e quindi un buffer overflow non è possibile. Davvero.

Quote:
Ho visto un bell'esempio di questo su VMS (se non e' blindato quello li'!!!) non fa niente di male, scrive solo "Box was hacked". Se vuoi posso provare a ripescarlo, mi ci vorra' un po' di tempo pero'.

Conosco pochissimo VMS, non sarei in grado di capirlo. Se puoi trovare un esempio che calzi su piattaforma Intel (Windows o Linux, come vuoi) sarò lieto di discuterne ancora.

In generale, comunque, il buffer overflow e la successiva esecuzione di codice "maligno" avviene o attaccando un servizio (vedi SMTP o FTP, tanto per citarne due che esistono sia su Windows che su Linux - Unix) o creando un file che inganni il programma che lo dovrà aprire (aprire in senso di interpretare) come, ad esempio, il recente (non recentissimo) buffer overflow che colpisce WinAmp attraverso il tag ID3 degli MP3... l'ho provato personalmente ed è vero. Ma WinAmp l'ha corretto e ha rilasciato la patch dopo 2 giorni...

Quote:
ciao

d.

Ciao

Ci sono 10 tipi di persone. Quelle che capiscono l'aritmetica binaria... e poi gli altri 9 non ho capito.

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

aggiungo un link appena segnalato da pc facile

www.theregister.co.uk/2004/05/28/itanic_virus/

beh quello che penso io dell'itanium... oh.... lo chiamano itanic anche su theregister... lasciamo stare, ma tornando agli antivirus, vi pare ragionevole che ci sia bisogno di un esempio per sapere che i 64 bit si possono infettare..... no comment....

d.

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

Caro SverX e' verissimo che questo tipo di attacco in genere colpisce smtp o ftp per comodita' (smtp e' ovunque); mi domando se siano possibili processi che ne sono immuni e come devono essere strutturati. Per portare all'estremo il tuo esempio mi chiedo se si puo' attaccare strings o comesichiama o dump o quelle cose li'.

ci penso

pensaci anche tu e poi se hai voglia ne riparliamo

grazie

daniela

SverX

Quote:
e' verissimo che questo tipo di attacco in genere colpisce smtp o ftp per comodita' (smtp e' ovunque)

più che altro perchè ci sono in giro ancora tanti server con servizi smtp e ftp di versioni notoriamente bacate (alcune da anni) ... certo che smtp è ovunque ma non sempre è bacato, intendo. Ovviamente valutando che il discorso degli open relay non sia contato come "baco" ...

Quote:
mi domando se siano possibili processi che ne sono immuni e come devono essere strutturati. Per portare all'estremo il tuo esempio mi chiedo se si puo' attaccare strings o comesichiama o dump o quelle cose li'.

Processi "immuni" magari non esistono... certo è che se nella programmazione si facesse più attenzione ai "bound check"... praticamente tutti i buffer overflow si basano sul fatto che qualcuno ha dichiarato un'array di n byte-caratteri-word-double etc (anche con n piuttosto grande) e poi -strano- arriva qualcuno che tenta di autenticarsi su un server SMTP usando una password di 6800 caratteri

E cosa intendi con "se si può attaccare strings o dump" non mi è chiaro...

Quote:
pensaci anche tu e poi se hai voglia ne riparliamo

è sempre un piacere

Quote:
daniela

claudio

Ci sono 10 tipi di persone. Quelle che capiscono l'aritmetica binaria... e poi gli altri 9 non ho capito.

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

ciao claudio e buona notte (mi ci vorrebbe proprio un caffettino)

il discorso si sta facendo tanto interessante quanto astratto (e parecchio al di la' delle cose che so) che forse andrebbe fatta una distinzione tra la cattiva programmazione, la quale come dici tu spiana la strada e serve su un vassoio d'argento la strategia da utilizzare per costruire in concreto un virus che "dirotti" un processo vulnerabile e in tal modo prenda il controllo di quella macchina, ed eventuali fatti teorici che ci assicurano che anche un "lavoro ben fatto" ha il suo tallone d'Achille (sperabilmente pero' difficilissimo da individuare).

Mi pare che possiamo schematizzare cosi' la situazione da noi descritta: sia data una certa macchina up and running che funziona bene. Lo sfidante ha la possibilita' di scrivere su disco dei dati arbitrari. L'obiettivo e' indurre la macchina ad eseguire una istruzione I del suo set di istruzioni.

E' questo che intendiamo? O e' una descrizione troppo debole in quanto cosi' si puo' bloccare la macchina ma non necessariamente prenderne il controllo? Pretendi che il virus possa far eseguire alla macchina una sequenza arbitraria di istruzioni?

d.

SverX

Quote:
l discorso si sta facendo tanto interessante quanto astratto (e parecchio al di la' delle cose che so) che forse andrebbe fatta una distinzione tra la cattiva programmazione, la quale come dici tu spiana la strada e serve su un vassoio d'argento la strategia da utilizzare per costruire in concreto un virus che "dirotti" un processo vulnerabile e in tal modo prenda il controllo di quella macchina, ed eventuali fatti teorici che ci assicurano che anche un "lavoro ben fatto" ha il suo tallone d'Achille (sperabilmente pero' difficilissimo da individuare).

anche ai migliori programmatori scappano errori... è per quello che ci sono gli utenti

Quote:
Mi pare che possiamo schematizzare cosi' la situazione da noi descritta: sia data una certa macchina up and running che funziona bene. Lo sfidante ha la possibilita' di scrivere su disco dei dati arbitrari. L'obiettivo e' indurre la macchina ad eseguire una istruzione I del suo set di istruzioni.

mmm... a parte il discorso dello scrivere su disco... inizialmente non mi interessa scrivere su disco ma nella memoria e fare sì che, in un modo o nell'altro, quei byte che ho infilato in memoria vadano in esecuzione. A quel punto scrivere sul disco è banale, no?

Quote:
E' questo che intendiamo? O e' una descrizione troppo debole in quanto cosi' si puo' bloccare la macchina ma non necessariamente prenderne il controllo? Pretendi che il virus possa far eseguire alla macchina una sequenza arbitraria di istruzioni?

Sì, il buffer overflow se sapientemente sfruttato può (e spesso accade) far eseguire alla macchina istruzioni specifiche fino a "prenderne il controllo" e non solo mandarla in crash...

... nell'esempio più stupido che mi viene in mente se "spingiamo" 100 MB in una funzione che aspetta una stringa di al massimo 127 caratteri avremo facilmente un buffer overflow... ma da dove proseguirà l'esecuzione del processo? Non è predicibile... ma è nella memoria comunque, no? E se riempiamo la memoria (o buona parte) di NOP con in coda il nostro codice malvagio... beh, abbiamo una probabilità, no?

Certo che riuscire a "deviare l'esecuzione" proprio dove abbiamo preparato il nostro codice...

Ah, spero questo intervento non sia giudicato come una esortazione a fare intrusioni. Hacking è bene, ma ognuno lo faccia sulle proprie macchine

ciao

Ci sono 10 tipi di persone. Quelle che capiscono l'aritmetica binaria... e poi gli altri 9 non ho capito.

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

Oh! sto qualche gg via dal pc e quasi non trovo piu' il thread sommerso da altri...

si', certo, disco e memoria sono la stessa cosa (memoria anzi e' un passaggio in meno)

si', andranno sistemati un bel po' di NOP per essere sicuri di centrare l'esecuzione dell'istruzione voluta... perche' non si potra', credo, mirare con tanta precisione...

mi ero ripromessa di passare questo thread a Dei piu' competenti di me misera mortale... vedro' di ricordarmene

:-)

Si', e' bene che ciascuno facchia hacking sulle proprie macchine....

d.

danieladaniela · Dio minore Registrato: 26/11/03 08:42 Messaggi: 615

Tornero' sull'argomento, spero, intanto ecco un

articoletto sul buffer overflow

ma non rovesciate il caffe'!!

D.