Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

adresse destination 0.0.0.0 invalide ?

16 réponses
Avatar
Thierry B\.
Bonjour les spécialistes. Ma question est simple, et voici une
démonstration évidente de mes doutes...

-------------------------------------------
tth@gally:~$ uname -a
Linux gally 2.6.12-10-686 #1 Wed Feb 7 03:56:37 UTC 2007 i686 GNU/Linux
tth@gally:~$ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
Wed May 14 13:27:04 2008
-------------------------------------------
tth@puce ~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
tth@puce ~ $ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
telnet: connect to address 0.0.0.0: Invalid argument
tth@puce ~ $ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Wed May 14 14:27:25 2008
-------------------------------------------

En poussant un peu plus loin, on se rend vite compte que Linux
redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.
Par exemple, on retrouve bien 127.0.0.1 dans le log apache
avec un "lynx http://0.0.0.0/". Pourtant, l'adresse 0.0.0.0
est semble-t-il invalide comme destination pour les RFCs.

J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Et il y a un fil en cours sur ce sujet dans fcr.ip aussi...

Merci de votre attention.


--
Je suis très siècle dernier, à ce niveau.

--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.

10 réponses

1 2
Avatar
olivier.burelli
On May 19, 9:25 am, "Thierry B." wrote:
Bonjour les spécialistes. Ma question est simple, et voici une
démonstration évidente de mes doutes...

-------------------------------------------
:~$ uname -a
Linux gally 2.6.12-10-686 #1 Wed Feb 7 03:56:37 UTC 2007 i686 GNU/Linux
:~$ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
Connected to 0.0.0.0.
Escape character is '^]'.
Wed May 14 13:27:04 2008
-------------------------------------------
~ $ uname -a
OpenBSD puce.none.invalid 3.8 GENERIC#138 i386
~ $ telnet 0.0.0.0 daytime
Trying 0.0.0.0...
telnet: connect to address 0.0.0.0: Invalid argument
~ $ telnet 127.0.0.1 daytime
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
Wed May 14 14:27:25 2008
-------------------------------------------

En poussant un peu plus loin, on se rend vite compte que Linux
redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.
Par exemple, on retrouve bien 127.0.0.1 dans le log apache
avec un "lynxhttp://0.0.0.0/". Pourtant, l'adresse 0.0.0.0
est semble-t-il invalide comme destination pour les RFCs.

J'aimerais bien savoir si ce comportement est normal, dangereux,
justifié, toussa. Et où le trouver dans les sources de la kernelle.
Et il y a un fil en cours sur ce sujet dans fcr.ip aussi...

Merci de votre attention.

--
Je suis très siècle dernier, à ce niveau.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.



sans pouvoir donner de plus amples explications, effectivement le
0.0.0.0 est bien une adresse non joignable.

le comportement de ton BSD est correct. Ce qui m'empeche pas d'avoir
constate sur une plateforme OpenBSD + QMail une faille via l'adresse
0.0.0.0.

j'avais du patcher QMail pour cela.

Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?

--> telnet dans ton cas.

Cdlt,

Olivier

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
xtof.pernod
> On May 19, 9:25 am, "Thierry B." wrote:
(...)
En poussant un peu plus loin, on se rend vite compte que Linux
redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.





En effet..

# tcpdump -i lo -vvv&
# ping 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 time=0 ms
14:52:32.238085 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 84) 127.0.0.1 > 127.0.0.1: ICMP
echo request, id 41060, seq 0, len 64

..on voit bien que le noyau a mis 127.0.0.1 en source et en destination.


J'aimerais bien savoir si ce comportement est normal, dangereux,





normal, non.. C'est BSD qui doit avoir raison.
dangereux ? en injectant cette adresse à la place d'une réelle,
il doit etre possible de faire des trucs marrants, détourner du
traffic, tout ça..

justifié, toussa. Et où le trouver dans les sources de la kernelle.





Dans celui que j'ai sous la main: il y a une affectation de
INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::

if (!fl.fl4_dst) {
fl.fl4_dst = fl.fl4_src;
if (!fl.fl4_dst)
fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);

Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)


a écrit :
Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?
--> telnet dans ton cas.



Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)

<ml-26_XtoX-0.23d /]# tftp 0.0.0.0 -c get /xx /tmp/yy
14:53:17.938812 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 43) 127.0.0.1.32770 > 127.0.0.1.tftp:
[bad udp cksum 3e1c!] 15 RRQ "/xx" netascii
14:53:17.940300 IP (tos 0x0, ttl 64, id 24214, offset 0, flags [DF],
proto: UDP (17), length: 32) 127.0.0.1.32771 > 127.0.0.1.32770:
[bad udp cksum aa03!] UDP,
14:53:17.940727 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: UDP (17), length: 32) 127.0.0.1.32770 > 127.0.0.1.32771:
[bad udp cksum a903!] UDP,


espoir-ceci-aide, etc.
--
christophe.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Eric Razny
Le Tue, 10 Jun 2008 21:19:10 +0000, olivier.burelli a écrit :

sans pouvoir donner de plus amples explications, effectivement le
0.0.0.0 est bien une adresse non joignable.

le comportement de ton BSD est correct. Ce qui m'empeche pas d'avoir
constate sur une plateforme OpenBSD + QMail une faille via l'adresse
0.0.0.0.

j'avais du patcher QMail pour cela.

Cela devrait-il dire que le pb se situe au niveau de l'applicatif ?

--> telnet dans ton cas.



Je pense plus à un problème de resolver sous nunux.
Je viens de me frapper (en partie!) le code source de telnet d'une etch et
dans command.cc, fonction sourceroute, on a bien par exemple l'utilisation
de inet_aton et pas inet_addr. Le reste semble du même accabit (bon un
commentaire du type fixme, fuite mémoire fait désordre ;) ).

En écrivant ça il y a un moyen con de vérifier...
... c'est fait :

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms

hth.

--
Eric

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
tTh
xtof.pernod wrote:
En poussant un peu plus loin, on se rend vite compte que Linux
redirige 0.0.0.0 sur 127.0.0.1 de façon quasi transparente.





En effet..

# tcpdump -i lo -vvv&
# ping 0.0.0.0
PING 0.0.0.0 (0.0.0.0): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 time=0 ms
14:52:32.238085 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF],
proto: ICMP (1), length: 84) 127.0.0.1 > 127.0.0.1: ICMP
echo request, id 41060, seq 0, len 64

..on voit bien que le noyau a mis 127.0.0.1 en source et en destination.

J'aimerais bien savoir si ce comportement est normal, dangereux,





normal, non.. C'est BSD qui doit avoir raison.



Je pense aussi que BSD a raison. Que font les autres Unix ?

dangereux ? en injectant cette adresse à la place d'une réelle,
il doit etre possible de faire des trucs marrants, détourner du
traffic, tout ça..



Surtout qu'une lecture diagonale des RFCs peut laisser penser
que 0.0.0.0 ne peut pas être une adresse destination valide,
et qu'on aura donc, à tord, tendance à l'éliminer d'une stratégie
de filtrage...

justifié, toussa. Et où le trouver dans les sources de la kernelle.





Dans celui que j'ai sous la main: il y a une affectation de
INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::

if (!fl.fl4_dst) {
fl.fl4_dst = fl.fl4_src;
if (!fl.fl4_dst)
fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);

Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)




Excusez-moi d'arriver un peu tard (c'est quand même moi qui
ai lancé le truc :). Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$ avec une
conclusion qui me semble "presque" correcte.

Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)



D'après les essais que j'ai pû tenter, c'est assez général
comme comportement. Je dois avoir des sources de noyau
2.2 qui trainent quelque part, je vais aller voir ce qu'il
en est au siècle dernier. Mais j'aimerais surtout comprendre
le "pourquoi", la "motivation" du choix de ce comportement.



--
No sig available.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Pascal Hambourg
Salut,

Eric Razny a écrit :

Je pense plus à un problème de resolver sous nunux.



Hypothèse intéressante, mais je crois que c'est xtof qui a raison, étant
arrivé à la même conclusion que lui.

Pour info, cette discussion a été amorcée dans fr.comp.reseaux.ip sous
le titre "Attributions des ports".

