Vista sembra avere una gestione diversa per l'aggiornamento gratuito della cache ARP.. diversa da quella di XP e diversa da quanto indicato nell'RFC 826.


L'RFC826 dice che la cache ARP dovrebbe essere aggiornata nel seguente modo:

Per qualsiasi pacchetto ARP che arrivi sull'interfaccia di rete di un host, indipendentemente dal fatto che sia una richiesta o una risposta, che arrivi in via diretta o via ethernet broadcast, o che, nel caso di risposta, sia stato richiesto oppure no:

A) Se l'ip arp sorgente è già nella cache, aggiorno il mac nella arp-table
B) Se sono il destinatario del pacchetto (no broadcast) e non conosco l'ip sorgente (non ho aggiornato in A) aggiungo l'associazione ip-mac nella arp-table

In pratica se l'ip è già nella cache l'aggiorno sempre, se non c'è, creo la voce solo se il destinatario del pacchetto sono io (no broadcast).

Nel caso di Vista premetto che non ho avuto la possibilità di provare sul campo causa mancanza del suddetto OS.

In ogni caso... prendendo come riferimento l'appendice V di questo documento (pagina 36):
http://www.symantec.com/avcenter/ref...urface_RTM.pdf
si evince che:

1) Nessuna voce viene creata nella cache in seguito ad arp reply non richiesti. Questo avviene indipendentemente dal fatto il pacchetto sia destinato all'host o arrivi via broadcast.

2) Un ARP reply non richiesto aggiorna (sovvrascrive) la cache solo se esiste già una voce nell'ARP table. Questo avviene sia nel caso il pacchetto sia destinato all'host sia nel caso arrivi via broadcast.

3) Una voce viene creata solo in seguito ad una richiesta esplicita (ARP request) e solo nel caso l'ARP reply sia destinato all'host (no broadcast)


In sostanza sembra che per avvelenare la cache ARP di Vista questa debba già contenere una voce per quell'IP.
Una tecnica simile è adottata da Solaris.
Il problema dovrebbe essere facilmente aggirabile obbligando l'host ad eseguire una ARP request che gli permetta di creare la voce per l'ip di interesse. A tale scopo dovrebbe sufficiente inviare un pacchetto ICMP echo request con IP mittente "spoofato" uguale a quello dell'ip che si vuole attaccare.
A questo punto è possibile avvelenare la voce relativa a quell'ip.

Seconda possibilità è vincere una corsa sulla risposta ad una evetuale ARP request da parte dell'host. Direi che è più semplice l'opzione precedente.