Je sens que je vais me faire incendier, mais bon je me lance : est-ce
une bonne idée de mettre /usr/bin/passwd comme shell pour des
utilisateurs ? En fait je désire un système pour pouvoir laisser des
utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en
m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu
par la manière qui consiste à passer par le web via un cgi.
Que cela pose-t-il comme problème de sécurité ? Peut-il y avoir un
problème avec les redirections de ports de SSH par exemple ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
shaddai
On 14 Jul 2003 13:31:17 GMT, NIIN wrote:
Je sens que je vais me faire incendier, mais bon je me lance : est-ce une bonne idée de mettre /usr/bin/passwd comme shell pour des utilisateurs ? En fait je désire un système pour pouvoir laisser des utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant tls par exemple.
Que cela pose-t-il comme problème de sécurité ? Peut-il y avoir un problème avec les redirections de ports de SSH par exemple ?
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
-- We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
On 14 Jul 2003 13:31:17 GMT, NIIN wrote:
Je sens que je vais me faire incendier, mais bon je me lance : est-ce
une bonne idée de mettre /usr/bin/passwd comme shell pour des
utilisateurs ? En fait je désire un système pour pouvoir laisser des
utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en
m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu
par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir
trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant
tls par exemple.
Que cela pose-t-il comme problème de sécurité ? Peut-il y avoir un
problème avec les redirections de ports de SSH par exemple ?
Je vois un problème "assez" grave. Si un jour une personne trouve une
faille locale dans /usr/bin/passwd, cette faille sera distante pour toi,
tous les utilisateurs pourront utiliser la faille pour gagner les
privilèges de l'administrateur. A déconseiller donc.
--
We are the knights who say
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
Je sens que je vais me faire incendier, mais bon je me lance : est-ce une bonne idée de mettre /usr/bin/passwd comme shell pour des utilisateurs ? En fait je désire un système pour pouvoir laisser des utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant tls par exemple.
Que cela pose-t-il comme problème de sécurité ? Peut-il y avoir un problème avec les redirections de ports de SSH par exemple ?
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
-- We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
Laurent Fousse
Dans fr.comp.securite, shaddai nous disait:
On 14 Jul 2003 13:31:17 GMT, NIIN wrote:
Je sens que je vais me faire incendier, mais bon je me lance : est-ce une bonne idée de mettre /usr/bin/passwd comme shell pour des utilisateurs ? En fait je désire un système pour pouvoir laisser des utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant tls par exemple.
Ou en gpg avec grunt?
-- fakeroot debian/rules troll
Dans fr.comp.securite, shaddai nous disait:
On 14 Jul 2003 13:31:17 GMT, NIIN wrote:
Je sens que je vais me faire incendier, mais bon je me lance : est-ce
une bonne idée de mettre /usr/bin/passwd comme shell pour des
utilisateurs ? En fait je désire un système pour pouvoir laisser des
utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en
m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu
par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir
trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant
tls par exemple.
Je sens que je vais me faire incendier, mais bon je me lance : est-ce une bonne idée de mettre /usr/bin/passwd comme shell pour des utilisateurs ? En fait je désire un système pour pouvoir laisser des utilisateurs changer leur mot de passe (dans mon cas via SSH) tout en m'assurant qu'ils n'ont pas d'accès shell. Je ne suis pas convaincu par la manière qui consiste à passer par le web via un cgi.
Si c'est seulement pour pouvoir changer le mot de passe tu dois pouvoir trouver un autre moyen que ça. L'envoie d'un mail sur un smtp supportant tls par exemple.
Ou en gpg avec grunt?
-- fakeroot debian/rules troll
niin
L'envoie d'un mail sur un smtp supportant tls par exemple.
Y a-t-il un soft déjà écrit qui fait cela ?
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
Je suis bien conscient de cela, mais je suppose que ce programme a été maintes fois audité !
Ou en gpg avec grunt?
Je ne connais pas grunt. Mais je suppose que les utilisateurs moyens vont trouver cela trop compliqué pour pouvoir changer leur mot de passe.
C'est quoi la solution standart pour ce genre de problème ? un cgi ? Comment font les hébergeurs internet ?
Merci
L'envoie d'un mail sur un smtp supportant
tls par exemple.
Y a-t-il un soft déjà écrit qui fait cela ?
Je vois un problème "assez" grave. Si un jour une personne trouve une
faille locale dans /usr/bin/passwd, cette faille sera distante pour toi,
tous les utilisateurs pourront utiliser la faille pour gagner les
privilèges de l'administrateur. A déconseiller donc.
Je suis bien conscient de cela, mais je suppose que ce programme a été
maintes fois audité !
Ou en gpg avec grunt?
Je ne connais pas grunt. Mais je suppose que les utilisateurs moyens
vont trouver cela trop compliqué pour pouvoir changer leur mot de
passe.
C'est quoi la solution standart pour ce genre de problème ? un cgi ?
Comment font les hébergeurs internet ?
L'envoie d'un mail sur un smtp supportant tls par exemple.
Y a-t-il un soft déjà écrit qui fait cela ?
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
Je suis bien conscient de cela, mais je suppose que ce programme a été maintes fois audité !
Ou en gpg avec grunt?
Je ne connais pas grunt. Mais je suppose que les utilisateurs moyens vont trouver cela trop compliqué pour pouvoir changer leur mot de passe.
C'est quoi la solution standart pour ce genre de problème ? un cgi ? Comment font les hébergeurs internet ?
Merci
Eric Belhomme
(NIIN) wrote in news::
C'est quoi la solution standart pour ce genre de problème ? un cgi ? Comment font les hébergeurs internet ?
une page cgi ou php sur un serveur HTTPS est suffisament sur, amha. Ou
alors si il y a un serveur SMB tu peux syncroniser les mots de passes avec samba
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
niin@subdimension.com (NIIN) wrote in
news:32c94ad9.0307152305.6ca5779e@posting.google.com:
C'est quoi la solution standart pour ce genre de problème ? un cgi ?
Comment font les hébergeurs internet ?
une page cgi ou php sur un serveur HTTPS est suffisament sur, amha. Ou
alors si il y a un serveur SMB tu peux syncroniser les mots de passes avec
samba
--
Rico (RicoSpirit) - http://www.ricospirit.net
Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) :
http://www.ricospirit.net/inn/
C'est quoi la solution standart pour ce genre de problème ? un cgi ? Comment font les hébergeurs internet ?
une page cgi ou php sur un serveur HTTPS est suffisament sur, amha. Ou
alors si il y a un serveur SMB tu peux syncroniser les mots de passes avec samba
-- Rico (RicoSpirit) - http://www.ricospirit.net Pour en savoir autant que moi sur INN (c.a.d. pas grand chose !) : http://www.ricospirit.net/inn/
niin
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
Je reviens sur cela. Non, ce n'est pas une faille distante, vu que les utilisateurs doivent se logger via SSH. Sans compte sur la machine, il est impossible d'appeler passwd. Donc la faille est locale ( sinon, il n'existe pas de failles locales ou alors je ne comprends plus rien !). Dans ce cas-là, y a-t-il un gros problème de sécu ?
Je vois un problème "assez" grave. Si un jour une personne trouve une
faille locale dans /usr/bin/passwd, cette faille sera distante pour toi,
tous les utilisateurs pourront utiliser la faille pour gagner les
privilèges de l'administrateur. A déconseiller donc.
Je reviens sur cela. Non, ce n'est pas une faille distante, vu que les
utilisateurs doivent se logger via SSH. Sans compte sur la machine, il
est impossible d'appeler passwd. Donc la faille est locale ( sinon, il
n'existe pas de failles locales ou alors je ne comprends plus rien !).
Dans ce cas-là, y a-t-il un gros problème de sécu ?
Je vois un problème "assez" grave. Si un jour une personne trouve une faille locale dans /usr/bin/passwd, cette faille sera distante pour toi, tous les utilisateurs pourront utiliser la faille pour gagner les privilèges de l'administrateur. A déconseiller donc.
Je reviens sur cela. Non, ce n'est pas une faille distante, vu que les utilisateurs doivent se logger via SSH. Sans compte sur la machine, il est impossible d'appeler passwd. Donc la faille est locale ( sinon, il n'existe pas de failles locales ou alors je ne comprends plus rien !). Dans ce cas-là, y a-t-il un gros problème de sécu ?
niin
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il pas un problème ?
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il
pas un problème ?
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il pas un problème ?
Cedric Blancher
Dans sa prose, Burelle Marwan nous ecrivait :
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille locale, mais si tu mets comme shell passwd a un utilisateur et que passwd dispose d'une faille, il peut exploiter cette faille via une connexion distante (au travers de ssh par exemple). De la même manière que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est donc locale.
Une faille distante, c'est le CRC32 overflow de OpenSSH par exemple. Même sans login/pass, on l'exploite. La question de locale/distante ne concerne pas l'endroit où tu te trouves pour l'exploiter, mais bien la manière dont elle est exploitée. Ici, une fois que tu as passé la phase d'authentification (ssh, telnet, voire console), tu es logué sur la machine, et tu passes en attaque locale.
Enfin, je répète ce qui a déjà été dis...
Oui oui, en effet...
-- "Alors, je crois savoir ce qui n'allait pas. J'ai désactivé l'option : Send in rich HTML by default. Et je crois que c'était ça qui foutait le bordel." -+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
Dans sa prose, Burelle Marwan nous ecrivait :
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille
locale, mais si tu mets comme shell passwd a un utilisateur et que
passwd dispose d'une faille, il peut exploiter cette faille via une
connexion distante (au travers de ssh par exemple). De la même manière
que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès
quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un
compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est
donc locale.
Une faille distante, c'est le CRC32 overflow de OpenSSH par exemple. Même
sans login/pass, on l'exploite. La question de locale/distante ne concerne
pas l'endroit où tu te trouves pour l'exploiter, mais bien la manière
dont elle est exploitée. Ici, une fois que tu as passé la phase
d'authentification (ssh, telnet, voire console), tu es logué sur la
machine, et tu passes en attaque locale.
Enfin, je répète ce qui a déjà été dis...
Oui oui, en effet...
--
"Alors, je crois savoir ce qui n'allait pas. J'ai désactivé
l'option : Send in rich HTML by default. Et je crois que c'était
ça qui foutait le bordel."
-+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille locale, mais si tu mets comme shell passwd a un utilisateur et que passwd dispose d'une faille, il peut exploiter cette faille via une connexion distante (au travers de ssh par exemple). De la même manière que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est donc locale.
Une faille distante, c'est le CRC32 overflow de OpenSSH par exemple. Même sans login/pass, on l'exploite. La question de locale/distante ne concerne pas l'endroit où tu te trouves pour l'exploiter, mais bien la manière dont elle est exploitée. Ici, une fois que tu as passé la phase d'authentification (ssh, telnet, voire console), tu es logué sur la machine, et tu passes en attaque locale.
Enfin, je répète ce qui a déjà été dis...
Oui oui, en effet...
-- "Alors, je crois savoir ce qui n'allait pas. J'ai désactivé l'option : Send in rich HTML by default. Et je crois que c'était ça qui foutait le bordel." -+- EF in Guide du linuxien pervers : "Bien configurer son Netscape"
Pierre BETOUIN
Le Wed, 16 Jul 2003 13:27:45 +0000, NIIN a écrit :
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il pas un problème ?
Non puisque passwd est suidé...
Pierre
Le Wed, 16 Jul 2003 13:27:45 +0000, NIIN a écrit :
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il
pas un problème ?
Le Wed, 16 Jul 2003 13:27:45 +0000, NIIN a écrit :
avec un cgi, apache doit tourner en suExec, non ? Cela ne pose-t-il pas un problème ?
Non puisque passwd est suidé...
Pierre
shaddai
On 16 Jul 2003 15:37:17 GMT, Cedric Blancher wrote:
Dans sa prose, Burelle Marwan nous ecrivait :
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille locale, mais si tu mets comme shell passwd a un utilisateur et que passwd dispose d'une faille, il peut exploiter cette faille via une connexion distante (au travers de ssh par exemple). De la même manière que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est donc locale.
C'est vrai que la personne sera loggué "à distance", mais que l'attaque nécessite d'avoir un compte sur la machine, et d'en connaître le mot de passe. Dans ce cas on revient à une faille locale. Je n'y avais pas assez réfléchi lors de la réponse que j'ai faite :)
-- We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
On 16 Jul 2003 15:37:17 GMT, Cedric Blancher wrote:
Dans sa prose, Burelle Marwan nous ecrivait :
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille
locale, mais si tu mets comme shell passwd a un utilisateur et que
passwd dispose d'une faille, il peut exploiter cette faille via une
connexion distante (au travers de ssh par exemple). De la même manière
que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès
quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un
compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est
donc locale.
C'est vrai que la personne sera loggué "à distance", mais que l'attaque
nécessite d'avoir un compte sur la machine, et d'en connaître le mot de
passe. Dans ce cas on revient à une faille locale. Je n'y avais pas
assez réfléchi lors de la réponse que j'ai faite :)
--
We are the knights who say
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
On 16 Jul 2003 15:37:17 GMT, Cedric Blancher wrote:
Dans sa prose, Burelle Marwan nous ecrivait :
Oui et non, si il y a une faille dans passwd, il s'agit d'une faille locale, mais si tu mets comme shell passwd a un utilisateur et que passwd dispose d'une faille, il peut exploiter cette faille via une connexion distante (au travers de ssh par exemple). De la même manière que s'il y a une faille dans le shell de ton utilisateur.
Pas d'accord.
Une faille distante est une faille qui ne nécessite pas d'accès quelconque sur la machine, donc pas de compte. Or ici, le mec, il a un compte, et c'est via cet accès qu'il exploite une faille. Celle-ci est donc locale.
C'est vrai que la personne sera loggué "à distance", mais que l'attaque nécessite d'avoir un compte sur la machine, et d'en connaître le mot de passe. Dans ce cas on revient à une faille locale. Je n'y avais pas assez réfléchi lors de la réponse que j'ai faite :)
-- We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc
