Olimpo Informatico

[danieladaniela]

ho avuto una interessante discussione in merito con sverX che potete, se non l'avete ancora fatto, leggere qui



ho chiacchierato un po' in giro e vorrei riattizzare la discussione



eccovi un cut-and paste

ciao

d.





Note 240.1 antivirus programs and buffer overflow attacks 2 of 2

DAHMER::DANIELA 21 lines 5-JUL-2004 07:34



I have been having a discussion with some people about buffer overflow

and in general about the rolew of antivirus (which in my very humble

opinion are not a magic wand as someone likes to trade'em for). I havI

remembered a few good examples I read here awhile ago, and I believe I

read that also an antivirus, being of course no more than an ordinary

program run under that same OS, is in principle vulnerable to buffer

overflow attacks. Someone told me this is nonsense, because all an

antivirus does is scan the memory / disk or better, chunks of fixed

size of it, and it compares them with the signatures of known viruses.

my reply was that of course antivirus aren't just that, and proof of my

claim is that you can run an antivirus with parameters, so, obviously

there are input fields which in principle may be vulnerable to a buffer

overflow attack. I'd like to learn more, and of course to understand if

an antivirus program is vulnerable or not.





Thanks everyone!



Daniela









DAHMER::JTHOMPSON 8 lines 5-JUL-2004 13:52

-< All >-



Any program, on any OS, that allocates a contigious amount of memory,

and stores data in that memory, is subjectable to buffer overflows.



Even if a program does not allocate memory in this way, but simply uses

a data stack, and it would do so if it calls functions (unless written

in assembler) will use the stack. The stack itself, is an allocated

contigious amout of memory, and is vunerable to a buffer overflow.

(buffer meaning a contigious amount of allocated memory).

End of note





Note 240.2 antivirus programs and buffer overflow attacks 2 of 2

DAHMER::NORCA 24 lines 5-JUL-2004 21:22

-< All, but not equally. With examples. >-

While all OSs are vulnerable to buffer overflow attacks, some are much

less vulnerable than others. OpenBSD is the principle example of this.

Several techniques are used to minimize the possibility and impact of a

buffer overflow. First, OpenBSD uses a compiler extension called

ProPolice that protects the procedure stack from being overwritten

(briefly, it places an extra page between the data and stack space, and

sets it read only, so an attempt to write thru to the stack will

trigger an MMU fault). The second really powerful technique is not yet

available on all platforms, for hardware reasons, but it extremely

effective when available. It is known as W^X, write xor execute, and

does what it sounds like it should do. Each page of memory is (with

the help of the MMU, again) either writeable or executable, but not

both. This works great, because a buffer overflow attack depends on

being able to overwrite code space. On the other hand, it creates a

pseudo-Harvard architecture, so you can't run self-modifying code, but

really, this isn't the 80's, who does that (on a production system)

anymore? The other techniques in OpenBSD (there are far to many to

mention) are mostly concerneg with unpredictability, such as randomized

mapping of virtual address space onto physical address space (since an

overflow requires that you know how far to overwrite).



That was by no means exhaustive, but I hope it give you some idea.



-Cain

[SverX]

piacevole riattizzare la discussione



innanzitutto... sì, penso anche io che un antivirus inteso come un programma (immaginiamolo ancora non in memoria) che viene lanciato per es. (ma non limitandoci) da riga di comando con eventuali parametri _possa_ effettivamente essere soggetto ad un buffer/stack overflow per via di parametri opportunamente preparati "malignamente",per così dire.

Quindi concordo con la seconda parte del tuo intervento, e penso nessuno possa non concordare a sua volta.



Tornando alla parte "centrale" della discussione, però, continuo a ritenere che un antivirus (inteso come programma già "correttamente" caricato in memoria, programma che non offre servizi su porte IP e/o altre amenità tipo aree di memoria condivisa tra processi etc etc etc) non sia "vulnerabile", quantomeno nella sua normale attività di scansione di memoria / file. Ad esempio è facile che il dimensionamento del buffer di lettura per l'I/O sia fatto su una dimensione preimpostata e che la lettura del file avvenga per blocchi di quella stessa dimensione (... qui si potrebbe pensare di attuare un hack sulle API di I/O in modo da caricare più byte di quanti richiesti... ) e che quindi un buffer overflow dovuto ad un inserimento di una "stringa" in uno spazio non sufficiente a contenerla non sia davvero possibile.



Per quanto riguarda la possibilità di uno stack overflow... beh, alcuni antivirus utilizzano strane tecniche che cercano di simulare cosa farebbe un programma se eseguito. Certo è che se nell'antivirus vi fossero chiamate ricorsive ad una funzione interna (ad esempio per studiare diverse possibilità nel branch prediction) si potrebbe preparare ad hoc un file eseguibile solo allo scopo di confondere abbastanza l'antivirus, almeno fino a farlo arrivare a riempire e "crashare" lo stack (stack overflow)... e, a questo punto, forse anche fargli eseguire codice arbitrario, quello che abbiamo approntato.

Ma davvero, in mancanza di tali strane tecniche che solo alcuni antivirus hanno (e non so nemmeno perchè dato che tanto non hanno mai funzionato che io sappia... ) davvero direi che mandare in crash un programma che legge 1KB da 1 file per volta e vede se dentro c'è la parola "pippo" direi che è davvero impossibile...



la discussione continua... (?)

---

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

Edited by: SverX  at: 6/7/04 13:41

[ZapoTeX]

All'atto pratico, le conseguenze per utonti sono:

-quali antivirus evitare?

-lanciare l'antivirus prima di fare qualsiasi cosa che potebbe comprometterne i parametri di lancio (p.e. lanciarlo all'avvio)?



