pappy a écrit 279 commentaires

<mauvais esprit>
Alors ?

Ben t'abonne pas !
Tu voies bien que tu as un choix : abonnement ou pas ... ;-)))
</mauvais esprit>

Il y a une espèce de paradoxe que je pense voulu dans le dernier MISC

Disons que ce n'est pas totalement un hasard, mais je n'irai pas non plus jusqu'à dire que c'est complètement voulu.
De même pour l'article sur Diffie-Hellman, même s'il ne montre pas d'attaques.

Disons que ça contribue à la cohérence globale du magazine ...

/me devrait faire attention, bienôt je vais me mettre au marketting ou à la comm ;-)

En tout cas merci pour les compliments, ainsi que pour ceux qui portent des HS sur le(s) noyau(x).

juste pour rappel : la randomisation ne sert presque à rien pour les bugs qui permettent de dévoiler l'espace d'adressage des processus (typiquement les format bugs) ... vu que dans ce cas le processus devient un joli debogueur et qu'on peut lire tout ce qu'on veut où o veut avant d'aller écrire au(x) bon(s) endroit(s).

Mais comme le dit Vahnu (faut que je revienne à Lille moi ;-) : dans certains cas, les bretelles et la ceinture, c'est pas mal ;-]

Sans vouloir présager du niveau de chacun, il semble très accessible, même pour le néophyte ou l'amateur éclairé

J'en profite pour ajouter une couche : les auteurs ont fait un travail remarquable !!!
Oui, le noyau est un sujet complexe et vaste, mais les auteurs ont réussi un tour de force imprésionnant avec ce numéro (et le suivant qui sera dans la même veine) en le rendant accessible : bel exercice de pédagogie.

Bravo messieurs (de la part du rédac chef qui a oublié de mettre cela dans son édito) !

oui, c'est le livre bleu.

Si ovus voulez nous aider, on vend ce qui nous reste d'actes au prix de 25 Euros ;-) Envoyer un mail à achat@sstic.org

Aucune info là-dessus ;-) Je peux néanmoins dire que certaines conf (sans préciser lesquelles ... parce qu'à mon âge on perd la tête - entre autre ;-) ne seront jamais en ligne parce que les auteurs ne le souhaitent pas et que nous respectons leur choix.

Par ailleurs, il y aura les vidéos de certaines conf en ligne aussi (mais même remarque que ci-dessus).

normalement, nous mettrons les vidéos des conférences sur le site dans pas trop longtemps (cad avant la prochaine édition ;) Cela demande juste du travail ... et donc du temps.

Pour les conférences, effectivement, certaines ne pourront pas être diffusée parce que le conférencier ne le souhaite pas, ce qui me semble un droit que nous ne pouvons pas refuser à qq1.

Prend contact avec Thiebaut (ou moi pour que je te mette en contact avec thiebaut) pour les histoires de sons. Je n'ai pas la moindre idée de la qualité des vidéos, mais autant synchroniser le boulot fait pour éviter de s'embêter ;)

Encore merci de ton coup de main.

nan, nan, rassure toi, j'en ai une autre en tête qui remporte la palme haut la main, mais je ne balancerai pas ;)

De quelles "notions autres" tu parles ? A part le droit et l'article sur les coîts, je ne vois pas à quoi tu fais allusion.

Maintenant si la ligne editoriale change c'est votre choix, et j'ai bien sentis ce numero comme différent.

Nan, la ligne de change pas, comme tu pourra le constater dans le prochain numéro.

Mis à part que je suis entièrement d'accord avec boubou (et il ne me paye pas pour dire cela, c'est même moi qui lui doit une bière) je rajouterai même que la sécurité pour la sécurité n'est pas une fin en soi.

De plus, concernant le droit, il ne faut quand même pas oublier qu'avec la sécurité informatique, on manipule des choses sensibles (que ce soit les données ou les outils eux-mêmes). Savoir ce que tu as le droit de faire, dans quelles conditions et sous quelles réserves ne me semble pas complètement in-intéressant. Disons que c'est un sujet d'ouverture. Par exemple, prend l'article sur la loi godfrain paru dans MISC 3 :

http://www.miscmag.com/articles/index.php3?page=304(...)

Combien de fois ai-je entendu "troller" sur ce qu'était une intrusion, un maintien, etc... Et jusqu'à ce que l'auteur de cet article ne m'explique les choses du point de vue du juriste, c'était flou. Idem avec son article suivant sur le scan de port.

Mais je le reconnais, ce n'est pas de la technique, c'est périphérique, bref je le redis, c'est un sujet d'ouverture. Il continuera à y en avoir, mais rassure toi, MISC reste un journal dont le but est de présenter l'aspect technique et scientifique de la sécurité informatique ... même si la sécu ne se limite pas à des mesures techniques.

Sinon, pour le dossier, à part le premier article qui présente ce qu'on entend par "guerre de l'information" (et ce "truc" n'est pas un mythe), les articles suivants sont techniques non ? Regarde celui sur le reverse, tu ne vas pas être déçu.

c'est peut-être parce que Véro vote ?

<private joke>
bah, on peut lâcher me morceau. En fait, la bellaminette, c'est véro ;)))
</private joke>

ah bon, c'est pas toi qui a dessiné ? ;)

