Re: Vulnerability Issues in TCP

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sat, 24 Apr 2004 17:18:42 -0700
Raistlin <raistlin@xxxxxxxxx> wrote:

>Angelo Dell'Aera wrote:

>> Ora da quel  che mi sembra di leggere,  RFC793 parla chiaro (pagina
>> 37).  Se l'RST non e'  valido non deve sortire effetti sul receiver
>> e in piu' deve essere silenziosamente droppato (pagina 69).

>Si', ma il  problema e' che tu l'RST lo  puoi piazzare dovunque nella
>finestra di connessione, quindi  abbatti la difficolta' di indovinare
>il numero di  sequenza. La soluzione e' accettarlo  SOLO SE sull'edge
>della finestra, che e' dove dovrebbe ragionevolmente stare.

Come scrivevo in un'altra mail il  vero problema e' : se ricevi un RST
che non si trova su RCV.NXT  ma il cui SEQ e' nella finestra [RCV.NXT,
RCV.NXT  + RCV.WND]  che fai?  Scartarlo  e' non  corretto perche'  il
sender potrebbe  aver spedito altri  pacchetti che sono stati  persi o
semplicemente  hanno subito  reordering.  Quel pacchetto  e' valido  e
quindi  scartarlo sarebbe semplicemente  errato. Inviare  un duplicate
ACK e'  il demonio e su questo  mi pare siamo d'accordo.  A quel punto
che fare? Personalmente non  vedo alternative al comportamento attuale
se si vuole garantire una coerenza di fondo del protocollo.

>> Avendo sotto mano solo i sorgenti  di Linux, posso dire che esso e'
>> compliant con RFC793.

>Si' ma non previene l'attacco per la ragione di cui sopra.

IMHO la cosa migliore che si puo' fare per limitare la possibilita' di
riuscita dell'attacco sarebbe attuare due accorgimenti :

1-  randomizzazione della source port 
2-  abilitare sempre  i timestamp  anche per  i pacchetti  RST.  A tal
    proposito RFC1323 recita

  "It is recommended that RST segments NOT  carry timestamps,  and that 
   RST segments be acceptable regardless of their timestamp. 
   Old duplicate RST segments should be exceedingly unlikely, and their 
   cleanup function should take precedence over timestamps."

   Se si  rimuove  questa  raccomandazione,  oltre  alla  finestra,  e'
   necessario indovinare anche il timestamp e la cosa si  fa molto piu'
   difficile. 


Regards.


- --

Angelo Dell'Aera 'buffer' 
Antifork Research, Inc.	  	http://buffer.antifork.org

PGP information in e-mail header


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAjQqLpONIzxnBXKIRAg4FAKCtfP0NGVu5ZiUNaxc5VEcRYhT0bgCfQShw
7/gX3qNZQHKccnuKplIWd3I=
=AbR/
-----END PGP SIGNATURE-----

________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List