c'est le chiffrement par masque jetable. C'est une exception! Cette méthode est tellement contraignante qu'elle est rarement utilisée.
Ce n'est pas une exception ! C'est le Graal des cryptographes : un truc dont on a prouvé que c'était incassable, c'est quand même fort non ? Surout que c'est le seul !
Quant à son utilisation, tu te trompes : ça sert courament des les communications militaires, pour le téléphone rouge.
Pour ton Linux, il me semble que le "telnet sécurisé" qui fonctionne justement avec des OTPs (à vérifier)
Il ne faut jamais perdre de vue la durée souhaitée pour la confidentialité des infos...
Certes, mais comme tu le dis précédemment, si tu utilises un algo "pourri" (je reprends ta terminologie et je comprends cela comme désignant un algo pour lequel une attaque structurelle facile, simple et réalisable existe) alors tu t'exposes d'autant.
Je pense plutôt que le chiffrement à utiliser dépend de l'importance que tu attaches à tes données, et pas de leur "durée de vie".
Par exemple, si je suis un gros actionnaire de la société X et que je décide de vendre toutes mes actions de cette société, l'ordre de vente immédiate que j'envoie à ma banque a intérêt à être sacrément protégé. Sinon, supposons que tu écoutes mes communications et que tu parviennes à déchiffrer mon ordre : tu vas essayer de vendre tes propres actions avant moi pour faire chuter le cours de l'action et me ruiner.
(HS: enfin quelqu'un qui ne dit pas "cryptage" :)
Merci ;-)
Je connais assez bien la terminologie (je viens de soutenir un doctorat d'info où la crypto occupe une grosse place).
Excuse moi, mais je maintiens TOUT ce que j'ai écrit. En revanche, je pense que tu n'es pas très clair/précis.
Tout simplement parce que ça n'a rien à voir? Evidemment, plus ta clé est longue mieux c'est.
Héhé, tu n'as pas l'impression que tes 2 phrases se contredisent ?
Concernant ton exemple avec ton XOR sur 4096 bits, si mes données à chiffrer font elles-mêmes 4096 bits, tu peux toujours rêver pour parvenir à casser ça : il s'agit du système appelé One Time Pad. Manque de pot, c'est le seul système dont on a prouvé qu'il était absolument sûr (i.e. incassable). Regarde les articles de Shannon de 1948 et 1949 : il explique tout cela, je ne sais plus dans lequel des 2.
Désolé, mais la complexité de l'attaque n'est 2^(n-1) que pendant le premier cours d'initiation à la crypto... après on passe à la cryptanalyse, et là on tombe de haut parfois.
Voilà la phrase importante !
Je répète : la complexité de l'attaque exhaustive d'un algorithme de chiffrement symétrique dont la clé est de longueur n est 2^(n-1) en moyenne.
Tous les mots de cette phrase sont importants et je ne pense pas avoir écrit une connerie.
Ensuite, tu passes à la cryptanalyse, mais là, il s'agit complètement d'autre chose. Une cryptanalyse vise un algorithme précis et n'est pas générale comme peut l'être l'attaque exhaustive. C'est d'ailleurs pour ça que, pour comparer les cryptanalyses, on précise les conditions dans lesquelles l'attaque est possible (cad souvent le nombre de paires (clair, chiffré) nécessaires pour que l'attaque réussisse).
Maintenant, je commence à comprendre ce que tu voulais dire, et je trouve vraiment que tu n'es pas clair.
Les crpytanalyses sont des attaques structurelles : elles passent par une étude approfondie des fonctions qui interviennent dans l'algorithme de (dé)chiffrement.
Pour le moment, on connaît qq cryptanalyses contre DES (différentielle ou linéaire par exemple), mais on n'en connaît pas encore contre AES.La crpytanalyse différentielle date de 1991 (par Biham et Shamir), mais tout le monde continue quand même à utiliser DES.
Pourquoi ?
Simplement parce que les conditions de mise en oeuvre de cette attaque sont difficiles à obtenir (attention, je n'ai pas dit impossible). En effet, il faut 2^47 paires (clair, chiffré) pour cela
Je ne prétends certainement pas que personne ne trouvera une cryptanalyse contre AES (et elle sera peut-être bien plus efficace que les cryptanalyses connues contre DES), mais à un moment donné, tu es obligé d'utiliser ce que tu as sous la main, même si tu sais qu'un jor, ce sera sans doute insuffisant.
Bref, tu peux utiliser AES les yeux fermés aujourd'hui, mais peut-être que demain, qq'un cassera AES pour de bon (enfin, demain, je doute ;)
On ne peut pas faire confiance à nos prévisions de ce que seront les moyens technologiques dans 5 ou 10 ans...
Dans ce cas tu arrêtes immédiatement d'utiliser une voiture parce que peut-être que la téléportation sera au point d'ici 5 ou 10 ans ?
Je ne suis absolument pas d'accord avec ça ! Au ocntraire même : tu es obligé de faire confiance. Seulement, il faut avoir conscience des limites et risques éventuels.
Je recopie encore une fois ce que tu as écrit : Pour beaucoup d'algos qui paraîssent très bien à première vue, il existe des méthodes très simples de cassage.
Tu relieras attentivement ce que j'ai écrit, et je n'ai jamais prétendu que DES n'était pas cassé (mais je maintiens que ce ne n'est pas simple, la puce dont tu parles coûte plusieurs milliers de $ et les crpytanalyse du DES ne sont pas aussi évidente que tu le laisse entendre.
Quant à RC5-64, autant pour moi, je ne savais pas qu'il avait été cassé comme tu le laisses entendre (je veux bien voir de la doc là-dessus d'ailleurs).
Plutôt que de sortir de vagues généralités (oui, j'insiste sur le pléonasme), tu ne voudrais pas donner des exemples précis ?
Pour beaucoup d'algos qui paraîssent très bien à première vue, il existe des méthodes très simples de cassage.
Je ne me permettrai pas de qualifier la crpytanalyse différentielle ou linéaire (pour DES) de "très simple", idem pour la plupart des méthodes de cribles (pour RSA)
Tu parlais peut-être du code de César ou du chiffrement de Vigenère ? Certes à leur époques, ces méthodes étaient performantes ... et peut-être que DES, AES ou RSA sembleront aussi inefficaces dans qq siècles, mais c'est de la science-fiction pour le moment.
- Les algos de chiffrement à clé privée sont plus ou moins vulnérables aux attaques statistiques, en plus si tu as plusieurs documents dont du connais les originaus ça te rend la tâche plus facile, etc
Il existe différents types d'attaques qui dépendent des conditions :
- attaque à chiffré seul
- attaque à clair connu
- attaque à chiffré choisi
- attaque à clair choisi
Pour ces 2 dernières, il existe des formes adaptatives pour les algo asymétriques.
Ensuite, les attaques statistiques dont tu parles dépendent d'un algorithme précis et vise en fait les fonctions qui interviennent dans le chiffrement. Par exemple, la cryptanalyse différentielle (contre DES) est une attaque à clair choisi qui nécessite la connaissance des chiffrés correspondant à des couples de messages clairs dont la différence est fixée.
Alors c'est sûr, plus tu connais de choses, plus c'est facle ... Ainsi, la meilleure cryptanalyse différentielle connue pour casser DES nécessite quand même 2^47 paires (clair, chiffré).
- tu ne sais pas si certains algos à clé secrète n'ont pas de failles. tu ne peux pas connaître l'évolution des techniques, mais surtout des *algos*
Certes, je me place dans l'état actuel des connaissances et je préfère éviter la science-fiction ... même si j'adore lire ce genre de romans ;-)
Je pense que tu devrais te replonger dans des cours de crypto...
La qualité de l'algo est beaucoup plus importante que la longueur de la clé.
Non, sans blague ;-)
<mesquin>J'aimerais bcp voir un algo de chiffrement avec une clé de 1 bit ... bjr la qualité ;-]</mesquin>
Pour faire simple, on va considérer les algo de chiffrement symétrique. La seule mesure de la qualité d'un tel algo est la complexité de la meilleure attaque connue, la valeur de référence étant donnée par la complexité de l'attaque exhaustive (i.e. si tu as une clé de n bits "libres", tu testes les 2^n clés => tu fais, en moyenne, 2^(n-1) tentatives avant de trouver la bonne clé)
A part ça, j'aimerais bien savoir comment tu dissocies la qualité de l'algo et la longueur de la clé.
Recherche sur ton moteur de recherche favori "Kerckhoffs". Il a énoncé au 19ème siècle un résultat qui stipule que la sécurité d'un crypto-système devait reposer sur ses clés. Depuis, les algorithmes sont rendus publics et les attaques se focalisent sur l'obtention de ces dernières.
Si on trouve un algo pour casser le chiffre, la longueur de la clé importe tout à coup beaucuop moins...
Bravo ! Qui t'a soufflé ça ? Tu candidates pour la médaille Fields cette année ?
Sérieusement, un algo de cassage dépend forcément de la longueur de la clé. Ainsi, même si RSA 512 a été cassé, avec un RSA 4096 tu es peinard pour quelques siècles ... et tranquille encore, à moins bien sûr que les ordinateurs quantiques voient le jour ou qu'une découverte majeure soit réalisée en théorie des nombres.
elle est limitée sur la longueur des clés (au point d'être quasiment inutile)
La longueur des clés de CHIFFREMENT est limitée à 128 bits : pour la plupart des algo de chiffrement à clé secrète, tu peux t'assoir dessus pour quelques milénaires (au moins) avant de réussir à casser quoique ce soit. Pour les algo à clé publique, ceux fondés sur des courbes elliptiques devraient encore tenir qq temps avant que 128 bits ne soient plus siffisants.
A une époque, il y avait aussi une obligation de déclarer tout chiffrement avec sa clé à l'état
Même maintenant, il faut déposer le logiciel, et pas sa clé tant que tu respectes la taille de clé prévue par la loi.
Concernant l'utilisation personnelle d'openssh, tu n'es soumis à rien.
Bien que je sois un fervent défenseur du LL et de l'open source, je suis a regret de dire FAUX !
Regarde les multiples bogues de sudo par exemple. Ou encore le problème du crc32 avec les serveurs ssh. Le bogue était connu et référencé depuis plusieurs mois avant d'être corrigé.
J'en ai marre de voir partout que les logiciels open source ont moins de problème puisque le code est disponible !!!
Sérieusement, cmbien de pesonnes ici ont réellement audité des sources ?
En fait, la plupart des personnes se disent que puisque c'est en open source, il y a bien qq'un pour regarder le code, et que ce n'est pas donc la peine de s'embêter à le faire. Et je ne parle pas du niveau de compétences nécessaire.
moi, un truc comme ça, ça me laisse penser que c'est délibéré comme fonctionnalité
Qu'est-ce qui te laisse penser ça ?
Le %00 correspond au caractère de fin de chaîne et c'est un manière bien connue de faire exécuter du code à un script CGI écrit en perl par exemple.
Je ne pense vraiment pas que ça ait été voulu. Quand le browseur lit l'URL, il s'arrête lorsqu'il rencontre la fon de chaîne (le %00 donc) ... mais l'interpréteur continue, exactement comme avec perl.
Pour ton cas, soit tu en rachètes un, soit tu expédies ton exemplaire à l'adresse indiquée pour l'abonnement en mettant une lettre de protestation et tu devrais en recevoir un tout beau tout neuf.
A mon avis (impartial bien sûr), choisit la première solution ;-]
<msg perso>Lefinnois, tu pourrais passer sur irc ?</msg perso>
Oui, dans l'esprit, j'espère bien que MISC est plus proche de phrack que d'un autre magazine contre lequel j'ai une certaine amertume, voire plus ;-/
Chers lecteurs, merci de nous prévenir si nous ne respections plus cette ligne.
Sans vouloir cracher sur quiconque (et ce n'est pourtant pas l'envie qui m'en manque), est-ce que tous ces magazines sont réellement comparables ? Je m'abstiens de donner une réponse car :
je ne serai pas très objectif
je risque d'être vulgaire à l'encontre de HZV
En revanche, si un lecteur veut bien répondre en toute objectivé au message précédent, ça m'intéresse :)
Je pense la même chose. Bon, d'accord, je ne suis pas très objectif, c'est pour ça que je me suis retenu.
Mais ça me fait d'autant plus chier que la news sur zataz mag était elle passée en première page ...
M'enfin !
il y a eu des failles
C'est pas vraiment des failles, c'est juste qu'il y a des moyens de sortir du chroot (un shellcode bien comme il faut fait ça très bien).
chroot jail
chroot est une chose, jail en est une autre (qui n'existe pas sur linux)
Il faut pas tout mélanger.
L'exploit repose sur la modification de chunks dans le tas. En gros, il faut jouer avec des malloc() et free() pour aller modifier des pointeurs dans le tas de sorte à ce que le registre d'instructions finisse par pointer sur le shellcode de son choix.
Ce genre de faille est très difficile à exploiter ... mais c'est possible, comme les montrent les exemples de traceroute, sudo et maintenant celui-ci.
[^] # OTPs
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 2.
Ce n'est pas une exception ! C'est le Graal des cryptographes : un truc dont on a prouvé que c'était incassable, c'est quand même fort non ? Surout que c'est le seul !
Quant à son utilisation, tu te trompes : ça sert courament des les communications militaires, pour le téléphone rouge.
Pour ton Linux, il me semble que le "telnet sécurisé" qui fonctionne justement avec des OTPs (à vérifier)
Pour le reste : ok :)
[^] # parano vs. science-fiction
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 0.
Certes, mais comme tu le dis précédemment, si tu utilises un algo "pourri" (je reprends ta terminologie et je comprends cela comme désignant un algo pour lequel une attaque structurelle facile, simple et réalisable existe) alors tu t'exposes d'autant.
Je pense plutôt que le chiffrement à utiliser dépend de l'importance que tu attaches à tes données, et pas de leur "durée de vie".
Par exemple, si je suis un gros actionnaire de la société X et que je décide de vendre toutes mes actions de cette société, l'ordre de vente immédiate que j'envoie à ma banque a intérêt à être sacrément protégé. Sinon, supposons que tu écoutes mes communications et que tu parviennes à déchiffrer mon ordre : tu vas essayer de vendre tes propres actions avant moi pour faire chuter le cours de l'action et me ruiner.
(HS: enfin quelqu'un qui ne dit pas "cryptage" :)
Merci ;-)
Je connais assez bien la terminologie (je viens de soutenir un doctorat d'info où la crypto occupe une grosse place).
[^] # pas très clair ... consensus ?
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à -2.
Tout simplement parce que ça n'a rien à voir? Evidemment, plus ta clé est longue mieux c'est.
Héhé, tu n'as pas l'impression que tes 2 phrases se contredisent ?
Concernant ton exemple avec ton XOR sur 4096 bits, si mes données à chiffrer font elles-mêmes 4096 bits, tu peux toujours rêver pour parvenir à casser ça : il s'agit du système appelé One Time Pad. Manque de pot, c'est le seul système dont on a prouvé qu'il était absolument sûr (i.e. incassable). Regarde les articles de Shannon de 1948 et 1949 : il explique tout cela, je ne sais plus dans lequel des 2.
Désolé, mais la complexité de l'attaque n'est 2^(n-1) que pendant le premier cours d'initiation à la crypto... après on passe à la cryptanalyse, et là on tombe de haut parfois.
Voilà la phrase importante !
Je répète : la complexité de l'attaque exhaustive d'un algorithme de chiffrement symétrique dont la clé est de longueur n est 2^(n-1) en moyenne.
Tous les mots de cette phrase sont importants et je ne pense pas avoir écrit une connerie.
Ensuite, tu passes à la cryptanalyse, mais là, il s'agit complètement d'autre chose. Une cryptanalyse vise un algorithme précis et n'est pas générale comme peut l'être l'attaque exhaustive. C'est d'ailleurs pour ça que, pour comparer les cryptanalyses, on précise les conditions dans lesquelles l'attaque est possible (cad souvent le nombre de paires (clair, chiffré) nécessaires pour que l'attaque réussisse).
Maintenant, je commence à comprendre ce que tu voulais dire, et je trouve vraiment que tu n'es pas clair.
Les crpytanalyses sont des attaques structurelles : elles passent par une étude approfondie des fonctions qui interviennent dans l'algorithme de (dé)chiffrement.
Pour le moment, on connaît qq cryptanalyses contre DES (différentielle ou linéaire par exemple), mais on n'en connaît pas encore contre AES.La crpytanalyse différentielle date de 1991 (par Biham et Shamir), mais tout le monde continue quand même à utiliser DES.
Pourquoi ?
Simplement parce que les conditions de mise en oeuvre de cette attaque sont difficiles à obtenir (attention, je n'ai pas dit impossible). En effet, il faut 2^47 paires (clair, chiffré) pour cela
Je ne prétends certainement pas que personne ne trouvera une cryptanalyse contre AES (et elle sera peut-être bien plus efficace que les cryptanalyses connues contre DES), mais à un moment donné, tu es obligé d'utiliser ce que tu as sous la main, même si tu sais qu'un jor, ce sera sans doute insuffisant.
Bref, tu peux utiliser AES les yeux fermés aujourd'hui, mais peut-être que demain, qq'un cassera AES pour de bon (enfin, demain, je doute ;)
On ne peut pas faire confiance à nos prévisions de ce que seront les moyens technologiques dans 5 ou 10 ans...
Dans ce cas tu arrêtes immédiatement d'utiliser une voiture parce que peut-être que la téléportation sera au point d'ici 5 ou 10 ans ?
Je ne suis absolument pas d'accord avec ça ! Au ocntraire même : tu es obligé de faire confiance. Seulement, il faut avoir conscience des limites et risques éventuels.
[^] # Re: Des exemples ! des exemples ! des exemples !
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 4.
Pour beaucoup d'algos qui paraîssent très bien à première vue, il existe des méthodes très simples de cassage.
Tu relieras attentivement ce que j'ai écrit, et je n'ai jamais prétendu que DES n'était pas cassé (mais je maintiens que ce ne n'est pas simple, la puce dont tu parles coûte plusieurs milliers de $ et les crpytanalyse du DES ne sont pas aussi évidente que tu le laisse entendre.
Quant à RC5-64, autant pour moi, je ne savais pas qu'il avait été cassé comme tu le laisses entendre (je veux bien voir de la doc là-dessus d'ailleurs).
[^] # Des exemples ! des exemples ! des exemples !
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 0.
Pour beaucoup d'algos qui paraîssent très bien à première vue, il existe des méthodes très simples de cassage.
Je ne me permettrai pas de qualifier la crpytanalyse différentielle ou linéaire (pour DES) de "très simple", idem pour la plupart des méthodes de cribles (pour RSA)
Tu parlais peut-être du code de César ou du chiffrement de Vigenère ? Certes à leur époques, ces méthodes étaient performantes ... et peut-être que DES, AES ou RSA sembleront aussi inefficaces dans qq siècles, mais c'est de la science-fiction pour le moment.
[^] # Re: n'importe quoi !
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 4.
Il existe différents types d'attaques qui dépendent des conditions :
- attaque à chiffré seul
- attaque à clair connu
- attaque à chiffré choisi
- attaque à clair choisi
Pour ces 2 dernières, il existe des formes adaptatives pour les algo asymétriques.
Ensuite, les attaques statistiques dont tu parles dépendent d'un algorithme précis et vise en fait les fonctions qui interviennent dans le chiffrement. Par exemple, la cryptanalyse différentielle (contre DES) est une attaque à clair choisi qui nécessite la connaissance des chiffrés correspondant à des couples de messages clairs dont la différence est fixée.
Alors c'est sûr, plus tu connais de choses, plus c'est facle ... Ainsi, la meilleure cryptanalyse différentielle connue pour casser DES nécessite quand même 2^47 paires (clair, chiffré).
- tu ne sais pas si certains algos à clé secrète n'ont pas de failles.
tu ne peux pas connaître l'évolution des techniques, mais surtout des *algos*
Certes, je me place dans l'état actuel des connaissances et je préfère éviter la science-fiction ... même si j'adore lire ce genre de romans ;-)
[^] # et tu persistes !
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 8.
La qualité de l'algo est beaucoup plus importante que la longueur de la clé.
Non, sans blague ;-)
<mesquin>J'aimerais bcp voir un algo de chiffrement avec une clé de 1 bit ... bjr la qualité ;-]</mesquin>
Pour faire simple, on va considérer les algo de chiffrement symétrique. La seule mesure de la qualité d'un tel algo est la complexité de la meilleure attaque connue, la valeur de référence étant donnée par la complexité de l'attaque exhaustive (i.e. si tu as une clé de n bits "libres", tu testes les 2^n clés => tu fais, en moyenne, 2^(n-1) tentatives avant de trouver la bonne clé)
A part ça, j'aimerais bien savoir comment tu dissocies la qualité de l'algo et la longueur de la clé.
Recherche sur ton moteur de recherche favori "Kerckhoffs". Il a énoncé au 19ème siècle un résultat qui stipule que la sécurité d'un crypto-système devait reposer sur ses clés. Depuis, les algorithmes sont rendus publics et les attaques se focalisent sur l'obtention de ces dernières.
Si on trouve un algo pour casser le chiffre, la longueur de la clé importe tout à coup beaucuop moins...
Bravo ! Qui t'a soufflé ça ? Tu candidates pour la médaille Fields cette année ?
Sérieusement, un algo de cassage dépend forcément de la longueur de la clé. Ainsi, même si RSA 512 a été cassé, avec un RSA 4096 tu es peinard pour quelques siècles ... et tranquille encore, à moins bien sûr que les ordinateurs quantiques voient le jour ou qu'une découverte majeure soit réalisée en théorie des nombres.
[^] # n'importe quoi !
Posté par pappy (site web personnel) . En réponse à la dépêche Nouvel OpenSSH. Évalué à 10.
La longueur des clés de CHIFFREMENT est limitée à 128 bits : pour la plupart des algo de chiffrement à clé secrète, tu peux t'assoir dessus pour quelques milénaires (au moins) avant de réussir à casser quoique ce soit. Pour les algo à clé publique, ceux fondés sur des courbes elliptiques devraient encore tenir qq temps avant que 128 bits ne soient plus siffisants.
A une époque, il y avait aussi une obligation de déclarer tout chiffrement avec sa clé à l'état
Même maintenant, il faut déposer le logiciel, et pas sa clé tant que tu respectes la taille de clé prévue par la loi.
Concernant l'utilisation personnelle d'openssh, tu n'es soumis à rien.
# documents de la CE datés du 20/02/2002
Posté par pappy (site web personnel) . En réponse à la dépêche Brevets logiciels: Découverte d'une collusion entre la BSA et la Commission Européenne. Évalué à 4.
http://www.europa.eu.int/comm/internal_market/fr/indprop/index.htm(...)
Les deux premiers documents sont datés d'aujourd'hui. J'ai bien essayé des les lire ... mais c'est très chiant à la fin de la journée ;-/
Pour un résumé plus ou moins valide de la situation :
http://fr.news.yahoo.com/020220/7/2hpfr.html(...)
# avant de dire n'importe quoi ...
Posté par pappy (site web personnel) . En réponse à la dépêche kitetoa condamné. Évalué à 9.
Kiteto a déjà donné certaines explications qu'il me semble utiles de lire avant de raconter des conneries :
http://www.kitetoa.com/_disc1/showthread.php3?threadid=225(...)
[^] # exemple même de ce que je dis !
Posté par pappy (site web personnel) . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 3.
Tu te reposes sur les autres en espérant que qq'un aura regadé pour toi.
Et donc, si tu utilises mozilla, tu as un pb (voir lien bugtraq que je donne par ailleurs).
[^] # sudo, ssh et crc32 ...
Posté par pappy (site web personnel) . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 10.
Regarde les multiples bogues de sudo par exemple. Ou encore le problème du crc32 avec les serveurs ssh. Le bogue était connu et référencé depuis plusieurs mois avant d'être corrigé.
[^] # et pour preuve ... Mozilla
Posté par pappy (site web personnel) . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 2.
Vu sur bugtraq ce matin : http://www.securityfocus.com/archive/1/251788(...)
[^] # Logiciel Libre != sécurité
Posté par pappy (site web personnel) . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 10.
Sérieusement, cmbien de pesonnes ici ont réellement audité des sources ?
En fait, la plupart des personnes se disent que puisque c'est en open source, il y a bien qq'un pour regarder le code, et que ce n'est pas donc la peine de s'embêter à le faire. Et je ne parle pas du niveau de compétences nécessaire.
[^] # %00 == fin de chaîne
Posté par pappy (site web personnel) . En réponse à la dépêche Le plus gros trou de sécurité de IE. Évalué à 6.
Qu'est-ce qui te laisse penser ça ?
Le %00 correspond au caractère de fin de chaîne et c'est un manière bien connue de faire exécuter du code à un script CGI écrit en perl par exemple.
Je ne pense vraiment pas que ça ait été voulu. Quand le browseur lit l'URL, il s'arrête lorsqu'il rencontre la fon de chaîne (le %00 donc) ... mais l'interpréteur continue, exactement comme avec perl.
[^] # Re: Bien mais...
Posté par pappy (site web personnel) . En réponse à la dépêche Multi-systems & Internet Security Cookbook (MISC). Évalué à 1.
J'aimerais bien le savoir aussi.
Pour ton cas, soit tu en rachètes un, soit tu expédies ton exemplaire à l'adresse indiquée pour l'abonnement en mettant une lettre de protestation et tu devrais en recevoir un tout beau tout neuf.
A mon avis (impartial bien sûr), choisit la première solution ;-]
[^] # Re: en étant objectif ... enfin ;)
Posté par pappy (site web personnel) . En réponse à la dépêche Multi-systems & Internet Security Cookbook (MISC). Évalué à 6.
Oui, dans l'esprit, j'espère bien que MISC est plus proche de phrack que d'un autre magazine contre lequel j'ai une certaine amertume, voire plus ;-/
Chers lecteurs, merci de nous prévenir si nous ne respections plus cette ligne.
Pour ceux qui ne connaissent pas phrack : http://www.phrack.org(...) (en Anglais uniquement).
[^] # est-ce réellement comparable ?
Posté par pappy (site web personnel) . En réponse à la dépêche Multi-systems & Internet Security Cookbook (MISC). Évalué à 5.
En revanche, si un lecteur veut bien répondre en toute objectivé au message précédent, ça m'intéresse :)
[^] # Re: C'est le but
Posté par pappy (site web personnel) . En réponse à la dépêche Multi-systems & Internet Security Cookbook (MISC). Évalué à -6.
(presque) de rien ;)
<smoutch> :)
beurk
beurk
et re-beurk ...
[^] # c'est pas moi qui l'ai dit le premier ;)
Posté par pappy (site web personnel) . En réponse à la dépêche Multi-systems & Internet Security Cookbook (MISC). Évalué à 10.
Mais ça me fait d'autant plus chier que la news sur zataz mag était elle passée en première page ...
M'enfin !
# syslog-ng
Posté par pappy (site web personnel) . En réponse à la dépêche Vous fiez-vous à vos logs système ?. Évalué à 10.
http://www.balabit.hu/en/downloads/syslog-ng/(...)
Aller voir l'excellente doc en Français :
http://www.hsc.fr/ressources/breves/syslog-ng.html(...)
[^] # Re: chroot != jail
Posté par pappy (site web personnel) . En réponse à la dépêche Vulnerabilité dans wu-ftpd et problème de communication entre Redhat et ses concurrents. Évalué à 1.
http://www.hsc.fr/ressources/breves/jail.html(...)
http://www.daemonnews.org/200109/jailint.html(...)
[^] # chroot != jail
Posté par pappy (site web personnel) . En réponse à la dépêche Vulnerabilité dans wu-ftpd et problème de communication entre Redhat et ses concurrents. Évalué à 1.
C'est pas vraiment des failles, c'est juste qu'il y a des moyens de sortir du chroot (un shellcode bien comme il faut fait ça très bien).
chroot jail
chroot est une chose, jail en est une autre (qui n'existe pas sur linux)
Il faut pas tout mélanger.
[^] # Advisory de CORE
Posté par pappy (site web personnel) . En réponse à la dépêche Vulnerabilité dans wu-ftpd et problème de communication entre Redhat et ses concurrents. Évalué à 1.
Tous les détails sont dans :
http://archives.neohapsis.com/archives/vulnwatch/2001-q4/0063.html(...)
L'exploit repose sur la modification de chunks dans le tas. En gros, il faut jouer avec des malloc() et free() pour aller modifier des pointeurs dans le tas de sorte à ce que le registre d'instructions finisse par pointer sur le shellcode de son choix.
Ce genre de faille est très difficile à exploiter ... mais c'est possible, comme les montrent les exemples de traceroute, sudo et maintenant celui-ci.
[^] # pub
Posté par pappy (site web personnel) . En réponse à la dépêche Module d'audit SNARE. Évalué à 10.
J'avais écrit un article là-dessus pour le HS de Linux Mag sur la sécurité. Il est en ligne :
http://minimum.inria.fr/~raynal/index.php3?page=404(...)
</pub>