Un enorme trou de securite dans TCP/IP ?

Le
elvi52001
Le protocole TCP/IP est la fondation même des échanges réseaux et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.

http://www.k-otik.net/bugtraq/04212004.TCP.php
http://www.k-otik.com/news/04212004.TCP.php

ou va-t-on ?
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Sebastien Varrette
Le #572976
Patrice wrote:
Le protocole TCP/IP est la fondation même des échanges réseaux... et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.

http://www.k-otik.net/bugtraq/04212004.TCP.php
http://www.k-otik.com/news/04212004.TCP.php

ou va-t-on ?


En fait, cette faille est connue depuis longtemps.
C'est sa publicité (notamment aus Etats Unis) qui est récente... Et qui
va poser problème car de nombreuses personnes (pas forcément bien
intentionnées) vont s'y interessé.

Wait and see....

Nicob
Le #572725
On Thu, 22 Apr 2004 10:17:56 +0000, Sebastien Varrette wrote:

C'est sa publicité (notamment aus Etats Unis) qui est récente... Et
qui va poser problème car de nombreuses personnes (pas forcément bien
intentionnées) vont s'y interessé.


Pour moi, une faille publiée est toujours moins dangereuse qu'une faille
non publiée, car on peut entreprendre (si on est informé) des actions de
mitigation du risque, comme l'application d'un patch "home made", une
modification de la configuration, une restriction accentuée des accès ou
même une désactivation du service.


Nicob

totoy81
Le #572484
Le protocole TCP/IP est la fondation même des échanges réseaux... et
on vient de se rendre compte qu'il comportait depuis toujours une
faille structurelle ! Il serait beaucoup plus simple qu'on ne le
pensait jusqu'alors de neutraliser une connexion TCP/IP. Cette
perspective ouvre la voie à de nombreux dénis de service.


Cette faille est connue depuis la création même de la RFC 793 (TCP).
En théorie, à condition de trouver les couples {IP,port} source et
destination d'une connexion établie (le port source peut être plus
difficile à deviner comme avec l'utilisation de patchs comme
grSecurity par exemple, mais bon c pas légion), le seul paramètre
manquant à rendre un paquet RST (ou SYN avec ISN différent) spoofé
"légitime" est un numéro de séquence correct, soit à choisir parmi
2^32 possibilités. Ce qu'il y a de nouveau et qui rend l'attaque
faisable _en pratique_ c'est qu'on se rend compte qu'il n'est pas
nécessaire de choisir le numéro de séquence exact, mais un numéro
choisi dans une plage, qui correspond à la fenêtre "TCP Window"
(annoncée sur le 3-way handshake). Les facteurs aggravants sont la
predictabilité importante des ports sources "clients" et les valeurs
par défaut de fenêtre utilisées par les différents OS.

Ce n'est ni plus ni moins qu'un problème d'authentification (aka IPSec
est une solution au problème...), puisqu'on considère que la
connaissance du numéro de séquence exact relativement à la durée de
l'établissement de la connexion est "suffisamment difficilement" (;))
devinable.

Ce qui a fait "flipper" dès l'annonce c'est la mise en cause de la
disponibilité des infrastructures de routage (BGP est transporté par
TCP) vis à vis de ce type d'attaque. Néanmoins on s'est aperçu
rapidement qu'avec un filtrage correct des flux ingress/egress (aka
les bonnes pratiques BGP qui permettent pour l'instant de se passer de
{s-,so}BGP et consorts PKIstiques) et l'utilisation de
l'authentification par l'option TCP MD5 est un facteur mitigeant.

La solution apportée par plusieurs vendeurs a été de générer un
acquittement lors de la réception d'un RST ou SYN (avec ISN différent,
ce qui, cf.RFC, permet également de réinitialiser la connexion) dans
la fenêtre, ce qui permet de s'assurer que la pile légitime soit
l'émettrice (à moins que la connexion soit hijackée ou que le pirate
ait accès aux trames destinées à la machine cliente légitime).

Jerome T
Le #569918
"anth0" news:
Cette faille est connue depuis la création même de la RFC 793 (TCP).


Est-ce que vous ou quelqu'un d'autre aurait des sources sur cette
information ?

Publicité
Poster une réponse
Anonyme