Se non ho capito nulla di quanto detto, mi scuso!

[Gateo]

Ricordo i vostri o forse altri interventi, e ne avevo tratto la

conclusione che win e linux soffrono di buffi overflow

perche' il problema e' nel linguaggio (C?) che e' stato usato

per creare gli stessi.

E, dall'alto della mia ignoranza mi e vi chiedo:

e perche' mai non cambiano codesto linguaggio con uno

piu' furbo, invece di costringere AMd e Intel Transmeta

a fare dei processori antibuffoverflow?

[SverX]

Quote:

---

ll'atto pratico, le conseguenze per utonti sono

---

no, non ci sono conseguenza per gli "utonti", all'atto pratico. quella in corso è una discussione che -per ora- potremmo definire quasi "accademica". Non parliamo di nessun antivirus particolare e nessun parametro di avvio particolare...

Quote:

---

Ricordo i vostri o forse altri interventi, e ne avevo tratto la conclusione che win e linux soffrono di buffi overflow perche' il problema e' nel linguaggio (C?) che e' stato usato per creare gli stessi.

---

No, non è un problema legato alla scelta del linguaggio di programmazione... direi che è più legato alla scelta del programmatore... nel senso che devi prenderne uno buono per scrivere codice buono

---

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

[danieladaniela]

buonasera Claudio



tu scrivi

Quote:

---

alcuni antivirus utilizzano strane tecniche che cercano di simulare cosa farebbe un programma se eseguito.

---

questo mi sembra il classico esempio del coltello affilato, utilizzabile per tagliare il pane oppure per far(si) del male. Se la macchina piri con sistema operativo pacchio fa girare un simpatico simulatore di una architettura epsilon con sistema operativo zero, e li' sopra viene fatto il lavoro che dici tu, e' direi un'ottima mossa. Anche qualora win.... ehm volevo dire, il s.o. simulato, dovesse crashare, il funzionamento di piripacchio non subirebbe alcun intoppo, e il suo padrone eventualmente fara' ripartire il simulatore per controllare il prossimo presunto virus. Anzi mi sembra che sia stato fatto, come ho gia scritto: qualcun altro se ne ricorda? ("antivirus" per qualche unixstation che girava su vax/vms)

