Il me semblait qu'il était légal d'avoir deux serveurs qui écoutent sur le
même port, un sur une adresse particulière et l'autre sur INADDR_ANY, pour
peu que SO_REUSEADDR soit utilisé.
Stevens confirme (UNP page 195) :
# SO_REUSEADDR allows multiple instances of the same server to be started on
# the same port, as long as each instance binds a different local IP
# address. [...] The first HTTP server would call bind with a local IP
# address of 192.69.10.128 and a local port of 80 [...] The third server
# would call bind with the willcard as the local IP address and a local port
# of 80. Again, SO_REUSEADDR is required for the final call to succeed.
Or sous Linux (2.6.21.4, pour les tests les plus détaillés), ça ne marche
pas. Par exemple, si je lance en parallèle :
Et hop, plus personne ne peut monter les nfs de duey.
-- Stéphane
Olivier Miakinen
[...]
Cela dit, je trouve ca un peu douteux. Ca veut dire que quelqu'un peut piquer le port de quelqu'un d'autre pour peu que ce quelqu'un d'autre a fait un bind sur INADDR_ANY avec SO_REUSEADDR.
Oui. Dans le cas de SNMP (port 161) il fallait quand même être root pour pouvoir faire le bind(). Je ne sais pas si ce setsockopt réclame lui-même les droits de root lorsque le bind ne l'exige pas.
C'est probablement parce que 161 est un port privilégié (< 1024).
C'est non seulement probable, mais même certain. Pardon de ne pas avoir été clair sur ce point.
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY. Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de droits particuliers ?
Ca me semble un immense trou de securité, vu que je peux m'intercaller au beau milieu d'une session X de quelqu'un d'autre par exemple. Je ne sais pas si ca a ete fixé dans les versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté tel que TCP il sera impossible de s'intercaler dans un dialogue en cours puisque les quatre infos discriminantes (adresse et port locaux, adresse et port distants) sont complètement déterminés après la connexion.
Le comportement de Linux me semble plus sain.
En tout cas, merci de l'info comme quoi ça ne marche pas sur Linux.
[...]
Cela dit, je trouve ca un peu douteux. Ca veut dire que
quelqu'un peut piquer le port de quelqu'un d'autre pour peu que
ce quelqu'un d'autre a fait un bind sur INADDR_ANY avec
SO_REUSEADDR.
Oui. Dans le cas de SNMP (port 161) il fallait quand même être root
pour pouvoir faire le bind(). Je ne sais pas si ce setsockopt réclame
lui-même les droits de root lorsque le bind ne l'exige pas.
C'est probablement parce que 161 est un port privilégié (< 1024).
C'est non seulement probable, mais même certain. Pardon de ne pas avoir
été clair sur ce point.
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression
qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse
avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY.
Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce
qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de
droits particuliers ?
Ca me semble un immense trou de securité, vu que je peux
m'intercaller au beau milieu d'une session X de quelqu'un
d'autre par exemple. Je ne sais pas si ca a ete fixé dans les
versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté
tel que TCP il sera impossible de s'intercaler dans un dialogue en cours
puisque les quatre infos discriminantes (adresse et port locaux, adresse
et port distants) sont complètement déterminés après la connexion.
Le comportement de Linux me semble plus sain.
En tout cas, merci de l'info comme quoi ça ne marche pas sur Linux.
Cela dit, je trouve ca un peu douteux. Ca veut dire que quelqu'un peut piquer le port de quelqu'un d'autre pour peu que ce quelqu'un d'autre a fait un bind sur INADDR_ANY avec SO_REUSEADDR.
Oui. Dans le cas de SNMP (port 161) il fallait quand même être root pour pouvoir faire le bind(). Je ne sais pas si ce setsockopt réclame lui-même les droits de root lorsque le bind ne l'exige pas.
C'est probablement parce que 161 est un port privilégié (< 1024).
C'est non seulement probable, mais même certain. Pardon de ne pas avoir été clair sur ce point.
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY. Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de droits particuliers ?
Ca me semble un immense trou de securité, vu que je peux m'intercaller au beau milieu d'une session X de quelqu'un d'autre par exemple. Je ne sais pas si ca a ete fixé dans les versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté tel que TCP il sera impossible de s'intercaler dans un dialogue en cours puisque les quatre infos discriminantes (adresse et port locaux, adresse et port distants) sont complètement déterminés après la connexion.
Le comportement de Linux me semble plus sain.
En tout cas, merci de l'info comme quoi ça ne marche pas sur Linux.
Stephane Chazelas
2007-07-14, 16:56(+02), Olivier Miakinen: [...]
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY. Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de droits particuliers ?
On peut faire le setsockopt, mais pas le bind.
Ca me semble un immense trou de securité, vu que je peux m'intercaller au beau milieu d'une session X de quelqu'un d'autre par exemple. Je ne sais pas si ca a ete fixé dans les versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté tel que TCP il sera impossible de s'intercaler dans un dialogue en cours puisque les quatre infos discriminantes (adresse et port locaux, adresse et port distants) sont complètement déterminés après la connexion. [...]
Non, bien sur, mais je peux a partir d'un moment faire en sorte que toute nouvelle connection passe par mon "man in the middle", par exemple, que le prochain xterm que lancera la victime, se connectera a mon intercepteur.
En ayant DISPLAY=host:0, la victime aimerait pouvoir etre guarantie qu'elle se connectera au serveur X qu'elle a sous les yeux, mais en fait ce SO_REUSEADDR permet a quelqu'un de preempter le port TCP pour une addresse donnee.
-- Stéphane
2007-07-14, 16:56(+02), Olivier Miakinen:
[...]
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression
qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse
avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY.
Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce
qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de
droits particuliers ?
On peut faire le setsockopt, mais pas le bind.
Ca me semble un immense trou de securité, vu que je peux
m'intercaller au beau milieu d'une session X de quelqu'un
d'autre par exemple. Je ne sais pas si ca a ete fixé dans les
versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté
tel que TCP il sera impossible de s'intercaler dans un dialogue en cours
puisque les quatre infos discriminantes (adresse et port locaux, adresse
et port distants) sont complètement déterminés après la connexion.
[...]
Non, bien sur, mais je peux a partir d'un moment faire en sorte
que toute nouvelle connection passe par mon "man in the middle",
par exemple, que le prochain xterm que lancera la victime, se
connectera a mon intercepteur.
En ayant DISPLAY=host:0, la victime aimerait pouvoir etre
guarantie qu'elle se connectera au serveur X qu'elle a sous les
yeux, mais en fait ce SO_REUSEADDR permet a quelqu'un de
preempter le port TCP pour une addresse donnee.
En l'occurrence, sous Solaris 7, je n'ai meme pas l'impression qu'il soit necessaire que celui qui bind sur INADDR_ANY le fasse avec SO_REUSEADDR.
Non, en effet. Il n'y a rien à changer à celui qui bind sur INADDR_ANY. Mais là n'était pas ma question.
Ma question était : peut-on faire un SO_REUSEADDR sans être root, ce qui permettrait de « voler » les ports supérieurs à 1024 sans avoir de droits particuliers ?
On peut faire le setsockopt, mais pas le bind.
Ca me semble un immense trou de securité, vu que je peux m'intercaller au beau milieu d'une session X de quelqu'un d'autre par exemple. Je ne sais pas si ca a ete fixé dans les versions ulterieures.
La session X est basée sur UDP et non TCP ? Avec un protocole connecté tel que TCP il sera impossible de s'intercaler dans un dialogue en cours puisque les quatre infos discriminantes (adresse et port locaux, adresse et port distants) sont complètement déterminés après la connexion. [...]
Non, bien sur, mais je peux a partir d'un moment faire en sorte que toute nouvelle connection passe par mon "man in the middle", par exemple, que le prochain xterm que lancera la victime, se connectera a mon intercepteur.
En ayant DISPLAY=host:0, la victime aimerait pouvoir etre guarantie qu'elle se connectera au serveur X qu'elle a sous les yeux, mais en fait ce SO_REUSEADDR permet a quelqu'un de preempter le port TCP pour une addresse donnee.
-- Stéphane
Nicolas George
Stephane Chazelas wrote in message :
Oui, mais ce n'est qu'un exemple, quid de mountd, nfsd, cvs pserver, oracle, mysql...
Ça pourrait être résolu en n'autorisant à partager un port dans ces conditions que si l'UID est la même.
Stephane Chazelas wrote in message
<slrnf9hg5u.5pq.stephane.chazelas@spam.is.invalid>:
Oui, mais ce n'est qu'un exemple, quid de mountd, nfsd, cvs
pserver, oracle, mysql...
Ça pourrait être résolu en n'autorisant à partager un port dans ces
conditions que si l'UID est la même.
Oui, mais ce n'est qu'un exemple, quid de mountd, nfsd, cvs pserver, oracle, mysql...
Ça pourrait être résolu en n'autorisant à partager un port dans ces conditions que si l'UID est la même.
Luc.Habert.00__arjf
Nicolas George :
Ça pourrait être résolu en n'autorisant à partager un port dans ces conditions que si l'UID est la même.
Ça mériterait reflexion profonde. Que fais-tu si les EUID, RUID, saved UID ne sont pas identiques? Et les capabilities? Et si l'un des programmes était en mode 711 appartenant à un autre utilisateur? Et si il était sgid? Etc... L'UID seul n'est pas une définition claire de la personne à qui appartient le process.
Nicolas George :
Ça pourrait être résolu en n'autorisant à partager un port dans ces
conditions que si l'UID est la même.
Ça mériterait reflexion profonde. Que fais-tu si les EUID, RUID, saved UID
ne sont pas identiques? Et les capabilities? Et si l'un des programmes était
en mode 711 appartenant à un autre utilisateur? Et si il était sgid? Etc...
L'UID seul n'est pas une définition claire de la personne à qui appartient
le process.
Ça pourrait être résolu en n'autorisant à partager un port dans ces conditions que si l'UID est la même.
Ça mériterait reflexion profonde. Que fais-tu si les EUID, RUID, saved UID ne sont pas identiques? Et les capabilities? Et si l'un des programmes était en mode 711 appartenant à un autre utilisateur? Et si il était sgid? Etc... L'UID seul n'est pas une définition claire de la personne à qui appartient le process.
