Re: dettagli attacco TCP & BGP

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

On Sat, 24 Apr 2004 16:19:31 +0200
Ed3f <ed3f@xxxxxxxxxxxx> wrote:


>Partiamo dai trucchetti usati da OpenBSD per ridurre il rischio:
>- usa porte random

Questo e'  un accorgimento intelligente e  sarebbe auspicabile vederlo
in tutte le implementazioni del TCP.

>- non usa window size giganti (a differenza di Cisco... vero misi ?)

Questa cosa mi  puzza. Non conosco gli internals di  OpenBSD ma non ha
molto  senso limitare  la receive  window anzi  direi che  questa cosa
sarebbe davvero stupida da fare (leggi sotto).

>- accetta solo  RST con il  seq.number esattamente sul  termine della
finestra

E questo non  e' compliant con RFC793. Deprecabile  oserei dire. Certo
non e' detto che tutto cio' che sia scritto negli RFC sia sacro ma per
curiosita' se  OpenBSD riceve  un RST  in finestra ma  non con  il SEQ
esatto ("reordering  happens" direbbe qualcuno) come  si comporta?  Lo
scarta  silenziosamente? Risponde  all'RST  con un  duplicate ACK?  In
entrambi i casi, i ragazzi di OpenBSD dovrebbero rendersi conto che il
ruolo  dell'RST  ne   risulterebbe  assolutamente  snaturato  e  forse
farebbero bene  ad andare a  rileggersi lo Stevens prima  ancora degli
RFC.  I discorsi  di questi  giorni ("io  risolvo il  problema ACKando
l'RST" e simili)  mi fanno venire in mente  certe classiche domande di
gente che vorrebbe  tirare via TIME_WAIT come stato  del TCP ritenendo
inutile aspettare 2MSL.  Come in quel caso, anche  questo mi arreca un
certo disturbo.  Tutto  andrebbe fatto con criterio e  qui il criterio
latita. Mi chiedo inoltre come mai si faccia un gran vociare su questo
argomento mentre leggendo i commenti di coloro che realmente conoscono
TCP non ci sono allarmismi. Un esempio su tutti e' il commento di Dave
Miller su netdev qualche giorno fa

"You need to guess the ports and source/destination addresses as well,
which is  why I don't consider  this such a  serious issue personally.
It  is  mitigated if  timestamps  are  enabled,  because that  becomes
another number you  have to guess. It is  mitigated also by randomized
ephemeral port selection"

Non mi sembra si sia allarmato piu' di tanto... eppure quando penso al
networking io penso a lui! ;)

>Il problema sorge  con tutti gli altri stack/os  in quanto nessuno di
>questi utilizza questi 3 accorgimenti rimanendo esposto ad un rischio
>maggiore.

Mi  permetto  di  contraddirti.  Se l'implementazione  e'  conforme  a
RFC793, il problema sorge se un attaccante e' in grado di

1-  inviare un RST con RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND
2-  prevedere la porta sorgente

Da cosa nasce il problema allora?

Dal fatto che  il punto 2- tradizionalmente e'  facilmente attuabile a
causa  della sequenzialita' nella  scelta della  source port  di quasi
tutte  le implementazioni  del  TCP (cosa  molto  facile da  rimuovere
comunque).

Perche' allora adesso e' esploso il problema? Semplicemente perche' se
ragioni su link che possono  sostenere gigabit/sec (non se ne vedevano
tanti  ai   tempi  di   ARPANET...)  le  finestre   **devono**  essere
grandi. Che senso  avrebbe (come affermi facciano in  OpenBSD e che mi
puzza non poco)  tenere un limite sulla cwnd ad  esempio di 100 mentre
il   path   potrebbe  sostenere   anche   1000   packets  in   flight?
Significherebbe non  usare la  banda disponibile e  la cosa  mi sembra
quanto meno  strana... come  a dire  mandiamo a monte  anni e  anni di
ricerca sul TCP congestion control... e  dal mio punto di vista non e'
bello se permetti! ;)

>Inoltre...
>
>Dries Schellekens ha postato il seguente commento:
>
>I  just  read  the  NetBSD  advisory  and  apparently  they  made  an
>additional  implementation  flaw,  which  made these  attacks  a  lot
>easier.
>
>"Additionally, the 4.4BSD stack from which NetBSD's stack is derived,
>did  not even  check  that a  RST's  sequence number  was inside  the
>window.  RSTs anywhere  to the  left of  the window  were  treated as
>valid."

Questo e'  il vero demonio.. ma  guarda caso RFC793 non  dice questo a
proposito degli RST..

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)

iD8DBQFAjARXpONIzxnBXKIRAsYSAKC5CKEIbx5Nk1u/SbqzklV55qnvGwCeMulv
3g8UziiQa9QiWP2Oa9P+Dv4=
=G2sW
-----END PGP SIGNATURE-----

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