.... certo che se piripacchio e epsilonzero sono la stessa cosa, good luck....



Tornando alla parte centrale della discussione, siamo tornati mi sembra alla mia domanda: e' possibile sabotare uno strings di un dump? (intendo con strings un programma in qualche dialetto unix che fa quello che dici tu: strings pippo cerca "pippo") Nota che un antivirus e' sicuramente piu' vulnerabile. Prima di ammettere che e' impossibile crasharlo, io credo che bisognerebbe vederlo in faccia. Mi spiego. Un comando cosi' si puo' scrivere in assembler: in quel caso sappiamo esattamente cosa accade e il lavoro sara' blindatissimo. Ma sappiamo bene che porzioni notevoli dei sistemi operativi non sono scritte in assembler, e gli antivirus direi tantomeno. Come sara' fatto il codice che ne viene fuori? Sara' inaffondabile come il titanic? Sara' un pericolo vagante come un iceberg? Possiedera' entrambe le caratteristiche? A me rimane il dubbio.



Daniela

[danieladaniela]

Claudio pensavo a quello che hai scritto

Quote:

---

No, non è un problema legato alla scelta del linguaggio di programmazione... direi che è più legato alla scelta del programmatore... nel senso che devi prenderne uno buono per scrivere codice buono

---

fatta salva la seconda parte su cui siamo tutti d'accordo ) pensavo, forse _e'_ legato almeno in parte alla scelta del linguaggio.... ma in maniera inestricabile... passando anche attraverso il compilatore (o l'interprete)



mi pare difficile - per me che sono ignorante - dare indicazioni su caratteristiche di un linguaggio di programmazione "meno adatto" a questo genere di exploits... ma forse e' possibile...



o forse e' ora di andare a dormire eheheheh



d.

[SverX]

Ciao Daniela-per-2

Quote:

---

Tornando alla parte centrale della discussione, siamo tornati mi sembra alla mia domanda: e' possibile sabotare uno strings di un dump? (intendo con strings un programma in qualche dialetto unix che fa quello che dici tu: strings pippo cerca "pippo" Nota che un antivirus e' sicuramente piu' vulnerabile. Prima di ammettere che e' impossibile crasharlo, io credo che bisognerebbe vederlo in faccia.

---

Forse sto iniziando a capire il discorso



Allora cerchiamo di porre basi comuni fisse per il discorso... ad esempio mi piacerebbe capire se con "sabotare" intendi " utilizzare un processo apposito che interferisca con il processo 'vittima' " oppure qualcosa altro. Se intendi quello che ho scritto... beh, allora penso proprio di sì... ad esempio si può crashare il processo 'vittima' manipolando le API di I/O come già accenavo nel post precedente...



ma... tornando all'inizio del 3d... la domanda fondamentale non era qualcosa del tipo: "è possibile scrivere un file che mandi in crash un antivirus quando questo lo 'esamina'?"



... era questo il punto della discussione o sto facendo confusione?



Comunque ho chiacchierato con qualche collega a riguardo e -alla fine- un suggerimento curioso l'ho anche avuto. Al momento non sono (siamo) in grado di fare un test a riguardo ma non escludo ci potrebbero essere risultati interessanti. Il suggerimento riguarda la creazione di un file che si presenti come un programma (meglio se lo è davvero, è anche più facile farlo) e che contenga al suo interno tanti tanti tanti pezzettini di virus che siano sicuramente riconosciuti dall'antivirus. Non sapendo esattamente come il processo antivirus lavora (e non tutti lavoreranno alla stessa maniera, ovvio) può anche darsi che il trovare un eccessivo numero di 'hit' all'interno di un eseguibile vada in qualche modo a riempire una struttura dati statica (un array, per dire) e a travaricarne i limiti, possibilmente crashando il processo. Ovviamente può anche darsi che al primo 'hit' il file venga zappato via e fine, ovvio...



Qualcuno è in grado di fare un file/programma di questo tipo? Poi potremmo sperimentarlo con tutti gli AV a disposizione...

---

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