En écrivant ça il y a un moyen con de vérifier...
... c'est fait :

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms



Qu'est-ce que c'est censé vérifier, au juste ?

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
xtof.pernod
Eric Razny a écrit :
Le Tue, 10 Jun 2008 21:19:10 +0000, olivier.burelli a écrit :
(...)




> (...)
En écrivant ça il y a un moyen con de vérifier...
... c'est fait :

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.



Ca, c'est marrant.. Ton ping, il a déjà convertit
INADDR_ANY en INADDR_LOOPBACK ?!

Le mien, pas.. [cf post précédent]

64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms

hth.




0.053 ms pour router sur le loopback ? T'as quoi comme machine ?

(je pense qu'en fait on doit pas avoir la meme version de ping(1):
le mien, je suis même pas sûr qu'il soit linké avec libm, c'est
peut-être pour ça qu'il affiche que la partie entière de time=..)


> Je pense plus à un problème de resolver sous nunux.

Je penche plus pour ma version "les sources du noyau", mais en
même temps, ce que j'ai remonté, c'est 2 minutes au grep -R
et à l'éditeur..


--
christophe.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Eric Razny
Le Sat, 14 Jun 2008 19:25:27 +0000, Pascal Hambourg a écrit :

Je pense plus à un problème de resolver sous nunux.



Hypothèse intéressante, mais je crois que c'est xtof qui a raison, étant
arrivé à la même conclusion que lui.



Il faudrait regarder dans les sources du noyau. Un parsing rapide ne me
donne que net/ipv4/netfilter/ipt_REDIRECT.c pour trouver 0x7F000001 mais
comme loopback est aussi trouvable par d'autre méthode ça va être
coton. Il semble aussi y avoir des trucs à voir sur sctp et en cherchant
sur INADDR_ANY mais il ne faut pas compter sur moi avant septembre pour
chercher la dedans ;)



Pour info, cette discussion a été amorcée dans fr.comp.reseaux.ip sous
le titre "Attributions des ports".



Merci. Je vais y jetter un oeil (enfin si j'ai le temps!)

En écrivant ça il y a un moyen con de vérifier...
... c'est fait :

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttld time=0.053 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttld time=0.046 ms



Qu'est-ce que c'est censé vérifier, au juste ?



Effectivement ce n'est pas très probant au sens où on n'est quand même
pas sur que c'est pas le noyau qui fait ça au lieu du resolver voire de
ping.

J'ai bloqué un peu vite sur le 0.0.0.0 converti explicitement en
127.0.0.1 chez moi

Le plus simple va être de reprendre l'idée de xtof (tcpdump) en
écrivant rapidement une merde en C qui va ouvrir un socket et tenter de
se connecter en 0.0.0.0 sur un port quelconque en tcp par exemple (bon
formellement ça peut aussi venir des libs mais bon ;) )

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
xtof.pernod
tTh a écrit :
xtof.pernod wrote:
(...) le noyau a mis 127.0.0.1 en source et en destination.

J'aimerais bien savoir si ce comportement est normal, dangereux,





normal, non.. C'est BSD qui doit avoir raison.



Je pense aussi que BSD a raison. Que font les autres Unix ?



Et que fait la police ?

Quant à un autre type de système entierement basé sur les fenêtres,
il s'en rend bien compte, mais il essaye quand même:

Pinging 0.0.0.0 with 32 bytes of data:

Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.
Destination specified is invalid.

Ping statistics for 0.0.0.0:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),



dangereux ? en injectant cette adresse à la place d'une réelle,
il doit etre possible de faire des trucs marrants, détourner du
traffic, tout ça..



Surtout qu'une lecture diagonale des RFCs peut laisser penser
que 0.0.0.0 ne peut pas être une adresse destination valide,
et qu'on aura donc, à tord, tendance à l'éliminer d'une stratégie
de filtrage...




Pinaiiiiise, oui.. Ca fait froid dans le dos ce que tu dis la.. =)
Mais j'y pense, d'un coup: comment établir une route vers 0.0.0.0 ?!

0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)

justifié, toussa. Et où le trouver dans les sources de la kernelle.





