Je surfais, je suis tombé sur ça :
http://bugs.debian.org/cgi-bin/bugreport.cgi?archive=no&bug=325785
qui mène à ça :
http://www.rgod.altervista.org/phpldap.html
J'ai utilisé le "googledork" du bas, et j'ai cherché un site
en version récente (une 0.9.6, au canada, par exemple) et
j'ai essayé le coup du welcome.
Ben, j'ai le fichier passwd sous les yeux
o_O
Trop facile.
Bon, je vais me fendre d'un mail au site au question.
--
Je sais que c'est crétin de le faire et de le dire, merci.
Tu veux dire qu'il est possible de partir de G/KZp84Y$7i5FfBYhbGi8jV27kl8yU. et d'en déduire "toto"? Il me semblait plutot qu'on faisait l'inverse, à savoir crypter "toto", et constater que la chaine générée était identique à l'une de celle se trouvant dans shadow.
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot de passe crypté deux fois donnera deux cryptages différents. Donc, c'est un peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le système d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret : Luser a pour mot de passe 'toto', qui figure après cryptage comme étant G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow. Lors de sa prochaine tentative de login, Luser va taper 'toto', et comme l'algo de cryptage n'est pas réversible, son MdP sera à nouveau encrypté pour comparer le résultat obtenu à la chaîne qui figure dans /etc/shadow. Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera pas la même, il pourra très bien obtenir T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui ne "matchera" pas avec la chaîne dans shadow. Comment alors l'authentification pourra-t-elle avoir lieu ? J'ai manqué une étape, ou mal compris un truc ?
je ne connais pas le detail de l'implementation de la fct
mais il serait " tu peus noter le conditionnel" logique de penser que le systeme sait ou est l'aleatoire et l'humain lui ne le sait pas ou si il veut le savoir il doit rentrer
et que cela doit pouvoir etre configurable pour les paranos
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Stéphane CARPENTIER a wroté :
Tu veux dire qu'il est possible de partir de
G/KZp84Y$7i5FfBYhbGi8jV27kl8yU. et d'en déduire "toto"?
Il me semblait plutot qu'on faisait l'inverse, à savoir crypter "toto",
et constater que la chaine générée était identique à l'une de celle se
trouvant dans shadow.
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot
de passe crypté deux fois donnera deux cryptages différents. Donc,
c'est un
peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le système
d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret :
Luser a pour mot de passe 'toto', qui figure après cryptage comme étant
G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow.
Lors de sa prochaine tentative de login, Luser va taper 'toto', et comme
l'algo de cryptage n'est pas réversible, son MdP sera à nouveau encrypté
pour comparer le résultat obtenu à la chaîne qui figure dans /etc/shadow.
Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera pas
la même, il pourra très bien obtenir T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui
ne "matchera" pas avec la chaîne dans shadow.
Comment alors l'authentification pourra-t-elle avoir lieu ?
J'ai manqué une étape, ou mal compris un truc ?
je ne connais pas le detail de l'implementation de la fct
mais il serait " tu peus noter le conditionnel"
logique de penser que le systeme sait ou est l'aleatoire
et l'humain lui ne le sait pas
ou si il veut le savoir il doit rentrer
et que cela doit pouvoir etre configurable pour les paranos
--
des conneries j'en ai dites oui oui je vous assure...
mais elles n'engagent que votre perception
remy
Tu veux dire qu'il est possible de partir de G/KZp84Y$7i5FfBYhbGi8jV27kl8yU. et d'en déduire "toto"? Il me semblait plutot qu'on faisait l'inverse, à savoir crypter "toto", et constater que la chaine générée était identique à l'une de celle se trouvant dans shadow.
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot de passe crypté deux fois donnera deux cryptages différents. Donc, c'est un peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le système d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret : Luser a pour mot de passe 'toto', qui figure après cryptage comme étant G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow. Lors de sa prochaine tentative de login, Luser va taper 'toto', et comme l'algo de cryptage n'est pas réversible, son MdP sera à nouveau encrypté pour comparer le résultat obtenu à la chaîne qui figure dans /etc/shadow. Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera pas la même, il pourra très bien obtenir T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui ne "matchera" pas avec la chaîne dans shadow. Comment alors l'authentification pourra-t-elle avoir lieu ? J'ai manqué une étape, ou mal compris un truc ?
je ne connais pas le detail de l'implementation de la fct
mais il serait " tu peus noter le conditionnel" logique de penser que le systeme sait ou est l'aleatoire et l'humain lui ne le sait pas ou si il veut le savoir il doit rentrer
et que cela doit pouvoir etre configurable pour les paranos
-- des conneries j'en ai dites oui oui je vous assure... mais elles n'engagent que votre perception remy
Kevin Denis
Le 02-09-2005, Guillaume <guillaume.en> a écrit :
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot de passe crypté deux fois donnera deux cryptages différents. Donc, c'est un peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le système d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret : Luser a pour mot de passe 'toto', qui figure après cryptage comme étant G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow. Lors de sa prochaine tentative de login, Luser va taper 'toto', et comme l'algo de cryptage n'est pas réversible, son MdP sera à nouveau encrypté pour comparer le résultat obtenu à la chaîne qui figure dans /etc/shadow. Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera pas la même, il pourra très bien obtenir T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui ne "matchera" pas avec la chaîne dans shadow. Comment alors l'authentification pourra-t-elle avoir lieu ? J'ai manqué une étape, ou mal compris un truc ?
(mise du mot de passe samba a "samba"):
samba:$1$e1l0BG41$AZ4HLn1sLoC74PPr6yAeH/:13028:0:99999:7::: ^^^ ^ avec "toto" samba:$1$9V41fCG4$0wnvbnh2JrB8B.H9jRwmg1:13028:0:99999:7::: ^^^ ^ avec "luser" samba:$1$C/K13nD4$LHggDGeAWW9lYlc2NtpKm/:13028:0:99999:7::: ^^^ ^ Curieusement, les linux sont fournis avec des fichiers ranges qui s'appellent "man". Je me risque a taper man shadow. qui dit: SEE ALSO getpwent(3), shadow(5)
et man 5 shadow Le champs mot de passe doit être rempli. Le mot de passe crypté comprend 13 à 24 caractères pris dans l'alphabet réduit a-z, A-Z, 0-9, . et /. Consultez crypt(3) pour plus d'information sur le traitement de cette chaîne.
et man 3 crypt informe: (snip) salt is a two-character string chosen from the set [a-zA-Z0-9./]. This string is used to perturb the algo rithm in one of 4096 different ways. (...) The glibc2 version of this function has the following additional features. If salt is a character string start ing with the three characters "$1$" followed by at most eight characters, and optionally terminated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, and outputs up to 34 bytes, namely "$1$<string>$", where "<string>" stands for the up to 8 characters following "$1$" in the salt, followed by 22 bytes chosen from the set [a-zA-Z0-9./]. The entire key is significant here (instead of only the first 8 bytes).
-- Kevin
Le 02-09-2005, Guillaume <guillaume.en> a écrit :
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot de
passe crypté deux fois donnera deux cryptages différents. Donc, c'est un
peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le
système d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret :
Luser a pour mot de passe 'toto', qui figure après cryptage comme
étant G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow.
Lors de sa prochaine tentative de login, Luser va taper 'toto', et
comme l'algo de cryptage n'est pas réversible, son MdP sera à nouveau
encrypté pour comparer le résultat obtenu à la chaîne qui figure dans
/etc/shadow.
Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera
pas la même, il pourra très bien obtenir
T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui ne "matchera" pas avec la chaîne
dans shadow.
Comment alors l'authentification pourra-t-elle avoir lieu ?
J'ai manqué une étape, ou mal compris un truc ?
(mise du mot de passe samba a "samba"):
samba:$1$e1l0BG41$AZ4HLn1sLoC74PPr6yAeH/:13028:0:99999:7:::
^^^ ^
avec "toto"
samba:$1$9V41fCG4$0wnvbnh2JrB8B.H9jRwmg1:13028:0:99999:7:::
^^^ ^
avec "luser"
samba:$1$C/K13nD4$LHggDGeAWW9lYlc2NtpKm/:13028:0:99999:7:::
^^^ ^
Curieusement, les linux sont fournis avec des fichiers ranges
qui s'appellent "man". Je me risque a taper man shadow. qui dit:
SEE ALSO
getpwent(3), shadow(5)
et man 5 shadow
Le champs mot de passe doit être rempli. Le mot de passe
crypté comprend 13 à 24 caractères pris dans l'alphabet
réduit a-z, A-Z, 0-9, . et /. Consultez crypt(3) pour
plus d'information sur le traitement de cette chaîne.
et man 3 crypt informe:
(snip)
salt is a two-character string chosen from the set
[a-zA-Z0-9./]. This string is used to perturb the algo
rithm in one of 4096 different ways.
(...)
The glibc2 version of this function has the following
additional features. If salt is a character string start
ing with the three characters "$1$" followed by at most
eight characters, and optionally terminated by "$", then
instead of using the DES machine, the glibc crypt function
uses an MD5-based algorithm, and outputs up to 34 bytes,
namely "$1$<string>$", where "<string>" stands for the up
to 8 characters following "$1$" in the salt, followed by
22 bytes chosen from the set [a-zA-Z0-9./]. The entire
key is significant here (instead of only the first 8
bytes).
Oui, mais comme dans le cryptage il y a une partie aléatoire, un mot de passe crypté deux fois donnera deux cryptages différents. Donc, c'est un peu plus fin, mais dans les grandes lignes, c'est ça.
Je ne comprends pas comment c'est possible, du moins comment le système d'authentification fonctionne dans ces conditions.
Je vais tâcher d'exposer mes doutes à partir d'un exemple concret : Luser a pour mot de passe 'toto', qui figure après cryptage comme étant G/KZp84Y$7i5FfBYhbGi8jV27kl8yU dans /etc/shadow. Lors de sa prochaine tentative de login, Luser va taper 'toto', et comme l'algo de cryptage n'est pas réversible, son MdP sera à nouveau encrypté pour comparer le résultat obtenu à la chaîne qui figure dans /etc/shadow. Mais si ce cryptage comprend une partie aléatoire, la chaîne ne sera pas la même, il pourra très bien obtenir T/XMc84L$7v5SsOLuoTv8wI27xy8lH, qui ne "matchera" pas avec la chaîne dans shadow. Comment alors l'authentification pourra-t-elle avoir lieu ? J'ai manqué une étape, ou mal compris un truc ?
(mise du mot de passe samba a "samba"):
samba:$1$e1l0BG41$AZ4HLn1sLoC74PPr6yAeH/:13028:0:99999:7::: ^^^ ^ avec "toto" samba:$1$9V41fCG4$0wnvbnh2JrB8B.H9jRwmg1:13028:0:99999:7::: ^^^ ^ avec "luser" samba:$1$C/K13nD4$LHggDGeAWW9lYlc2NtpKm/:13028:0:99999:7::: ^^^ ^ Curieusement, les linux sont fournis avec des fichiers ranges qui s'appellent "man". Je me risque a taper man shadow. qui dit: SEE ALSO getpwent(3), shadow(5)
et man 5 shadow Le champs mot de passe doit être rempli. Le mot de passe crypté comprend 13 à 24 caractères pris dans l'alphabet réduit a-z, A-Z, 0-9, . et /. Consultez crypt(3) pour plus d'information sur le traitement de cette chaîne.
et man 3 crypt informe: (snip) salt is a two-character string chosen from the set [a-zA-Z0-9./]. This string is used to perturb the algo rithm in one of 4096 different ways. (...) The glibc2 version of this function has the following additional features. If salt is a character string start ing with the three characters "$1$" followed by at most eight characters, and optionally terminated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, and outputs up to 34 bytes, namely "$1$<string>$", where "<string>" stands for the up to 8 characters following "$1$" in the salt, followed by 22 bytes chosen from the set [a-zA-Z0-9./]. The entire key is significant here (instead of only the first 8 bytes).
-- Kevin
Manuel Leclerc
[shadow]
The glibc2 version of this function [...]
L'interpréteur de commande est un processus. Dedans, on peut taper "su", qui est un autre processus, et du coup, on change d'identité, c'est ça ? C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
-- I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question. --Charles Babbage
[shadow]
The glibc2 version of this function [...]
L'interpréteur de commande est un processus. Dedans,
on peut taper "su", qui est un autre processus, et
du coup, on change d'identité, c'est ça ?
C'est très mystérieux (pour moi). Existe-t-il un
lien qui explique les mécanismes à l'oeuvre ?
--
I am not able to rightly apprehend the kind of confusion
of ideas that could provoke such a question.
--Charles Babbage
L'interpréteur de commande est un processus. Dedans, on peut taper "su", qui est un autre processus, et du coup, on change d'identité, c'est ça ? C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
-- I am not able to rightly apprehend the kind of confusion of ideas that could provoke such a question. --Charles Babbage
l'indien
On Fri, 02 Sep 2005 12:43:50 +0200, Manuel Leclerc wrote:
[shadow]
The glibc2 version of this function [...]
L'interpréteur de commande est un processus. Dedans, on peut taper "su", qui est un autre processus, et du coup, on change d'identité, c'est ça ? C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
Sous Unix, traditionnellement, root a le droit de tout faire. su est un processus suid root, c'est à dire qu'il s'execute toujours en tant que root, quel que soit l'utilisateur qui le lance. Il peut donc appeler l'appel système setuid qui change le User-ID du process courant et lancer un shell qui sera alors lancé avec la nouvelle identité. Il y a en fait des subtilités car il existe en réalité plusieurs User-ID, mais le méchanisme est là, en gros.
On Fri, 02 Sep 2005 12:43:50 +0200, Manuel Leclerc wrote:
[shadow]
The glibc2 version of this function [...]
L'interpréteur de commande est un processus. Dedans,
on peut taper "su", qui est un autre processus, et
du coup, on change d'identité, c'est ça ?
C'est très mystérieux (pour moi). Existe-t-il un
lien qui explique les mécanismes à l'oeuvre ?
Sous Unix, traditionnellement, root a le droit de tout faire.
su est un processus suid root, c'est à dire qu'il s'execute toujours en
tant que root, quel que soit l'utilisateur qui le lance.
Il peut donc appeler l'appel système setuid qui change le User-ID du
process courant et lancer un shell qui sera alors lancé avec la nouvelle
identité.
Il y a en fait des subtilités car il existe en réalité plusieurs
User-ID, mais le méchanisme est là, en gros.
On Fri, 02 Sep 2005 12:43:50 +0200, Manuel Leclerc wrote:
[shadow]
The glibc2 version of this function [...]
L'interpréteur de commande est un processus. Dedans, on peut taper "su", qui est un autre processus, et du coup, on change d'identité, c'est ça ? C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
Sous Unix, traditionnellement, root a le droit de tout faire. su est un processus suid root, c'est à dire qu'il s'execute toujours en tant que root, quel que soit l'utilisateur qui le lance. Il peut donc appeler l'appel système setuid qui change le User-ID du process courant et lancer un shell qui sera alors lancé avec la nouvelle identité. Il y a en fait des subtilités car il existe en réalité plusieurs User-ID, mais le méchanisme est là, en gros.
Manuel Leclerc
su est un processus suid root, c'est à dire qu'il s'execute toujours en tant que root, quel que soit l'utilisateur qui le lance. Il peut donc appeler l'appel système setuid qui change le User-ID du process courant et lancer un shell qui sera alors lancé avec la nouvelle identité.
Donc c'est su qui effectue la vérification avec shadow ? Par curiosité, il y a eu des attaques dans lesquelles on arrivait à faire prendre des vessies pour des lanternes à ce pauvre su ?
su est un processus suid root, c'est à dire qu'il
s'execute toujours en tant que root, quel que soit
l'utilisateur qui le lance.
Il peut donc appeler l'appel système setuid qui
change le User-ID du process courant et lancer
un shell qui sera alors lancé avec la nouvelle
identité.
Donc c'est su qui effectue la vérification avec
shadow ?
Par curiosité, il y a eu des attaques dans lesquelles
on arrivait à faire prendre des vessies pour des lanternes
à ce pauvre su ?
su est un processus suid root, c'est à dire qu'il s'execute toujours en tant que root, quel que soit l'utilisateur qui le lance. Il peut donc appeler l'appel système setuid qui change le User-ID du process courant et lancer un shell qui sera alors lancé avec la nouvelle identité.
Donc c'est su qui effectue la vérification avec shadow ? Par curiosité, il y a eu des attaques dans lesquelles on arrivait à faire prendre des vessies pour des lanternes à ce pauvre su ?
C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force d'Unix, la simplicité des mécanismes mis en jeu.
"Manuel Leclerc" , dans le message <43182ce7@neottia.net>, a écrit :
C'est très mystérieux (pour moi). Existe-t-il un
lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est
vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force
d'Unix, la simplicité des mécanismes mis en jeu.
C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force d'Unix, la simplicité des mécanismes mis en jeu.
Michel Billaud
Nicolas George <nicolas$ writes:
"Manuel Leclerc" , dans le message , a écrit :
C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force d'Unix, la simplicité des mécanismes mis en jeu.
C'est à dire qu'avec Unix, pour faire des choses compliquées, on y arrive en combinant des mécanismes simples. L'embêtant c'est que la combinaison est parfois compliquée.
Avec d'autres systèmes, il est aussi compliqué de faire des choses simples avec des mécanismes compliqués :-)
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Nicolas George <nicolas$george@salle-s.org> writes:
"Manuel Leclerc" , dans le message <43182ce7@neottia.net>, a écrit :
C'est très mystérieux (pour moi). Existe-t-il un
lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est
vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force
d'Unix, la simplicité des mécanismes mis en jeu.
C'est à dire qu'avec Unix, pour faire des choses compliquées, on y
arrive en combinant des mécanismes simples. L'embêtant c'est que la
combinaison est parfois compliquée.
Avec d'autres systèmes, il est aussi compliqué de faire des choses
simples avec des mécanismes compliqués :-)
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
C'est très mystérieux (pour moi). Existe-t-il un lien qui explique les mécanismes à l'oeuvre ?
N'importe quel cours de débutant sur Unix devrait faire l'affaire. C'est vraiment élémentaire, c'est d'ailleurs ce qui fait la principale force d'Unix, la simplicité des mécanismes mis en jeu.
C'est à dire qu'avec Unix, pour faire des choses compliquées, on y arrive en combinant des mécanismes simples. L'embêtant c'est que la combinaison est parfois compliquée.
Avec d'autres systèmes, il est aussi compliqué de faire des choses simples avec des mécanismes compliqués :-)
MB -- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
Kevin Denis
Le 02-09-2005, Michel Billaud a écrit :
Avec d'autres systèmes, il est aussi compliqué de faire des choses simples avec des mécanismes compliqués :-)
Je viens de tomber sur une calculatrice a l'aide de sendmail.cf
http://www.chiark.greenend.org.uk/~matthews/calculator.cf Je salue la prouesse, mais m'interroge sur l'utilite.
De meme, on peut jouer a sokoban avec sed. http://aurelio.net/sed/sokoban/sokoban.sed.html en sachant que la page est coloree a l'aide d'un autre script sed. -- Kevin
Le 02-09-2005, Michel Billaud <billaud@labri.fr> a écrit :
Avec d'autres systèmes, il est aussi compliqué de faire des choses
simples avec des mécanismes compliqués :-)
Je viens de tomber sur une calculatrice a l'aide de sendmail.cf
http://www.chiark.greenend.org.uk/~matthews/calculator.cf
Je salue la prouesse, mais m'interroge sur l'utilite.
De meme, on peut jouer a sokoban avec sed.
http://aurelio.net/sed/sokoban/sokoban.sed.html
en sachant que la page est coloree a l'aide d'un autre script sed.
--
Kevin
Avec d'autres systèmes, il est aussi compliqué de faire des choses simples avec des mécanismes compliqués :-)
Je viens de tomber sur une calculatrice a l'aide de sendmail.cf
http://www.chiark.greenend.org.uk/~matthews/calculator.cf Je salue la prouesse, mais m'interroge sur l'utilite.
De meme, on peut jouer a sokoban avec sed. http://aurelio.net/sed/sokoban/sokoban.sed.html en sachant que la page est coloree a l'aide d'un autre script sed. -- Kevin
Kevin Denis
Le 02-09-2005, Manuel Leclerc a écrit :
su est un processus suid root
Donc c'est su qui effectue la vérification avec shadow ? Par curiosité, il y a eu des attaques dans lesquelles on arrivait à faire prendre des vessies pour des lanternes à ce pauvre su ?
bon, "su vulnerability" dans google. Hop, un vieux truc
de 2002 sur tru64. http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-08/0007.html
Le programme "su" est lance, en argument, il recoit plein d'octet curieusement, ce qui fait qu'il se prend les pieds dans sa propre execution, et se met a executer le code qu'on lui a donne en parametre. Ca s'appelle vulgairement un buffer-overflow.
Mais bah, le principe reste le meme pour n'importe quel binaire suid ou lance par root. -- Kevin
Le 02-09-2005, Manuel Leclerc <manuel.leclerc@alussinan.org> a écrit :
su est un processus suid root
Donc c'est su qui effectue la vérification avec
shadow ?
Par curiosité, il y a eu des attaques dans lesquelles
on arrivait à faire prendre des vessies pour des lanternes
à ce pauvre su ?
bon, "su vulnerability" dans google. Hop, un vieux truc
de 2002 sur tru64.
http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-08/0007.html
Le programme "su" est lance, en argument, il recoit plein d'octet
curieusement, ce qui fait qu'il se prend les pieds dans sa propre
execution, et se met a executer le code qu'on lui a donne en
parametre. Ca s'appelle vulgairement un buffer-overflow.
Mais bah, le principe reste le meme pour n'importe quel binaire suid
ou lance par root.
--
Kevin
Donc c'est su qui effectue la vérification avec shadow ? Par curiosité, il y a eu des attaques dans lesquelles on arrivait à faire prendre des vessies pour des lanternes à ce pauvre su ?
bon, "su vulnerability" dans google. Hop, un vieux truc
de 2002 sur tru64. http://www.derkeiler.com/Mailing-Lists/Securiteam/2002-08/0007.html
Le programme "su" est lance, en argument, il recoit plein d'octet curieusement, ce qui fait qu'il se prend les pieds dans sa propre execution, et se met a executer le code qu'on lui a donne en parametre. Ca s'appelle vulgairement un buffer-overflow.
Mais bah, le principe reste le meme pour n'importe quel binaire suid ou lance par root. -- Kevin
Stéphane CARPENTIER
Richard Delorme wrote:
En quoi essayer tous les mots de passe n'est pas mathématique ?
La question initiale était :
il est en principe et mathematiquement impossible de partir du fichier et arriver au mot de passe en clair
Dans le cas ou tu essayes tous les mots de passe, un par un, tu ne vas pas me dire que tu pars du fichier pour arriver au mot de passe en clair. Tu ne fais pas d'analyse mathématique du fichier. Tu utilises le fichiers pour éviter les protections du système qui vont t'empêcher de tester trop de connexions ratées en un temps trop court. Ce n'est donc pas le codage que tu casses mathématiquement. Car si les mots de passe n'étaient pas codés, il te faudrait _exactement_ le même temps pour les trouver.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
Richard Delorme wrote:
En quoi essayer tous les mots de passe n'est pas mathématique ?
La question initiale était :
il est en principe et mathematiquement impossible
de partir du fichier et arriver au mot de passe en clair
Dans le cas ou tu essayes tous les mots de passe, un par un, tu ne
vas pas me dire que tu pars du fichier pour arriver au mot de passe
en clair. Tu ne fais pas d'analyse mathématique du fichier. Tu utilises
le fichiers pour éviter les protections du système qui vont t'empêcher
de tester trop de connexions ratées en un temps trop court.
Ce n'est donc pas le codage que tu casses mathématiquement. Car si les
mots de passe n'étaient pas codés, il te faudrait _exactement_ le même
temps pour les trouver.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid.
http://stef.carpentier.free.fr/
En quoi essayer tous les mots de passe n'est pas mathématique ?
La question initiale était :
il est en principe et mathematiquement impossible de partir du fichier et arriver au mot de passe en clair
Dans le cas ou tu essayes tous les mots de passe, un par un, tu ne vas pas me dire que tu pars du fichier pour arriver au mot de passe en clair. Tu ne fais pas d'analyse mathématique du fichier. Tu utilises le fichiers pour éviter les protections du système qui vont t'empêcher de tester trop de connexions ratées en un temps trop court. Ce n'est donc pas le codage que tu casses mathématiquement. Car si les mots de passe n'étaient pas codés, il te faudrait _exactement_ le même temps pour les trouver.
Stéphane
--
Pour me répondre, traduire gratuit en anglais et virer le .invalid. http://stef.carpentier.free.fr/
