J'en profite pour signaler à tous une intéressante alternative à GCC (pour le C et sur x86 uniquement malheureusement) vu dans le LOGIN: de ce mois : TinyCC.
Pour rapidement paraphraser sa homepage (et donner qq impressions), l'executable est extrêmement petit (60ko annoncé, mais ça doit être une fois recompilé par lui-même ;), il compile assemble et link d'un seul trait avec des résultats en optimisation stupéfiant et surtout la possibilité d'effectuer du bound checking (avec des messages plus pédant que Segmentation Fault :), il est aussi relativement compatible C99 (plus qq extensions GNU C).
Autre fonctionnalité intéressante : il peut compiler et executer directement et ce à grande vitesse, autorisant l'utilisation de source C comme des scripts avec une belle déclaration #!/usr/local/bin/tcc (testé ! :).
petites précisions...
libsafe ça necessite de patcher la libc.
PaX ne fonctionne que sur x86 puisqu'il rend la pile non executable via la gestion du paging sur IA 32.
Prelude - qui est un IDS - rapporte les debordements de buffers au niveau host via libsafe et prochainement via un plugin PaX à prelude-lml (analyse de logs), et au niveau réseau bien sûr via un pattern matching classique (et peut être bientôt du protocol analysis ? :) avec la gestion des NOP polymorphes (comme l'a fait ensuite spp_fnord.c de dragos ruiu pour snort).
A vrai même si bcp de sociétés développant des IDS vendent du vent, elles ont pas tout à fait tort de casser du sucre sur le dos de Snort. Ne serait-ce que pour son code ignoble (plus les qq failles sympas dans le decodeurs unicode, ou les plugins d'output sql, ainsi que dans plusieurs plugins de decode comme celui sur ICMP qui a du être complétement réécrit...) , ou le proselytisme dont font preuve marty roesch ou dragos ruiu depuis la fondation de Sourcefire.
Cependant ça m'étonne qu'on fasse tout une histoire de fragroute puisqu'il reprend des techniques datant de 98 qui avait justement introduit dans le monde des IDS et firewalls les termes stateful inspection ou tcp stream reassembly et ip defragmentation. Le tout refait (jusque dans le nom) ce que faisait l'outil de test fragrouter en y ajoutant des fonctions de proxy. Bref on dirait plus une réponse "hacker" aux méthodes de normalization de Vern Paxson qu'on retrouve dans pf d'openbsd, plutôt qu'une véritable évolution (je dis ça notamment à cause du "evade passive OS fingerprinting techniques"). En théorie, stream4, frag2 et les plugins applicatifs de snort resolvent ces problèmes depuis longtemps. Et c'est pareil pour tous les IDS. Si des issues n'ont pas été corrigé, elles seront surtout de l'ordre des overlaps ou des timeouts dont les valeurs et comportements sont spécifiques à chaque OS. Or l'IDS tout perfectionné qu'il soit ne peut pas prévoir le comportement des 2 extrêmités d'une transmission. Tout ce qu'on peut faire dans ce cas c'est demander à chaque administrateur de selectionner ses propres valeurs (comme ce sera ou est déjà le cas pour Prelude [1]).
Petit point personnel : en terme de qualité je prefère encore IP360 ou Dragon à Snort, et si je veux de l'open source en plus je vais voir chez Prelude...
y'a Razor aussi, un système anti-spam original utilisant le principe du peer-to-peer.
Son client Razor Reporting Agent fait un checksum (avec SHA-1) des mails considérés comme spam, transmet ce checksum à Razor Catalogue Server qui va le redistribuer à tous les autres clients Razor Filtering Agent qui n'auront plus qu'à comparer des checksums pour filtrer le vilain spam aussi bien au niveau d'un utilisateur que d'un MTA.
Article 5
Exceptions aux actes soumis à restrictions
[...]
3. La personne habilitée à utiliser une copie d'un programme d'ordinateur peut, sans l'autorisation du titulaire du droit, observer, étudier ou tester le fonctionnement de ce programme afin de déterminer les idées et les principes qui sont à la base de n'importe quel élément du programme, lorsqu'elle effectue toute opération de chargement, d'affichage, de passage, de transmission ou de stockage du programme d'ordinateur qu'elle est en droit d'effectuer.
Article 6
Décompilation
1. L'autorisation du titulaire des droits n'est pas requise lorsque la reproduction du code ou la traduction de la forme de ce code au sens de l'article 4 points a) et b) est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un programme d'ordinateur créé de façon indépendante avec d'autres programmes et sous réserve que les conditions suivantes soient réunies :
a) ces actes sont accomplis par le licencié ou par une autre personne jouissant du droit d'utiliser une copie d'un programme ou pour leur compte par une personne habilitée à cette fin ;
b) les informations nécessaires à l'interopérabilité n'ont pas déjà été facilement et rapidement accessibles aux personnes visées au point a) et
c) ces actes sont limités aux parties du programme d'origine nécessaires à cette interopérabilité.
[...]
ouh la la vi, y'en avait eu que 4 en février, ça faisait presque un mois, c'était décevant une semaine sans bug openssh.
Je sais pas si c'est le coté super sécurité qui attire les auditeurs, ou juste que c'est codé n'importe comment...
Ce qui est original c'est d'affirmer que la NSA a 50 d'avance sur la recherche cryptographique et en même temps entretenir le mythe en expliquant qu'on se peut pas gauger blablabla...
Certes la NSA est le premier employeur de mathématiciens au monde, certes son budget est plus important que je-ne-sais-plus-quel ministère. Mais par exemple dans le cas des patches SE Linux, les extensions concernent essentiellement les mises en place de politiques de sécurité dont le code est compréhensible. Le développement est assuré par la NSA mais aussi par MITRE Corp. et NAI Labs. La première a participé à la rédaction d'un draft sur le full disclosure pour l'ietf, tandis que la seconde a participé au developpement de LOMAC et maintenant de TrustedBSD (au travers du projet CBOSS soutenu par le darpa). Ces sociétés ne sont pas tenu je pense au secret defense.
Ensuite, si la NSA avait tant d'avance, je pense que d'en un pays empreint de l'éthique protestante, il aurait tôt fait d'en tirer parti économiquement. Je pense aussi que comme dans tout pays, les différentes bureaucraties s'affrontent en exploitant les petits écarts/secrets de l'autre. Je pense aussi que sur un nombre aussi important d'employés dont plusieurs génies, si qqch dérape ça finira par sortir.
Je ne pense pas que même la NSA ait des siècles d'avance sur le reste du monde. Je me souviens d'avoir lu l'histoire des chercheurs de GCHQ britannique qui avait découvert la cryptographie à clé publique : c'était seulement quelques années avant les publications de Diffie-Hellman-Merkle puis Rivest-Shamir-Adleman. Pour se donner une idée de l'avancement qu'on pu avoir (et doivent tjrs avoir) les agences de renseignement, le royaume uni libère chaque année des documents classés secret defense. Aux USA, il existe le Freedom of Information Act (FOIA) qui permet de consulter de nombreux documents passée une certaine période de temps.
Bref, même si certainement, comme c'est leur boulot, les agences de renseignement espionnent ; je pense qu'il y aura suffisamment de garde fous ou contre pouvoir (comme l'open source). En même temps, je peux être naïf :)
Peter Shor a décrit un algorithme de factorisation tirant parti de la nature des ordinateurs quantiques (superposition d'état) pour s'exécuter en un temps polynomial O(L² L log L log log L) où L est le nombre de bits d'un nombre N. Cet algorithme est basé sur la recherche de période pour N via un transformé de Fourier.
Par ailleurs, il existe d'excellents algorithmes pour les ordinateurs classiques factorisant de grands entiers en des temps "raisonnablement" exponentiels comme le ECM (basé sur les courbes elliptiques, très étudiées en théorie des nombres et en théorie des codes) bien que trop lent pour s'attaquer à RSA, et surtout le Number Field Sieve (NFS) de Pollard (et d'autres) qui a effectué de nombreux travaux depuis 20 ans sur les algorithmes de factorisation. Le NFS s'exécute en un temps O(e1.9(ln n)1/3(ln ln n)2/3).
L'algorithme décrit par Bernstein est une optimisation (impressionante) du NFS comme il en est pratiquée depuis 10 ans. Pour mémoire RSA Security offre de $10000 à $200000 pour la factorisation de modulos RSA de 576 à 2048 bits.
En 1999, c'est déjà une variation du NFS qui avait permit de cracker RSA 155 (de 512 bits) en 97.5 années-cpu.
Pour un budget inférieur à une solution commerciale, Kalima a pu aussi s'offrir douze jours d'intervention sur site. « Je préfère investir mon budget dans un service à forte valeur ajoutée que dans le droit d'utiliser un CD-ROM », conclut Quentin Blarre
A ce propos, il est passé il y a quelques jours sur kuro5hin un excellent article sur le mythe de la sécurité open source http://www.kuro5hin.org/story/2002/2/12/61225/8865(...)
Avec à la fin une présentation de différentes approches d'audit (audit de code, étude formelle d'algorithme, tests, étude du design ...).
Parmi les problèmes engendrés par le mythe de la sécurité open source on trouve :
- le manque de support qui allié à un code complexe peut rendre l'audit difficile
- l'assomption "puisque le code est ouvert, il sera audité donc c'est pas mon problème"
- le fait qu'un contributeur va s'intéresser uniquement à la feature qu'il ajoute (c'est directement lié au point précédent AMA)
Sinon en terme d'audit, le récent projet Sardonix, monté à partir de fond de la DARPA par les gens de WireX (Immunix, stackguard, formatguard) avec en plus des gens comme RFP, tente d'appliquer le modèle d'audit d'OpenBSD à l'ensemble de l'open source. En clair, ils se proposent de faire de l'audit systématique de code.
Je suis tout à fait d'accord que la centralisation dans les mains de VA Software de tant de ressources est inquiétant.
MAIS je faisais surtout remarquer le manque d'anticipation et de stratégie de la FSF.
Au lieu d'avoir à recommencer un **DN, il aurait peut etre mieux valu voir venir et soutenir slashdot et autres avt qu'ils se fassent racheter par VA.
Si la FSF veut éviter les dérives, elle devrait faire en sorte que le développement ne soit pas baser uniquement sur une unique entreprise (participation de développeurs FSF).
C'est vraiment pour le plaisir de réinventer la roue :)
Si déjà la FSF et la FSF Europe arrivait à canaliser (un tant soit peu, je suis pas un centralisateur fou) les développeurs et les dons (sur les gros projets principalement), peut etre qu'elle aurait senti le besoin de plateforme de développement et d'information libres ala OSDN.
Mais surtout, au lieu de persister à réinventer chaque site, pourquoi ne pas les racheter à VA Software, ou bien débaucher les administrateurs de ces sites, ou encore essayer de s'arranger avec VA Software qui tente peut etre simplement de survivre ? Bref pourquoi ne pas tenter l'anticipation et la conciliation ? :)
Ah puis pour inciter les gens à migrer vers Savannah, il faudrait parfaitement prendre en charge CoopX ou le fichier XML de backup de SF et fournir un service au moins équivalent si ce n'est meilleur (site statique ça va pas forcément en enchanter des masses, les foundries seraient utiles, je verrai bien un système d'entraide indépendant des projets avec des questions affichées publiquement, peut etre proposer des alternatives à CVS comme Subversion, disposer de développeurs FSF pour du support généraliste ce qui peut permettre parfois de (re)lancer un projet dont le code ne motive pas de prime abord...).
Personnellement j'apprécie bcp Stallman mais le coté extremistes des organisations free software qui tentent sans cesse de s'imposer en leader sans faire ce qu'il faut pour l'etre c'est agaçant. La FSF (et donc FSDN) manque cruellement de visibilité à mes yeux.
Bien sur tout ça ce sont des vues personnelles et je manque certainement d'informations (teach me ! :)
Je tiens à rappeler que Kitetoa s'est specialisé dans l'intrusion à l'aide de browser netscape (raison pour laquelle il parle uniquement de sites web d'entreprises).
Le but de Kitetoa n'est pas (spécialement :) de divulguer des informations concernant la sécurité de ces serveurs publics ou d'aider les administrateurs, mais surtout de dénoncer ces administrations ou entreprises qui divulguent des fichiers nominatifs informatiques à cause d'un défaut de sécurité qui bien souvent n'est dû qu'à un manque de configuration (et non pas de développement).
Avec la recherche par extensions de google, ou bien l'introduction de liens vers des CGI dans une page crawlées, on peut également réaliser de magnifiques "intrusions". Je pense que c'est l'incompétence et l'igorance de la loi qui devraient être punis, pas le citoyen qui les pointe.
(en passant, comment savoir si les données sont reservées/privées/interdites puisqu'on se trouve sur un serveur public et qu'on tape de simples URL ? On peut invoquer s'être trompé, ou même être arrivé là par un lien du site en quesion, etc. C'est pas scalable comme jugement :)
Posté par vjm .
En réponse à la dépêche LOGIN: n°92.
Évalué à 10.
Les numéros sont préparés quasiment un mois à l'avance, donc à moins de faire de l'espionnage ça m'étonnerait qu'ils se repompent des idées sur des sujets différents avec des auteurs différents en qq jours (entre la sortie de Linuxmag et le bouclage de LOGIN:).
Par ailleurs si tu fais l'effort d'acheter login: ce mois ci, tu découvrirais que ça n'aborde pas iproute2 mais ALTQ développé par KAME pour les *BSD. MAIS surtout, login: a l'amabilité d'aborder un peu de théorie en présentant les différentes disciplines de queueing et pas seulement un bête rechauffé de man/howto (d'autant plus qu'il y a peu d'information sur ALTQ).
Enfin je trouve que login: s'est grandement amélioré dernièrement avec énormément d'article originaux sur la programmation allant du C (c'est avec eux que j'ai compris les signaux et les ipc y'a un moment) au python en passant par le java, le php ou le perl et le rebol.
Ce sont aussi les seuls à distribuer autre chose que des distributions linux et à aborder la sécurité dans un mensuel plutôt généraliste, bref à être ecclectique.
hmm je remarque un petit problème dans l'application d'EAP dans notre cas (le wireless). Tout d'abord ça suppose d'avoir une encapsulation à base de PPP (du L2TP par exemple) et dans ce cas je trouve que ça fait double emploi. SpeKa prévoit d'hors et déjà d'effectuer son authentification via radius encapsulé dans du l2tp.
Plus grave, l'exemple que cisco présente pour un wireless LAN implique l'authentification implicite de tous les hôtes connectés à un point d'accès puisque l'authentification est port-based au niveau du switch et que le point d'accès se trouve à un de ses ports. En clair, on authentifie le point d'accès, pas les utilisateurs. Pour moa ça n'offre pas une réponse appropriée au problème de l'auth.
Donc je persiste, l'authentification/intégrité/confidentialité au layer 2 n'est pas un pré-requis au succès du wireless. De toute manière le layer est bien trop spécifique puisque en rapport avec le hardware, c'est pour cela qu'on a des layers d'abstraction bien plus efficaces pour offrir des méthodes de sécurité efficace comme le montre IPSec, SSL ou SSH (remarquez l'empilement de couches ;)
de mon point de vue c'est ici exactement la même technique à base d'incrémentation d'IP ID qui existe effectivement depuis des lustres grâce au travail d'antirez sur hping. Tu parles d'Idle Host Scan, et l'article aussi...
ensuite pour ce qui est de l'article de phrack présenté. Il est très verbeux et sans fond. Sa méthode suppose qu'on puisse décrire des scénarios complet d'attaque ce qui s'avère assez complexe et de plus il parle d'utiliser des IA alors que les tests à base de réseaux de neurone se montrer exceptionnellement lent et surtout trop strict (pas assez d'approximation dû aux méthodes d'apprentissage). Ca pourrait facilement être implémenté dans des IDS network-based/knowledge-based classique en ayant un meta-langage de description d'attaque permettant de chaîner ces attaques pour donner un scénario (avec des alertes de plus en plus fortes selon l'avancement dans le scénario ou dans le réseau).
Je recommande aussi de lire le travail effectué pour NIDES/EMERALD, un IDS experimental efficace et behavior-based (detection statistique, profiling...).
En terme d'IDS les articles de phrack sont malheureusement peut intéressant. Chercher sur le projet IDS de l'université de colombia (/me se touche sur les papers de lee et stolfo ;).
A noter qu'utiliser des proxies c'est bien gentil mais ça ne change strictement rien à la détection des scans par les IDS. Ce qui va changer c'est qu'on ne remontera pas jusqu'à l'attaquant. C'est certes embêtant en forensic mais aussi trivial qu'inutile en détection (signatures ou scénarios resteront les mêmes, seule l'adresse change).
Sinon moa j'ai une petite question : Reverse Path Forwarding est il disponible ou prévu sous FreeBSD (ou autre *BSD/Linux) ? Le RPF peut s'avérer très utile pour contrer le spoofing mais je ne le vois que sur des routeurs Cisco/Juniper.
faut arrêter de paniquer sur le WEP. C'est comme si vous vous mettiez tous à chialer pke y'a des tools (en private ça existe) qui te permettent de détourner des VPN MPLS via BGP pour la signalling.
Bref, MPLS ou WEP c'est du layer 2. C'est vrai que ce serait sympa d'avoir une encryption correcte à ce niveau mais je me vois mal faire du chiffrement et de l'authentification au layer 2. J'utilise des protocoles à la IPSec ou même du L2TP ./ Et je vais pas hurler si j'ai pas une putain d'encryption de tueur au layer 2 :)
Airsnort le tool en question crack WEP à partir d'une cryptanalise de RC4. Suffit de changer d'algo ou de longueur de clé. Enfin ça varie aussi selon le débit (forcément plus y'a de données plus une cryptanalyse differentielle est rapide).
D'autre part pour répondre aux msg plus haut, y'a qq incohérences ds vos discours. On ne peut pas passer par dessus du domaine public ? Alors en quoa est il public ? :) Plus bas on parle ensuite de domaine privé. Faudrait vous décider. Personnellement j'étais tombé sur des discutions de l'INRIA il y a quelques tps et des drafts de l'ART et ça parlait essentiellement de définir des Groupe Fermé d'Utilisateur qui aurait accès au réseau. Pour ce qui est des fréquences militaires sur le 2.4GHz, ça a été réglé y'a un bon moment et ça concernait essentiellement Bluetooth (802.15) pas vraiment le 802.11b.
Hmm moa j'avais lu ça dans Histoire des Codes Secrets de Simon Singh. La dernière partie est consacrée à la cryptographie quantique. L'idée existe depuis les années 60 et s'est précisé avec des recherches de Bennett et Brassard chez IBM dans les années 80 (un peu avant le célèbre article de deutsch sur l'ordinateur quantique).
A envoie une suite aléatoire de bits (sous forme de photons sachant qu'en informatique quantique le 1 ou le 0 est défini par la polarisation du photon) à travers plusieurs schémas de polarisation. B les reçoit et fait passer successivementà travers tous ses filtres de polarisation. Parallèlement A envoit les schemas de polarisation utilisé (mais pas la polarisation elle-même), B compare et dit à A dans quel cas il est tombé juste. Finalement on conserve uniquement les valeurs justes de la séquence qui va former une one-time-key parfaitement aléatoire puisqu'issue d'une polarisation aléatoire et d'une interprétation de la polarisation aléatoire :)
L'astuce vient du fait que qqun intercepte à travers un filtre pour connaître la polarisation, il va se tromper autant que B et va donc influencer la polarisation en sortie vers B. Donc juste après la définition de la clé, on prend un faible extrait de cette clé qui ne sera pas utilisé pour effectuer une vérification en comparant l'état des schemas de polarisation des 2 côtés. Si trop de bits ont été écarté alors que le schema était le même de chaque côté, ça signifie que qqun intercepte.
Pour info, l'experience a été réussi à 88 au labo Thomas Watson d'IBM. Depuis il y a eu un essai par l'université de Genêve en 95 sur 23kms de fibre optique et à Los Alamos dans l'air sur 1km.
PS : oui oui je sais ça existe aussi par modulation de phase et d'autres sur les 4 états de Bell dérivés du travail sur les paires Einstein-Podolsky-Rosen et connus surtout pour 2 photons reliés entre eux blablabla si on touche à l'un on touche à l'autre mais alors là vaut mieux aller lire soit même.
# TCC
Posté par vjm . En réponse à la dépêche Sortie de GCC 3.1. Évalué à 10.
Pour rapidement paraphraser sa homepage (et donner qq impressions), l'executable est extrêmement petit (60ko annoncé, mais ça doit être une fois recompilé par lui-même ;), il compile assemble et link d'un seul trait avec des résultats en optimisation stupéfiant et surtout la possibilité d'effectuer du bound checking (avec des messages plus pédant que Segmentation Fault :), il est aussi relativement compatible C99 (plus qq extensions GNU C).
Autre fonctionnalité intéressante : il peut compiler et executer directement et ce à grande vitesse, autorisant l'utilisation de source C comme des scripts avec une belle déclaration #!/usr/local/bin/tcc (testé ! :).
http://fabrice.bellard.free.fr/tcc/(...)
Pour info, un mécanisme de bound checking similaire existe sous forme de patch pour GCC
http://web.inter.nl.net/hcc/Haj.Ten.Brugge/(...)
# lala
Posté par vjm . En réponse à la dépêche Configurer un firewall sous FreeBSD avec ipfw. Évalué à -1.
hop -1, pub gratuite
[^] # Re: A lire...
Posté par vjm . En réponse à la dépêche Le patch OpenWall. Évalué à 6.
libsafe ça necessite de patcher la libc.
PaX ne fonctionne que sur x86 puisqu'il rend la pile non executable via la gestion du paging sur IA 32.
Prelude - qui est un IDS - rapporte les debordements de buffers au niveau host via libsafe et prochainement via un plugin PaX à prelude-lml (analyse de logs), et au niveau réseau bien sûr via un pattern matching classique (et peut être bientôt du protocol analysis ? :) avec la gestion des NOP polymorphes (comme l'a fait ensuite spp_fnord.c de dragos ruiu pour snort).
http://www.prelude-ids.org(...)
[^] # Re: Free software vs Logiciel propriétaire
Posté par vjm . En réponse à la dépêche Passez sous le nez de Snort. Évalué à 10.
Cependant ça m'étonne qu'on fasse tout une histoire de fragroute puisqu'il reprend des techniques datant de 98 qui avait justement introduit dans le monde des IDS et firewalls les termes stateful inspection ou tcp stream reassembly et ip defragmentation. Le tout refait (jusque dans le nom) ce que faisait l'outil de test fragrouter en y ajoutant des fonctions de proxy. Bref on dirait plus une réponse "hacker" aux méthodes de normalization de Vern Paxson qu'on retrouve dans pf d'openbsd, plutôt qu'une véritable évolution (je dis ça notamment à cause du "evade passive OS fingerprinting techniques"). En théorie, stream4, frag2 et les plugins applicatifs de snort resolvent ces problèmes depuis longtemps. Et c'est pareil pour tous les IDS. Si des issues n'ont pas été corrigé, elles seront surtout de l'ordre des overlaps ou des timeouts dont les valeurs et comportements sont spécifiques à chaque OS. Or l'IDS tout perfectionné qu'il soit ne peut pas prévoir le comportement des 2 extrêmités d'une transmission. Tout ce qu'on peut faire dans ce cas c'est demander à chaque administrateur de selectionner ses propres valeurs (comme ce sera ou est déjà le cas pour Prelude [1]).
Petit point personnel : en terme de qualité je prefère encore IP360 ou Dragon à Snort, et si je veux de l'open source en plus je vais voir chez Prelude...
[1] http://www.prelude-ids.org(...)
# Razor
Posté par vjm . En réponse à la dépêche ORBZ, c'est fini! place à DSBL. Évalué à 10.
Son client Razor Reporting Agent fait un checksum (avec SHA-1) des mails considérés comme spam, transmet ce checksum à Razor Catalogue Server qui va le redistribuer à tous les autres clients Razor Filtering Agent qui n'auront plus qu'à comparer des checksums pour filtrer le vilain spam aussi bien au niveau d'un utilisateur que d'un MTA.
http://razor.sourceforge.net/(...)
[^] # Re: bien l'europe
Posté par vjm . En réponse à la dépêche Le droit au code source/à la décompilation. Évalué à 10.
http://europa.eu.int/eur-lex/fr/lif/dat/1991/fr_391L0250.html(...)
Article 5
Exceptions aux actes soumis à restrictions
[...]
3. La personne habilitée à utiliser une copie d'un programme d'ordinateur peut, sans l'autorisation du titulaire du droit, observer, étudier ou tester le fonctionnement de ce programme afin de déterminer les idées et les principes qui sont à la base de n'importe quel élément du programme, lorsqu'elle effectue toute opération de chargement, d'affichage, de passage, de transmission ou de stockage du programme d'ordinateur qu'elle est en droit d'effectuer.
Article 6
Décompilation
1. L'autorisation du titulaire des droits n'est pas requise lorsque la reproduction du code ou la traduction de la forme de ce code au sens de l'article 4 points a) et b) est indispensable pour obtenir les informations nécessaires à l'interopérabilité d'un programme d'ordinateur créé de façon indépendante avec d'autres programmes et sous réserve que les conditions suivantes soient réunies :
a) ces actes sont accomplis par le licencié ou par une autre personne jouissant du droit d'utiliser une copie d'un programme ou pour leur compte par une personne habilitée à cette fin ;
b) les informations nécessaires à l'interopérabilité n'ont pas déjà été facilement et rapidement accessibles aux personnes visées au point a) et
c) ces actes sont limités aux parties du programme d'origine nécessaires à cette interopérabilité.
[...]
[^] # Re: Ca va mieux :-)
Posté par vjm . En réponse à la dépêche Trou de securite dans OpenSSH 2.0 -> 3.02. Évalué à 1.
Je sais pas si c'est le coté super sécurité qui attire les auditeurs, ou juste que c'est codé n'importe comment...
http://openssh.com/security.html(...)
Le problème reste que la seule alternative c'est SSH.com commercial...
[^] # Re: NSA nous mène par le bout du nez
Posté par vjm . En réponse à la dépêche Le RSA en danger. Évalué à 5.
Certes la NSA est le premier employeur de mathématiciens au monde, certes son budget est plus important que je-ne-sais-plus-quel ministère. Mais par exemple dans le cas des patches SE Linux, les extensions concernent essentiellement les mises en place de politiques de sécurité dont le code est compréhensible. Le développement est assuré par la NSA mais aussi par MITRE Corp. et NAI Labs. La première a participé à la rédaction d'un draft sur le full disclosure pour l'ietf, tandis que la seconde a participé au developpement de LOMAC et maintenant de TrustedBSD (au travers du projet CBOSS soutenu par le darpa). Ces sociétés ne sont pas tenu je pense au secret defense.
Ensuite, si la NSA avait tant d'avance, je pense que d'en un pays empreint de l'éthique protestante, il aurait tôt fait d'en tirer parti économiquement. Je pense aussi que comme dans tout pays, les différentes bureaucraties s'affrontent en exploitant les petits écarts/secrets de l'autre. Je pense aussi que sur un nombre aussi important d'employés dont plusieurs génies, si qqch dérape ça finira par sortir.
Je ne pense pas que même la NSA ait des siècles d'avance sur le reste du monde. Je me souviens d'avoir lu l'histoire des chercheurs de GCHQ britannique qui avait découvert la cryptographie à clé publique : c'était seulement quelques années avant les publications de Diffie-Hellman-Merkle puis Rivest-Shamir-Adleman. Pour se donner une idée de l'avancement qu'on pu avoir (et doivent tjrs avoir) les agences de renseignement, le royaume uni libère chaque année des documents classés secret defense. Aux USA, il existe le Freedom of Information Act (FOIA) qui permet de consulter de nombreux documents passée une certaine période de temps.
Bref, même si certainement, comme c'est leur boulot, les agences de renseignement espionnent ; je pense qu'il y aura suffisamment de garde fous ou contre pouvoir (comme l'open source). En même temps, je peux être naïf :)
http://www.nsa.gov/selinux/contrib.html(...)
http://opensource.nailabs.com/initiatives/cboss/(...)
http://www.ietf.org/internet-drafts/draft-christey-wysopal-vuln-dis(...)
http://www.aclu.org/library/foia.html(...)
http://www.ddj.com/documents/s=909/ddj9875b/9875b.htm(...)
[^] # Re: Keep cool
Posté par vjm . En réponse à la dépêche Le RSA en danger. Évalué à 10.
http://www.research.att.com/~shor/papers/#quantum(...)
Par ailleurs, il existe d'excellents algorithmes pour les ordinateurs classiques factorisant de grands entiers en des temps "raisonnablement" exponentiels comme le ECM (basé sur les courbes elliptiques, très étudiées en théorie des nombres et en théorie des codes) bien que trop lent pour s'attaquer à RSA, et surtout le Number Field Sieve (NFS) de Pollard (et d'autres) qui a effectué de nombreux travaux depuis 20 ans sur les algorithmes de factorisation. Le NFS s'exécute en un temps O(e1.9(ln n)1/3(ln ln n)2/3).
http://mathworld.wolfram.com/NumberFieldSieve.html(...)
L'algorithme décrit par Bernstein est une optimisation (impressionante) du NFS comme il en est pratiquée depuis 10 ans. Pour mémoire RSA Security offre de $10000 à $200000 pour la factorisation de modulos RSA de 576 à 2048 bits.
En 1999, c'est déjà une variation du NFS qui avait permit de cracker RSA 155 (de 512 bits) en 97.5 années-cpu.
http://www.rsasecurity.com/rsalabs/challenges/factoring/(...)
Bref, belle découverte, mais pas de panique.
http://www.crypto-world.com/FactorPapers.html(...)
# innovation
Posté par vjm . En réponse à la dépêche Le logiciel libre en entreprise. Évalué à 10.
Pour un budget inférieur à une solution commerciale, Kalima a pu aussi s'offrir douze jours d'intervention sur site. « Je préfère investir mon budget dans un service à forte valeur ajoutée que dans le droit d'utiliser un CD-ROM », conclut Quentin Blarre
impeccable :)
[^] # Re: libre = méthodes = sécurité améliorée
Posté par vjm . En réponse à la dépêche L'OpenSource dynamise la sécurité. Évalué à 10.
http://www.kuro5hin.org/story/2002/2/12/61225/8865(...)
Avec à la fin une présentation de différentes approches d'audit (audit de code, étude formelle d'algorithme, tests, étude du design ...).
Parmi les problèmes engendrés par le mythe de la sécurité open source on trouve :
- le manque de support qui allié à un code complexe peut rendre l'audit difficile
- l'assomption "puisque le code est ouvert, il sera audité donc c'est pas mon problème"
- le fait qu'un contributeur va s'intéresser uniquement à la feature qu'il ajoute (c'est directement lié au point précédent AMA)
Sinon en terme d'audit, le récent projet Sardonix, monté à partir de fond de la DARPA par les gens de WireX (Immunix, stackguard, formatguard) avec en plus des gens comme RFP, tente d'appliquer le modèle d'audit d'OpenBSD à l'ensemble de l'open source. En clair, ils se proposent de faire de l'audit systématique de code.
Voir http://www.sardonix.org(...) (site encore en beta, projet jeune) et aussi ces slides de Theo de Raadt sur les méthodes d'audit d'OpenBSD
http://openbsd.org/papers/mexico98-slides.ps(...)
[^] # Re: Wheel
Posté par vjm . En réponse à la dépêche Lancement du FSDN (Free Software Development Network). Évalué à 3.
MAIS je faisais surtout remarquer le manque d'anticipation et de stratégie de la FSF.
Au lieu d'avoir à recommencer un **DN, il aurait peut etre mieux valu voir venir et soutenir slashdot et autres avt qu'ils se fassent racheter par VA.
Si la FSF veut éviter les dérives, elle devrait faire en sorte que le développement ne soit pas baser uniquement sur une unique entreprise (participation de développeurs FSF).
# Wheel
Posté par vjm . En réponse à la dépêche Lancement du FSDN (Free Software Development Network). Évalué à 6.
Si déjà la FSF et la FSF Europe arrivait à canaliser (un tant soit peu, je suis pas un centralisateur fou) les développeurs et les dons (sur les gros projets principalement), peut etre qu'elle aurait senti le besoin de plateforme de développement et d'information libres ala OSDN.
Mais surtout, au lieu de persister à réinventer chaque site, pourquoi ne pas les racheter à VA Software, ou bien débaucher les administrateurs de ces sites, ou encore essayer de s'arranger avec VA Software qui tente peut etre simplement de survivre ? Bref pourquoi ne pas tenter l'anticipation et la conciliation ? :)
Ah puis pour inciter les gens à migrer vers Savannah, il faudrait parfaitement prendre en charge CoopX ou le fichier XML de backup de SF et fournir un service au moins équivalent si ce n'est meilleur (site statique ça va pas forcément en enchanter des masses, les foundries seraient utiles, je verrai bien un système d'entraide indépendant des projets avec des questions affichées publiquement, peut etre proposer des alternatives à CVS comme Subversion, disposer de développeurs FSF pour du support généraliste ce qui peut permettre parfois de (re)lancer un projet dont le code ne motive pas de prime abord...).
Personnellement j'apprécie bcp Stallman mais le coté extremistes des organisations free software qui tentent sans cesse de s'imposer en leader sans faire ce qu'il faut pour l'etre c'est agaçant. La FSF (et donc FSDN) manque cruellement de visibilité à mes yeux.
Bien sur tout ça ce sont des vues personnelles et je manque certainement d'informations (teach me ! :)
[^] # Re: La sécurité avance !
Posté par vjm . En réponse à la dépêche kitetoa condamné. Évalué à 8.
Le but de Kitetoa n'est pas (spécialement :) de divulguer des informations concernant la sécurité de ces serveurs publics ou d'aider les administrateurs, mais surtout de dénoncer ces administrations ou entreprises qui divulguent des fichiers nominatifs informatiques à cause d'un défaut de sécurité qui bien souvent n'est dû qu'à un manque de configuration (et non pas de développement).
Avec la recherche par extensions de google, ou bien l'introduction de liens vers des CGI dans une page crawlées, on peut également réaliser de magnifiques "intrusions". Je pense que c'est l'incompétence et l'igorance de la loi qui devraient être punis, pas le citoyen qui les pointe.
(en passant, comment savoir si les données sont reservées/privées/interdites puisqu'on se trouve sur un serveur public et qu'on tape de simples URL ? On peut invoquer s'être trompé, ou même être arrivé là par un lien du site en quesion, etc. C'est pas scalable comme jugement :)
[^] # Re: copies personelles
Posté par vjm . En réponse à la dépêche you buy it, you own it !. Évalué à 2.
Voir les articles 5 et 6 de la Directive Européenne sur le Logiciel de 1991
http://europa.eu.int/eur-lex/fr/lif/dat/1991/fr_391L0250.html(...)
[^] # Re: Linux Mag sert d'inspiration ?
Posté par vjm . En réponse à la dépêche LOGIN: n°92. Évalué à 10.
Par ailleurs si tu fais l'effort d'acheter login: ce mois ci, tu découvrirais que ça n'aborde pas iproute2 mais ALTQ développé par KAME pour les *BSD. MAIS surtout, login: a l'amabilité d'aborder un peu de théorie en présentant les différentes disciplines de queueing et pas seulement un bête rechauffé de man/howto (d'autant plus qu'il y a peu d'information sur ALTQ).
Enfin je trouve que login: s'est grandement amélioré dernièrement avec énormément d'article originaux sur la programmation allant du C (c'est avec eux que j'ai compris les signaux et les ipc y'a un moment) au python en passant par le java, le php ou le perl et le rebol.
Ce sont aussi les seuls à distribuer autre chose que des distributions linux et à aborder la sécurité dans un mensuel plutôt généraliste, bref à être ecclectique.
[^] # Re: y'avait deja un truc come ca
Posté par vjm . En réponse à la dépêche Secure Internet Live Conferencing. Évalué à 10.
http://www.minithins.net/releases(...)
et blowjob de GCU pour xchat
http://ftp.gcu-squad.org/misc/blowjob.pl(...)
have feun :)
[^] # Re: WiFi
Posté par vjm . En réponse à la dépêche Comparaison de deux produits libres et gratuits. Évalué à 4.
Plus grave, l'exemple que cisco présente pour un wireless LAN implique l'authentification implicite de tous les hôtes connectés à un point d'accès puisque l'authentification est port-based au niveau du switch et que le point d'accès se trouve à un de ses ports. En clair, on authentifie le point d'accès, pas les utilisateurs. Pour moa ça n'offre pas une réponse appropriée au problème de l'auth.
Donc je persiste, l'authentification/intégrité/confidentialité au layer 2 n'est pas un pré-requis au succès du wireless. De toute manière le layer est bien trop spécifique puisque en rapport avec le hardware, c'est pour cela qu'on a des layers d'abstraction bien plus efficaces pour offrir des méthodes de sécurité efficace comme le montre IPSec, SSL ou SSH (remarquez l'empilement de couches ;)
[^] # Re: WiFi
Posté par vjm . En réponse à la dépêche Comparaison de deux produits libres et gratuits. Évalué à 6.
THC WarDrive. Pareil , à coupler avec un GPS en plus du laptop et de la NIC wireless :)
[^] # Re: Idle Spoof Scanning
Posté par vjm . En réponse à la dépêche Scan par témoin. Évalué à 3.
ensuite pour ce qui est de l'article de phrack présenté. Il est très verbeux et sans fond. Sa méthode suppose qu'on puisse décrire des scénarios complet d'attaque ce qui s'avère assez complexe et de plus il parle d'utiliser des IA alors que les tests à base de réseaux de neurone se montrer exceptionnellement lent et surtout trop strict (pas assez d'approximation dû aux méthodes d'apprentissage). Ca pourrait facilement être implémenté dans des IDS network-based/knowledge-based classique en ayant un meta-langage de description d'attaque permettant de chaîner ces attaques pour donner un scénario (avec des alertes de plus en plus fortes selon l'avancement dans le scénario ou dans le réseau).
Je recommande aussi de lire le travail effectué pour NIDES/EMERALD, un IDS experimental efficace et behavior-based (detection statistique, profiling...).
En terme d'IDS les articles de phrack sont malheureusement peut intéressant. Chercher sur le projet IDS de l'université de colombia (/me se touche sur les papers de lee et stolfo ;).
http://www.sdl.sri.com/projects/nides/(...(...))
http://prelude.sourceforge.net/(...(...))
http://www.cs.columbia.edu/ids/(...(...))
A noter qu'utiliser des proxies c'est bien gentil mais ça ne change strictement rien à la détection des scans par les IDS. Ce qui va changer c'est qu'on ne remontera pas jusqu'à l'attaquant. C'est certes embêtant en forensic mais aussi trivial qu'inutile en détection (signatures ou scénarios resteront les mêmes, seule l'adresse change).
Sinon moa j'ai une petite question : Reverse Path Forwarding est il disponible ou prévu sous FreeBSD (ou autre *BSD/Linux) ? Le RPF peut s'avérer très utile pour contrer le spoofing mais je ne le vois que sur des routeurs Cisco/Juniper.
[^] # Re: WiFi
Posté par vjm . En réponse à la dépêche Comparaison de deux produits libres et gratuits. Évalué à 8.
Bref, MPLS ou WEP c'est du layer 2. C'est vrai que ce serait sympa d'avoir une encryption correcte à ce niveau mais je me vois mal faire du chiffrement et de l'authentification au layer 2. J'utilise des protocoles à la IPSec ou même du L2TP ./ Et je vais pas hurler si j'ai pas une putain d'encryption de tueur au layer 2 :)
Airsnort le tool en question crack WEP à partir d'une cryptanalise de RC4. Suffit de changer d'algo ou de longueur de clé. Enfin ça varie aussi selon le débit (forcément plus y'a de données plus une cryptanalyse differentielle est rapide).
D'autre part pour répondre aux msg plus haut, y'a qq incohérences ds vos discours. On ne peut pas passer par dessus du domaine public ? Alors en quoa est il public ? :) Plus bas on parle ensuite de domaine privé. Faudrait vous décider. Personnellement j'étais tombé sur des discutions de l'INRIA il y a quelques tps et des drafts de l'ART et ça parlait essentiellement de définir des Groupe Fermé d'Utilisateur qui aurait accès au réseau. Pour ce qui est des fréquences militaires sur le 2.4GHz, ça a été réglé y'a un bon moment et ça concernait essentiellement Bluetooth (802.15) pas vraiment le 802.11b.
http://airsnort.sourceforge.net/(...(...))
[^] # Re: moouuiii
Posté par vjm . En réponse à la dépêche Premier craquage quantique. Évalué à 10.
A envoie une suite aléatoire de bits (sous forme de photons sachant qu'en informatique quantique le 1 ou le 0 est défini par la polarisation du photon) à travers plusieurs schémas de polarisation. B les reçoit et fait passer successivementà travers tous ses filtres de polarisation. Parallèlement A envoit les schemas de polarisation utilisé (mais pas la polarisation elle-même), B compare et dit à A dans quel cas il est tombé juste. Finalement on conserve uniquement les valeurs justes de la séquence qui va former une one-time-key parfaitement aléatoire puisqu'issue d'une polarisation aléatoire et d'une interprétation de la polarisation aléatoire :)
L'astuce vient du fait que qqun intercepte à travers un filtre pour connaître la polarisation, il va se tromper autant que B et va donc influencer la polarisation en sortie vers B. Donc juste après la définition de la clé, on prend un faible extrait de cette clé qui ne sera pas utilisé pour effectuer une vérification en comparant l'état des schemas de polarisation des 2 côtés. Si trop de bits ont été écarté alors que le schema était le même de chaque côté, ça signifie que qqun intercepte.
Pour info, l'experience a été réussi à 88 au labo Thomas Watson d'IBM. Depuis il y a eu un essai par l'université de Genêve en 95 sur 23kms de fibre optique et à Los Alamos dans l'air sur 1km.
have fun
http://sw00d.free.fr/crypto/pages/quantique.htm(...)
http://www.cs.mcgill.ca/~crepeau/CRYPTO/Biblio-QC.html(...)
PS : oui oui je sais ça existe aussi par modulation de phase et d'autres sur les 4 états de Bell dérivés du travail sur les paires Einstein-Podolsky-Rosen et connus surtout pour 2 photons reliés entre eux blablabla si on touche à l'un on touche à l'autre mais alors là vaut mieux aller lire soit même.
http://www.public.iastate.edu/~physics/sci.physics/faq/bells_inequa(...)