Dans celui que j'ai sous la main: il y a une affectation de
INADDR_LOOPBACK (127.0.0.1, bien sûr) à 2 variables (dst et src)
dans /usr/src/linux-2.6.23.12/net/ipv4/route.c, L. 2245::

if (!fl.fl4_dst) {
fl.fl4_dst = fl.fl4_src;
if (!fl.fl4_dst)
fl.fl4_dst = fl.fl4_src = htonl(INADDR_LOOPBACK);

Peut-être une piste !? (si c'est pas là, je vois pas où c'est =)




Excusez-moi d'arriver un peu tard (c'est quand même moi qui
ai lancé le truc :). Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$ avec une
conclusion qui me semble "presque" correcte.



Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)
(c'etait: ma manière de dire que j'ai pas copié sur lui, m'sieur!)


Je pense pas, ca le fait au ping et aussi avec tftp
(client ras-de-terre de tftp-hpa-0.48:)



D'après les essais que j'ai pû tenter, c'est assez général
comme comportement. Je dois avoir des sources de noyau
2.2 qui trainent quelque part, je vais aller voir ce qu'il



Tu jettera un oeil au 0.99p155, pendant que t'es debout ?!?..

en est au siècle dernier. Mais j'aimerais surtout comprendre
le "pourquoi", la "motivation" du choix de ce comportement.




Plus je regarde le bout de code, plus je me dis: si y a truc qui
va pô, alors mettre un truc qui va bien à la place, fin-si.

Avec effet de bord, c'est 127.1 qui répond à 0.0.0.0, qui n'est pas
routable donc.


--
christophe.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Pascal Hambourg
xtof.pernod a écrit :
Eric Razny a écrit :

$ ping 0.0.0.0
PING 0.0.0.0 (127.0.0.1) 56(84) bytes of data.



Ca, c'est marrant.. Ton ping, il a déjà convertit
INADDR_ANY en INADDR_LOOPBACK ?!



Le mien aussi. Sans regarder le code (de toute façon je n'y comprendrais
probablement rien, n'étant pas programmateur de sockets), je soupçonne
que ping affiche entre parenthèses l'adresse IP destination de la socket
raw créée, qui a été modifiée par le noyau.

0.053 ms pour router sur le loopback ? T'as quoi comme machine ?



Une machine rapide, pour sûr. Sur la mienne c'est 0,200 ms.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Avatar
Pascal Hambourg
xtof.pernod a écrit :

Quant à un autre type de système entierement basé sur les fenêtres,
il s'en rend bien compte, mais il essaye quand même:

Pinging 0.0.0.0 with 32 bytes of data:

Destination specified is invalid.



Ça doit dépendre des versions, parce que le mien (2000 SP4) me dit :

Hôte inconnu 0.0.0.0.

Ceci dit, il ne faut pas trop s'y fier car il répond la même chose pour
l'adresse de broadcast limité 255.255.255.255.

0.0.0.0 ne peut donc pas etre autre chose qu'une adresse invalide,
comme 255.255.255.255 (?)



Plaît-il ? 255.255.255.255 est une adresse destination parfaitement
valide, c'est l'adresse de broadcast limité.

Pascal, dans fcr.ip est arrivé au même
morceau de code <g0rk1p$1flu$ avec une
conclusion qui me semble "presque" correcte.



Tu aurais les refs' de l'article ? Je le trouve pas (meme au gougueule)



Auto-promo :
<http://groups.google.fr/group/fr.comp.reseaux.ip/msg/c36da1dc6d8297e1&gt;
Dans le formulaire de recherche avancée, il faut retirer les <>
encadrant le message-id. C'est bizarre, mais c'est comme ça.

Quant au fait que tu ne le voies pas sur ton serveur de news, c'est
peut-être encore à cause de mon adresse source IPv6 qui serait vue comme
invalide par des filtres obsolètes. La chaîne de modération de
fr.comp.securite m'avait déjà fait le coup il y a quelques temps.
Regarde si tu vois d'autres articles récents de moi dans des forums non
modérés.

--
Pour contacter l'équipe de modération :
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
1 2