Re: Vulnerability Issues in TCP

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

On Tue, 20 Apr 2004 20:37:46 +0200
"marco misitano" <misi@xxxxxxxxx> wrote:

>The vulnerability described  in this advisory affects implementations
>of  the Transmission  Control  Protocol (TCP)  that  comply with  the
>Internet  Engineering  Task Force's  (IETF's)  Requests For  Comments
>(RFCs) for  TCP, including RFC  793, the original  specification, and
>RFC 1323, TCP Extensions for High Performance.
>
>The  issue  described  in  this  advisory is  the  practicability  of
>resetting  an  established TCP  connection  by  sending suitable  TCP
>packets with the RST (Reset) or SYN (Synchronise) flags set.
>
>The Border  Gateway Protocol (BGP)  is judged to be  potentially most
>affected by this vulnerability.


Mi sono mantenuto  per troppo tempo perche' tale e  tanta e' la voglia
di commentare questa ennesima "scoperta dell'acqua calda"... ma adesso
non  mi  trattengo  piu'.  Mi  riaggancio  alle  considerazioni  fatte
dall'ottimo Stefano Zanero esprimendo la mia personalissima opinione.

Ma andiamo con  ordine. In generale partire dagli  RFC fa sempre bene.
Facciamo riferimento quindi a RFC793.

  (pagina 37)

Reset Processing

  In all states except SYN-SENT, all reset (RST) segments are validated
  by checking their SEQ-fields.  A reset is valid if its sequence number
  is in the window.  In the SYN-SENT state (a RST received in response
  to an initial SYN), the RST is acceptable if the ACK field
  acknowledges the SYN.

  The receiver of a RST first validates it, then changes state.  If the
  receiver was in the LISTEN state, it ignores it.  If the receiver was
  in SYN-RECEIVED state and had previously been in the LISTEN state,
  then the receiver returns to the LISTEN state, otherwise the receiver
  aborts the connection and goes to the CLOSED state.  If the receiver
  was in any other state, it aborts the connection and advises the user
  and goes to the CLOSED state.

  (pagina 69)

  If an incoming segment is not acceptable, an acknowledgment
  should be sent in reply (unless the RST bit is set, if so drop
  the segment and return)

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).

Chi non fa questo, non e' RFC-compliant. Punto. 

Se poi decidi arbitrariamente che  un RST va bene sempre... beh allora
direi  che  non  e'  un  problema  di protocollo  ma  un  problema  di
implementazione e devi essere pronto a pagarne le conseguenze.

Avendo sotto  mano solo i  sorgenti di Linux,  posso dire che  esso e'
compliant  con  RFC793. Per  chi  si  volesse  togliere lo  sfizio  di
guardare     i      dettagli     vedere     net/ipv4/tcp_input.c     :
tcp_rcv_established().

Per la randomizzazione delle porte  proposta da Cisco.. da quanti anni
si parla  di questa cosa? Da  quanti anni si  parla di randomizzazione
dell'IP  ID per  evitare  lo scanning  attraverso  IP ID  incrementali
teorizzato  da  antirez?   Da  quanti   anni  si  parla  di  questo  e
quest'altro?  Da tanti  anni ma chissa' perche' in  Linux e in OpenBSD
di queste cose ci si preoccupa... per tutti gli altri questi sono solo
"rumori di fondo dalla rete".

Ma non e' questo il peggio che ho visto.

La cosa peggiore  dal mio punto di vista e' stato  leggere il Draft di
IETF  sul  problema  (draft-ietf-tcpm-tcpsecure-00). Confesso  di  non
essere riuscito  ad arrivare  fino in fondo  in quanto mi  sembrava di
stare leggendo un RFC da primo aprile o giu' di li' ma tant'e'.

La cosa peggiore che ho letto in assoluto...

2.2 Solution

   RFC793 [1] currently requires handling of a segment with the RST
 bit when in a synchronized state to be processed as follows:
   1) If the RST bit is set and the sequence number is outside the
      expected window, silently drop the segment.
   2) If  the RST bit  is set  and the  sequence number  is acceptable
      i.e.: (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND)   then  reset  the
      connection.

   Instead, the following changes should be made to provide some
   protection against such an attack.
   A) If the RST bit is set and the sequence number is outside the
      expected window, silently drop the segment.
   B) If  the RST  bit is exactly  the next expected  sequence number,
      reset the connection.
   C) If the RST bit is set and the sequence number does not exactly
      match the next expected sequence value, yet is within the
      acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an
      acknowledgment.

Il punto  C) e' delirio  allo stato puro  e chi propone  questo (ossia
rispondere a un  pacchetto RST) non ha capito  affatto la logica della
macchina a stati  del TCP. Non credo valga  la pena sprecare ulteriore
fiato per commenti perche' questa pietosita' si commenta da sola.

Ultima considerazione e poi ritorno al mio silenzio (con somma pace di
tutti immagino).  Si e'  fatto un gran  parlare delle  conseguenze che
questa  vulnerabilita' potrebbe  avere  su  BGP e  questa  cosa mi  fa
davvero sorridere. Mi fa sorridere perche' penso che se esistono degli
ISP che effettivamente accettano pacchetti BGP spoofati...  beh allora
non tutti  i mali vengono per  nuocere! Non credo ci  fosse bisogno di
questa rilevazione  dell'eccellente statunitense per  capire che forse
non e'  una bella cosa da  fare... ma e' giusto  che l'informazione ci
sia... e speriamo almeno che ci sia qualcuno in grado di coglierla!
 
Torno al mio silenzio. 

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)

iD8DBQFAiOyvpONIzxnBXKIRAkrKAJ9PmU7UWjDFRwRe4S6shVHEleKAcQCdHIg8
MbSYTtjRCgYxn1+Y1EYgw/U=
=Kg4y
-----END PGP SIGNATURE-----

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