Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
?
Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
?
Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
?
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
On 14 Apr 2005 09:43:44 GMT, LaDDL :
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
C'est peut-être moi qui ai du mal à lire, mais je n'y trouve pas "tous
les détails", justement. Je n'ai même pas réussi à comprendre s'il
s'agissait d'une faille dans la couche IP, ou un port ouvert par
erreur.
J'ai trouvé deux ou trois sites qui donnent un peu plus de détails,
mais pas tellement.
Par exemple, je ne sais toujours pas si un
firewall permet d'empêcher l'utilisation de cette faille.
On 14 Apr 2005 09:43:44 GMT, LaDDL :
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
C'est peut-être moi qui ai du mal à lire, mais je n'y trouve pas "tous
les détails", justement. Je n'ai même pas réussi à comprendre s'il
s'agissait d'une faille dans la couche IP, ou un port ouvert par
erreur.
J'ai trouvé deux ou trois sites qui donnent un peu plus de détails,
mais pas tellement.
Par exemple, je ne sais toujours pas si un
firewall permet d'empêcher l'utilisation de cette faille.
On 14 Apr 2005 09:43:44 GMT, LaDDL :
Tous les détails en français ici :
http://www.microsoft.com/france/technet/securite/ms05-019.mspx
C'est peut-être moi qui ai du mal à lire, mais je n'y trouve pas "tous
les détails", justement. Je n'ai même pas réussi à comprendre s'il
s'agissait d'une faille dans la couche IP, ou un port ouvert par
erreur.
J'ai trouvé deux ou trois sites qui donnent un peu plus de détails,
mais pas tellement.
Par exemple, je ne sais toujours pas si un
firewall permet d'empêcher l'utilisation de cette faille.
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
Le Thu, 14 Apr 2005 15:49:04 +0000, LaDDL a écrit :
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Outre le fait que le mot fragmentation n'apparaît que pour décrire à
quoi sert le PMTU Discovery (comprendre qu'on ne peut pas conclure sur
la base de l'article), que les dénis de service en fragmentation
(teardrop, bonk, etc.) étaient surtout tendance en en 97-98 (mais bon,
ils ont bien réussi à nous ressortir le land qui date de la même
époque), ça n'est pas clair du tout.
Surtout quand on lit :
Vulnérabilité liée à la réinitialisation de la connexion ICMP
Ah, ICMP est un protocole connecté... Et en plus on réinitialiser ces
trucs qui n'existent pas ?... Hummm, voyons la suite :
Il existe une vulnérabilité de déni de service En anglais qui pourrait
permettre à un attaquant d'envoyer un message TCP spécialement conçu
à un système affecté.
Ah ouais, on enverrait des paquets TCP pour casser des hypothétiques
connexions ICMP ? Va falloir penser à changer de traducteur chez
Microsoft.
Franchement, si on veut avoir des réponses claires, il vaut carrément
mieux aller voir la base CVE...
On peut aussi mettre ça en parallèle
d'un draft mentionné par Cisco dans un de ses advisories :
http://www.watersprings.org/pub/id/draft-gont-tcpm-icmp-attacks-03.txt
1. CAN-2005-0048 : pas trop de détail, mais apparemment, c'est un remote
root sur la pile IP (putain, j'e, ai rêver, MS l'a fait :))).
2. CAN-2004-0790 : rien non plus chez CVE, mais je vote pour le cassage
de
connexion TCP avec devinant les ports. C'est drôle, mais en 97,
j'avais un outil qui faisait ça pour faire mumuse sur IRC...
3. CAN-2004-1060 : rien dans CVE, mais c'est la même chose qu'au dessus,
sauf qu'on fait baisser la PMTU du mec à fond en lui retournant des
Frag Needed. Implémenté en 98 (au moins).
4. CAN-2004-0230 : déni de service en TCP/RST par brute force du numéro
d'acquittement sur des connexion à fenêtre large.
Faille présentée à Cansecwest/core04 y'a un an.
5. CAN-2005-0688 : le land, un Dos datant de 1999 qui ressort sous XP...
No comment
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
Attaque 1, d'après les bruits courent, le paquet est tellement mal foutu
qu'il ne passe pas un routeur, ni un firewall de bonne facture.
Attaque 2, si le firewall n'implémente pas de gestion d'état sur les
messages ICMP, peu de chance qu'il soit bloqué (avec Netfiltet, ça passe
pas :)).
Attaque 3, idem qu'au dessus.
Attaque 4, tant que numéro d'acquittement est dans la fenêtre, ça
passe, c'est la RFC qui le dit. C'est une faille structurelle de TCP,
voir
la présentation de Paul Watson à ce sujet.
Attaque 5, l'OS ne devrait même pas accepter ça (Linux boule ce genre de
paquet sans autre forme de procès). Un firewall devrait régler le
problème.
Le Thu, 14 Apr 2005 15:49:04 +0000, LaDDL a écrit :
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Outre le fait que le mot fragmentation n'apparaît que pour décrire à
quoi sert le PMTU Discovery (comprendre qu'on ne peut pas conclure sur
la base de l'article), que les dénis de service en fragmentation
(teardrop, bonk, etc.) étaient surtout tendance en en 97-98 (mais bon,
ils ont bien réussi à nous ressortir le land qui date de la même
époque), ça n'est pas clair du tout.
Surtout quand on lit :
Vulnérabilité liée à la réinitialisation de la connexion ICMP
Ah, ICMP est un protocole connecté... Et en plus on réinitialiser ces
trucs qui n'existent pas ?... Hummm, voyons la suite :
Il existe une vulnérabilité de déni de service En anglais qui pourrait
permettre à un attaquant d'envoyer un message TCP spécialement conçu
à un système affecté.
Ah ouais, on enverrait des paquets TCP pour casser des hypothétiques
connexions ICMP ? Va falloir penser à changer de traducteur chez
Microsoft.
Franchement, si on veut avoir des réponses claires, il vaut carrément
mieux aller voir la base CVE...
On peut aussi mettre ça en parallèle
d'un draft mentionné par Cisco dans un de ses advisories :
http://www.watersprings.org/pub/id/draft-gont-tcpm-icmp-attacks-03.txt
1. CAN-2005-0048 : pas trop de détail, mais apparemment, c'est un remote
root sur la pile IP (putain, j'e, ai rêver, MS l'a fait :))).
2. CAN-2004-0790 : rien non plus chez CVE, mais je vote pour le cassage
de
connexion TCP avec devinant les ports. C'est drôle, mais en 97,
j'avais un outil qui faisait ça pour faire mumuse sur IRC...
3. CAN-2004-1060 : rien dans CVE, mais c'est la même chose qu'au dessus,
sauf qu'on fait baisser la PMTU du mec à fond en lui retournant des
Frag Needed. Implémenté en 98 (au moins).
4. CAN-2004-0230 : déni de service en TCP/RST par brute force du numéro
d'acquittement sur des connexion à fenêtre large.
Faille présentée à Cansecwest/core04 y'a un an.
5. CAN-2005-0688 : le land, un Dos datant de 1999 qui ressort sous XP...
No comment
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
Attaque 1, d'après les bruits courent, le paquet est tellement mal foutu
qu'il ne passe pas un routeur, ni un firewall de bonne facture.
Attaque 2, si le firewall n'implémente pas de gestion d'état sur les
messages ICMP, peu de chance qu'il soit bloqué (avec Netfiltet, ça passe
pas :)).
Attaque 3, idem qu'au dessus.
Attaque 4, tant que numéro d'acquittement est dans la fenêtre, ça
passe, c'est la RFC qui le dit. C'est une faille structurelle de TCP,
voir
la présentation de Paul Watson à ce sujet.
Attaque 5, l'OS ne devrait même pas accepter ça (Linux boule ce genre de
paquet sans autre forme de procès). Un firewall devrait régler le
problème.
Le Thu, 14 Apr 2005 15:49:04 +0000, LaDDL a écrit :
En gros, ces vulnérabilités sont liées à l'exploitation de la gestion de
la fragmentation IP [c'est très tendance actuellement ;) ]
Outre le fait que le mot fragmentation n'apparaît que pour décrire à
quoi sert le PMTU Discovery (comprendre qu'on ne peut pas conclure sur
la base de l'article), que les dénis de service en fragmentation
(teardrop, bonk, etc.) étaient surtout tendance en en 97-98 (mais bon,
ils ont bien réussi à nous ressortir le land qui date de la même
époque), ça n'est pas clair du tout.
Surtout quand on lit :
Vulnérabilité liée à la réinitialisation de la connexion ICMP
Ah, ICMP est un protocole connecté... Et en plus on réinitialiser ces
trucs qui n'existent pas ?... Hummm, voyons la suite :
Il existe une vulnérabilité de déni de service En anglais qui pourrait
permettre à un attaquant d'envoyer un message TCP spécialement conçu
à un système affecté.
Ah ouais, on enverrait des paquets TCP pour casser des hypothétiques
connexions ICMP ? Va falloir penser à changer de traducteur chez
Microsoft.
Franchement, si on veut avoir des réponses claires, il vaut carrément
mieux aller voir la base CVE...
On peut aussi mettre ça en parallèle
d'un draft mentionné par Cisco dans un de ses advisories :
http://www.watersprings.org/pub/id/draft-gont-tcpm-icmp-attacks-03.txt
1. CAN-2005-0048 : pas trop de détail, mais apparemment, c'est un remote
root sur la pile IP (putain, j'e, ai rêver, MS l'a fait :))).
2. CAN-2004-0790 : rien non plus chez CVE, mais je vote pour le cassage
de
connexion TCP avec devinant les ports. C'est drôle, mais en 97,
j'avais un outil qui faisait ça pour faire mumuse sur IRC...
3. CAN-2004-1060 : rien dans CVE, mais c'est la même chose qu'au dessus,
sauf qu'on fait baisser la PMTU du mec à fond en lui retournant des
Frag Needed. Implémenté en 98 (au moins).
4. CAN-2004-0230 : déni de service en TCP/RST par brute force du numéro
d'acquittement sur des connexion à fenêtre large.
Faille présentée à Cansecwest/core04 y'a un an.
5. CAN-2005-0688 : le land, un Dos datant de 1999 qui ressort sous XP...
No comment
Ton FW peut empêcher ces types d'attaques. Lis bien la page indiquée
ci-haut et la partie concernée, car c'est indiqué/précisé. ;)
Attaque 1, d'après les bruits courent, le paquet est tellement mal foutu
qu'il ne passe pas un routeur, ni un firewall de bonne facture.
Attaque 2, si le firewall n'implémente pas de gestion d'état sur les
messages ICMP, peu de chance qu'il soit bloqué (avec Netfiltet, ça passe
pas :)).
Attaque 3, idem qu'au dessus.
Attaque 4, tant que numéro d'acquittement est dans la fenêtre, ça
passe, c'est la RFC qui le dit. C'est une faille structurelle de TCP,
voir
la présentation de Paul Watson à ce sujet.
Attaque 5, l'OS ne devrait même pas accepter ça (Linux boule ce genre de
paquet sans autre forme de procès). Un firewall devrait régler le
problème.
Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du CVE
correspondant est toujours indiqué.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
dvips -o $@ $<
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du CVE
correspondant est toujours indiqué.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
dvips -o $@ $<
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du CVE
correspondant est toujours indiqué.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
dvips -o $@ $<
Faut faire gffe de pas te couper avec ton truc, t'as mis des ciseaux ($<)
Le Sat, 16 Apr 2005 17:24:11 +0000, LaDDL a écrit :Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Effectivement. Mais d'ici à trouver un rapport avec la fragmentation...
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du
CVE
correspondant est toujours indiqué.
C'est d'ailleurs comme cela qu'on peut trouver facilement les advisories
CVE (non linkés au passage)
qui sont plus clairs,
quand ils sont
publiés et complets,
ce qui n'était pas le cas jeudi.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
Comment marche la fragmentation n'a pas de rapport avec cette faille,
c'est le mécanisme de PMTU discovery qui est en cause (mauvais check des
ICMP Frag needed)...
Le Sat, 16 Apr 2005 17:24:11 +0000, LaDDL a écrit :
Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Effectivement. Mais d'ici à trouver un rapport avec la fragmentation...
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du
CVE
correspondant est toujours indiqué.
C'est d'ailleurs comme cela qu'on peut trouver facilement les advisories
CVE (non linkés au passage)
qui sont plus clairs,
quand ils sont
publiés et complets,
ce qui n'était pas le cas jeudi.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
Comment marche la fragmentation n'a pas de rapport avec cette faille,
c'est le mécanisme de PMTU discovery qui est en cause (mauvais check des
ICMP Frag needed)...
Le Sat, 16 Apr 2005 17:24:11 +0000, LaDDL a écrit :Je lis uniquement leur bulletin en US. Même en version originale avec MS
on doit toujours décrypter/interprêter !!!
Effectivement. Mais d'ici à trouver un rapport avec la fragmentation...
Complétement d'accord. Mais si tu lis bien les bulletins MS le nom du
CVE
correspondant est toujours indiqué.
C'est d'ailleurs comme cela qu'on peut trouver facilement les advisories
CVE (non linkés au passage)
qui sont plus clairs,
quand ils sont
publiés et complets,
ce qui n'était pas le cas jeudi.
http://www.tcpipguide.com/free/t_IPMessageFragmentationProcess-4.htm
Comment marche la fragmentation n'a pas de rapport avec cette faille,
c'est le mécanisme de PMTU discovery qui est en cause (mauvais check des
ICMP Frag needed)...
Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
? Existe t il déjà un exploit ? Est elle facilement utilisable ? Doit
on s'attendre à la sortie d'un vers exploitant cette faille ?
Isotaupe
Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
? Existe t il déjà un exploit ? Est elle facilement utilisable ? Doit
on s'attendre à la sortie d'un vers exploitant cette faille ?
Isotaupe
Bonjour,
Une faille critique Microsoft Windows TCP/IP Remote Code Execution and
DoS (MS05-019) a été annoncée hier. Quel est l'impact de cette faille
? Existe t il déjà un exploit ? Est elle facilement utilisable ? Doit
on s'attendre à la sortie d'un vers exploitant cette faille ?
Isotaupe