si tu parles du pour la science spécial crypto, je suis un des auteurs de l'article en question. Il se trouve que nous avions précisé que l'origine de ce texte était douteuse, mais ça a disparu à la PAO :(

Cette lettre est très vraissemblablement un faux :

http://www.stellaweb.ch/nadar/wb/lettre_mus.htm(...)

Contrairement à ce qui est dit dans l'article de isecurelabs, cette idée n'est pas nouvelle :

En Mars 1996, Mr Rowland publia cela :
http://www.firstmonday.dk/issues/issue2_5/rowland/(...)

Il y a qq problèmes (connus) avec cette solution.

Toujours en 1996, un article présente bcp de méthodes pour cacher des bits d'inforamtion dans les différentes couches du modèle OSI :
T. G. Handel and M. T. Sandford
Hiding Data in the {OSI} Network Model


Enfin, dans un registre légèrement différent, il y a le tunnel ICMP avec le (vieux) projet LOKI :
http://www.phrack.org/show.php?p=49&a=6(...)
http://www.phrack.org/show.php?p=51&a=6(...)

A bon entendeur salut.

salut ;-)

oui, tout à fait, en général, c'est comme ça que ça se traduit

il va falloir te faire à l'idée que de jeunes filles blondes délicieuses ...

Je me suis déjà fait à l'idée ... mais ma copine, qui est brune, bcp moins ;-)

La faiblesse du WEP vient de l'utilisation de RC4 ET du fait que la clef ne change pas. RC4 en soit ne pose pas (trop) de problème. Le fait que la clé ne change pas ne pose pas (trop) de problème non plus. Le problème, c'est que certains morceaux de la clé (l'IV pour être précis en utilisant la terminologie WEP) voyagent en clair sur le réseau. Ca en soit, ce n'est encore pas trop grave (quoique ;-) Mais là où ça devient une cata, c'est que certains IV révèlent de l'information sur les octets de la clé secrète, ce qui permet ensuite de reconstruire intégralement la clé secrète. Pour les précisions, lire S. Fluhrer, I. Mantin et A. Shamir - Weaknesses in the key scheduling algorithm of RC4 Bon, je ne voulais pas le faire, mais tu m'y pousse ;) ou encore le dernier MISC (http://www.miscmag.com) qui traite justement du wireless (et du WEP entre autre) Merci pour la ref du papier sur le 802.1x, c'est pas mal :) Dernier truc, en étant connecté au niveau 2 sur ton AP, l'attaquant ne peut pas communiquer sur le réseau, certes, mais il peut injecter du trafic, faire des dénis de services, modifier des trames, etc... ce qui est déjà pas mal non ?

On remarquera dans le thème sécurité la présence d'une star, Frédérique Raynal, de MISC... La star étouffe de rire en lisant cela :))) Est-ce qu'il serait possible de remplacer/virer/changer cette expression svp ? Parce qu'après, j'en connais encore qui vont dire que j'ai le melon ... ;-/ Frédérique Sinon, je rappelle que mon prénom s'écrit "Frédéric"

Petit correctif ... Je ne ferai pas un truc sur php et autres, mais sur qq "biliothèques libres" pour construire des outils de sécurité, et en particulier libnet qui est une superbe bibliothèque pour construire des paquets à balancer ensuite sur le réseau.

En gros, on utilise une clef symetrique qui ne change pas pendant toute la duree de l'association entre les deux extremites d'une connexion WIFI. C'est MAL (tm), Non, je ne suis pas d'accord ! ssh utilise aussi une clé symétrique, appelée clé de session, pour chiffrer toute ta communication, et ça ne pose pas de problème (enfin, en toute rigueur, il me semble que cette clé est regénérée toutes les heures par défaut ... mais c'est vraiment du luxe). Le problème, c'est uniquement la manière dont le RC4 qui est à l'intérieur du WEP est utilisé, rien d'autre. 802.1x ... bla bla bla ... < l'authetification est asymetrique : pas d'authentification de la borne d'acces. On est donc vulnerable a des attaques de types Man in the Middle. Dans ce cas, je te conseille d'arrêter d'utiliser ssl, ssh et ipsec tout de suite parce que ces protocoles sont aussi vulnérables à du man in the middle. C'est un problème structurelle des algo asymétriques et la seule solution connue et fiable actuellement repose sur l'utilisation de certificats pour vérifier les clés, et donc un tiers. En revanche, le problème que tu ne mentionnes pas avec le 802.1x, c'est qu'une fois qu'une machine est authentifiée sur le réseau (ou l'AP en général), il "suffit" de choper son adresse MAC pour se faire passer pour elle et bénnéficier de ses privilèges ... et ça, excuse moi du peu, ça me semble autrement plus risqué que du man in the middle. IPSec IPsec n'empêchera pas du tout un pirate de se connecter sur ton réseau ... ça fonctionne au niveau 3 et plus, donc comme on est au niveau 2 pour les AP ... c'est raté

Tout ce qui est dans cet article est vrai.
Pour le canal caché, j'ai même fait qq tests de capacité (ie le nombre de bits transmis par session) avec sshv2. En gros, on peut dire que la capacité de ce canal n'est pas énorme ... mais emplement suiffisante pour récupérer la clé de session et donc tout décoder à posteriori.
Pour le reste, cet article de B. Perrot (le "porteur" de ssh en ssf) a été écrit pour le Linux Mag hors série 8, et donc il date un peu ... mais là où il est fort, c'est qu'il reste totalement d'actualité.
Le seul manque de cet article, concerne la séparation de privilège qui n'est pas mentionnée, et pour cause puisqu'elle n'était pas encore implémantée.