[nettime-fr] Cryptogram, 15 mars 2000

[jmm <jmm@free.fr>]

'lo,

Bruce Schneier et sa newsletter Cryptogram font autorité dans le
milieu de la sécurité informatique et sont régulièrement cité dans
Nettime, entre auters. Je me permets de RE:transmettre la traduction
qu'en fait Gilbert Fernandes, pour ceux qui ne connaîtraient pas
cette excellente source d'informations ou qui désespéraient de pouvoir
la lire en anglais.

tschuss
jmm.


Objet: Cryptogram, 15 mars 2000
Date: Mer, 15 mars 2000 15:26:23 -0600
De(1): Bruce Schneier <schneier@counterpane.com>
Traduction: Dim, 19 mars 2000 11:05:06 -0100
De(2): Gilbert Fernandes <gilb@wanadoo.fr>

Cryptogram

15 mars 2000

par Bruce Schneier
Fondateur et CTO de
Counterpane Internet Security Inc.

http://www.counterpane.com

Une lettre d'information gratuite et mensuelle vous proposant des résumés,
analyses, éclaircissements et commentaires sur la sécurité informatique et
la cryptographie.

Les anciens exemplaires sont disponibles à http://www.counterpane.com

Pour vous inscrire ou quitter la liste, consultez la fin du document.

Droits déposés (c) 2000 Counterpane Internet Security, Inc.

** *** ***** ******* *********** ************* ***************

Dans cet exemplaire:
      Kerberos et Windows 2000
      Counterpane -- Recherche commentée
      Nouvelles
      Nouvelles de l'AES
      Nouvelles de Counterpane
      Le logiciel comme outil de cambrioleur
      Le loup dans l'auberge: La législation de Virginie
      Complexité logicielle et sécurité
      Commentaires de lecteurs

** *** ***** ******* *********** ************* ***************

          Kerberos et Windows 2000


Kerberos est un procédé d'authentification à clef symétrique. Il a été
développé au MIT comme un élément de leur projet Athena dans les années
80.Le protocole fut publié en octobre 1988 et il a été implémenté par
plusieurs distributions UNIX. La version actuelle de Kerberos est la
version 5, qui corrige quelques vulnérabilités de sécurité de la version 4.
Elle n'a jamais dominé dans le monde de l'authentification, mais elle est
utilisée dans de nombreux réseaux. Ces derniers jours, l'IETF (Internet
Engineering Task Force) contrôle la spécification de Kerberos.

Kerberos est un protocole d'authentification client-serveur (le livre
"Cryptographie appliquée" entre en détail dans le protocole). Pour pouvoir
comprendre cet article, n'oubliez pas que Kerberos repose sur un serveur
sécurisé Kerberos sur le réseau. Les clients se connectent au serveur et
obtiennent des "tickets" protégés. Les clients peuvent ensuite utiliser ces
tickets pour se connecter à d'autres serveurs du réseau: serveurs de
fichiers, bases de données, etc.

Kerberos fait désormais partie de Microsoft Windows 2000, en quelque sorte.
Le problème c'est que Microsoft a fait quelques changements au protocole
pour le rendre inutilisable avec le standard Kerberos, et avec tous les
produits qui implémentent Kerberos correctement.

De manière plus précise, l'incompatibilité est due à quelque chose qui
porte le nom de "data authorization field" (champ de données
d'authentification) au sein des messages Kerberos. Toutes les
implémentations majeures de Kerberos laissent ce champ vide. La nouvelle
implémentation de Microsoft ne le fait pas; elle utilise cette zone pour
échanger les privilèges d'accès entre le serveur Kerberos et le client.

Il y a deux manières de considérer cela:

o  Puisque le champ n'a pas d'utilisation spécifique au sein du protocole,
   et que personne d'autre ne l'utilise, le fait que Microsoft utilise le
   protocole n'est pas néfaste.

o  Parce que Microsoft refuse de publier les détails de son usage
   propriétaire du champ, ils nuisent à l'interopérabilité et la
   standardisation. Les autres vendeurs d'implémentations Kerberos ne
   peuvent supporter directement les clients 2000.

Et même pire: Microsoft a court-circuité l'IETF dans ce processus (il y a
une procédure que vous devez suivre si vous souhaitez améliorer, dévier ou
modifier un standard IETF).

En surface, il ne s'agit que d'une nouvelle pratique commerciale
consternante. Si vous êtes une compagnie qui a investi dans le système
d'authentification Kerberos basé sur UNIX et que vous souhaitez supporter
les machines sous Windows 2000, votre seule option est d'acheter un serveur
Kerberos Windows 2000 et de payer pour l'intégration. Je suis persuadé que
c'est le véritable objectif de Microsoft.

Mais je suis plus inquiet au sujet de la sécurité. Les protocoles sont très
fragiles; nous l'avons appris à de nombreuses reprises. Vous ne pouvez pas
apporter des changements à un protocole de sécurité et imaginer que le
protocole restera sûr. Microsoft a pris le protocole Kerberos, un protocole
publié qui a été étudié pendant plus d'une décade et ils ont modifié
l'algorithme et affectent sa sécurité. Pire, ils ont fait ces changements
dans le secret et n'ont publié aucun détail de manière publique.

Ne vous laissez pas prendre au piège. Le Kerberos de Windows 2000 n'est pas
Kerberos. Il ne correspond pas au standard Kerberos. Il lui ressemble, mais
nous n'avons aucune idée de sa sécurité.

Page de Kerberos:
<http://www.isi.edu/gost/gost-group/products/kerberos/>

Spécification IETF:
<ftp://ftp.isi.edu/in-notes/rfc1510.txt>
<ftp://athena-dist.mit.edu/pub/kerberos/doc/techplan.txt>

Information sur le Kerberos de Microsoft:
Windows 2000 Kerberos Authentication white paper:
<http://www.microsoft.com/windows2000/library/howitworks/security/kerberos.a
sp>

Introduction to Windows 2000 Security Services:
<http://www.microsoft.com/WINDOWS2000/guide/server/features/secintro.asp>

Guide to Kerberos Interoperability:
<http://www.microsoft.com/windows2000/library/planning/security/kerbsteps.asp>

Article de David Chappell sur Kerberos et Windows 2000:
<http://www.microsoft.com/msj/defaulttop.asp?page=/msj/0899/kerberos/kerbero
stop.htm>

** *** ***** ******* *********** *************

       Counterpane -- Recherche commentée

"A Performance Comparison of the Five AES Finalists"

B. Schneier et D. Whiting, Third AES Candidate Conference, 2000, à paraître.

En 1997, le NIST a annoncé un programme afin de développer et choisir un
standard avancé de chiffrement (Advanced Encryption Standard ou AES) afin
de remplacer le vieillissant DES (Data Encryption Standard). Le NIST a
désigné cinq finalistes en 1999. Nous comparons les performances des cinq
finalistes à l'AES sur une variété de plateformes répandues: les
processeurs 32 bits actuels (aussi bien les gros processeurs que les plus
petits, les embarqués et ceux des cartes intelligentes) et les processeurs
64 bits. Notre intention est de montrer les différentes vitesses
d'exécution au travers d'une variété de processeurs. Puis, nous indiquons
sur combien de rondes au maximum ont été cryptanalysés chacun des
algorithmes et nous examinons de nouveau les performances de ces variantes.
Nous comparons ensuite à nouveau les algorithmes, en utilisant les
variantes à sécurité minimale comme moyen d'aligner équitablement la
sécurité des cinq algorithmes.

<http://www.counterpane.com/aes-comparison.html>

** *** ***** ******* *********** *************

                     Nouvelles

Commentaires supplémentaires sur l'éthique à publier les vulnérabilités:
<http://boardwatch.internet.com/mag/99/oct/bwm62.html>
<http://cgi.zdnet.com/slink?22157:8469234>

Une opinion sur les attaques DDS (Denial of Service) et le fiasco de CD
Universe:
<http://www.osopinion.com/Opinions/GaryMurphy/GaryMurphy7.html>

Voici un nouveau standard DDS:
Texte:
<http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&doc
id=00-3450-filed>
PDF:
<http://frwebgate.access.gpo.gov/cgi-bin/getdoc.cgi?dbname=2000_register&doc
id=00-3450-filed.pdf>

BAIT, DIRT et d'autres outils. Une partie sonne trop bien pour être vraie.
<http://www.codexdatasystems.com/>

L'insécurité de H&R Block:
<http://news.cnet.com/news/0-1005-200-1550948.html?tag=st.ne.1002.tgif?st.ne
fd.gif.d>

Le pire produit de sécurité est celui qui n'est pas utilisé. Voici les
résultats d'une étude sur PGP et son usage. La plupart des gens n'arrivent
pas à l'utiliser correctement. Quelques personnes ont même envoyé des
emails sans chiffrement, et croyaient avoir envoyé leur message sous forme
chiffrée.
<http://www.wired.com/news/news/business/story/21484.html>
<http://www.cs.cmu.edu/~alma/johnny.pdf>

Novell a publié un document sur la "faille de sécurité de l'Active
Directory Services Microsoft" un jour avant que Microsoft ne lance Windows
2000. Microsoft a publié une réponse peu de temps après. Les deux documents
sont remplis de propos à but commercial. Russ Cooper a écrit une
description objective de ce non-fait:
<http://ntbugtraq.ntadvice.com/NDSvsADS-01.asp>

Bon logiciel de sécurité: un outil pour ligne de commande qui permet de
scruter statistiquement le code source C et et C++ à la recherche de
vulnérabilités de sécurité. Il s'appelle ITS4.
<http://www.rstcorp.com/its4/>

Le document de Mixter sur le cracking:
<http://mixter.void.ru/crack.txt>

Un excellent essai sur les différences entre les hackers et les vandales:
<http://www.villagevoice.com/issues/0007/thieme.shtml>

Commentaires sur les attaques Denial of Service distribuées:
<http://www.pbs.org/cringely/pulpit/pulpit20000217.html>
<http://www.thenation.com/issue/000313/0313klein.shtml>

Noms d'utilisateurs et mots de passe à vendre:
<http://www.wired.com/news/politics/0,1283,34515,00.html?tw=wn20000224>

La Sony PlayStation 2 est bloquée au Japon en exportation à cause de
cryptographie au sein de son système:
<http://www.theregister.co.uk/000302-000026.html>

La poupée GI Joe parlant le code Navajo:
<http://www.gijoe.com/lnavajo_code_talker.html>

De la spéculation sur ECHELON:
<http://www.zdnet.com/enterprise/stories/security/news/0,7922,2455560,00.html>
<http://www.wired.com/news/politics/0,1283,34932,00.html>

Une utilisation intéressante du pot de miel par le San Diego Supercomputer
Center (ou, SDSC qui pirate les pirates):
<http://security.sdsc.edu/incidents/worm.2000.01.18.shtml>

** *** ***** ******* *********** *************

              Nouvelles de l'AES

La grande semaine de nouvelles concernant l'AES du 10 au 14 avril 2000 à
New York. Lundi, mardi et mercredi se tiendra le 7ème Fast Encryption
Workshop (FSE 2000). Jeudi et vendredi se tiendra la troisième conférence
des candidats à l'AES (AES3). Les deux auront lieu au New York Hilton et
Towers. FSE 2000 aura plusieurs excellents documents sur les candidats AES
(nouvelles attaques contre MARS, RC6, Rijndael et Serpent) que l'AES3
n'aura pas. Les documents pour FSE 2000 ont été sélectionnés et la liste se
trouve sur le site Internet. Les documents pour l'AES3 n'ont pas été
annoncés pour l'instant (la limite de dépôt est dépassée depuis longtemps).

Venez faire partie de l'histoire de la cryptographie. Ce sera amusant.

FSE 2000:
<http://www.counterpane.com/fse.html>

AES3:
<http://csrc.nist.gov/encryption/aes/round2/conf3/aes3conf.htm>

** *** ***** ******* *********** *************

           Nouvelles de Counterpane

Bruce Schneier a fait l'objet d'une interview dans Business Week:
<http://www.businessweek.com/2000/00_10/b3671089.htm>

** *** ***** ******* *********** *************

     Le logiciel comme outil de cambrioleur

Assez fou. Deux personnes de Minneapolis qui ont volé intentionnellement de
l'information à leurs employeurs ont été accusées de possession d'un "outil
de cambriolage", L0phtcrack, le programme qui casse automatiquement les
mots de passe.

Les ramifications ne sont pas très claires. Il y a des outils qui peuvent
être utilisés pour cambrioler que vous ne pouvez posséder sans être un
professionnel sous licence (certains outils pour crocheter par exemple).
Les posséder est illégal. Mais les tournevis et les cutters peuvent aussi
être des outils de cambriolage s'ils sont utilisés à cette fin.

Il me semble que la loi commence à devenir sérieuse au sujet de tout cela.


<http://www.channel4000.com/news/stories/news-20000217-164727.html?&_ref=100
5006010>

** *** ***** ******* *********** *************

    Le loup dans l'auberge: La législation de Virginie

L'Etat de Virginie a récemment voté une loi, UCITA: Uniform Computer
Information Transactions Act. Elle est profondément dérangeante. Elle
pourrait avoir pour sous-titre: "La liste de vœux de l'industrie du
logiciel" quand on découvre la quantité de contrôle (et l'absence de
vérification) que la loi donne aux distributeurs de logiciels.

Sous UCITA, Microsoft non seulement n'a pas à corriger l'un des 63 000
bogues de Windows 2000, car elle n'est pas même obligée de vous en parler.
Elle pourrait aussi désactiver l'OS chez n'importe qui, pour n'importe
quelle raison (e. g. si vous refusez de vous soumettre aux termes qui vous
obligent à ne pas mentionner le moindre bogue dans un logiciel).

Le gouverneur n'a pas encore signé la loi, mais on s'y attend.

<http://www.lawnewsnetwork.com/practice/techlaw/news/A16380-2000Feb16.html>
<http://www4.zdnet.com:80/intweek/stories/news/0,4164,2436874,00.html>
<http://www.computerworld.com/home/print.nsf/CWFlash/000215ECDA>
<http://www.cnn.com/2000/TECH/computing/03/07/ucita.idg/index.html>

** *** ***** ******* *********** *************

        Complexité logicielle et sécurité

Le futur des systèmes numériques est la complexité, et la complexité est le
pire ennemi de la sécurité.

La technologie numérique a été une suite sans fin d'innovations, de
conséquences inattendues et de surprises, et il n'y a aucune raison de
croire que cela va cesser. Mais il y a parmi tout cela une constante, c'est
que les systèmes numériques sont de plus en plus complexes.

Nous l'avons bien vu ces dernières années. Les microprocesseurs sont
devenus plus complexes. Les systèmes d'exploitation sont devenus plus
complexes. Les ordinateurs sont devenus plus complexes. Les réseaux sont
devenus plus complexes. Les réseaux individuels se sont combinés, et
augmentent la complexité globale. Je l'ai dit avant, mais cela vaut la
peine: Internet est probablement la machine la plus complexe jamais
réalisée par l'humanité. Et elle ne risque pas de se simplifier avant
longtemps.

Comme consommateur, je pense que la complexité est appréciable. Il y a plus
de choix, plus d'options et plus de choses que je peux faire. Comme un
professionnel dans le domaine de la sécurité, je pense que c'est
terrifiant. La complexité est le pire ennemi de la sécurité. C'est vrai
depuis le début des ordinateurs, et cela va probablement rester vrai à
l'avenir. À mesure que le cyberespace devient plus complexe, sa sécurité
s'amoindrit. Il y a plusieurs raisons qui rendent cela vrai.

La première raison c'est le nombre de bogues dans la sécurité. Tout
logiciel contient des bogues. Et à mesure que la complexité du logiciel
augmente, le nombre de bogues aussi. Et un pourcentage de ces bogues
affecte la sécurité.

La seconde raison c'est l'aspect modulaire des systèmes complexes. Les
systèmes complexes sont par nécessite modulaires; il n'y a pas d'autre
moyen que de réduire la complexité en construisant par modules, qui
deviennent alors gérables. Nous n'aurions jamais pu créer Internet aussi
complexe et aussi intéressant sans aspect modulaire. Mais à mesure que nous
avançons dans cette forme, les failles de sécurité sont plus nombreuses,
parce que la sécurité échoue souvent là où deux modules interagissent.

Nous avons déjà vu des exemples de cela, où tout devient sensible à
Internet. Pendant des années, nous avons su que des applications Internet
comme sendmail ou rlogin devaient absolument être protégées, mais la
récente épidémie des macro virus de Microsoft Word et Excel nous montre que
des logiciels non-Internet doivent aussi être protégés. Les applet Java ne
doivent pas seulement être résistants aux usages auxquels ils se destinent,
mais ils doivent aussi être protégés contre toute autre attaque qu'un
attaquant aura pu imaginer. Les photocopieurs, les ports de maintenance sur
les routeurs, les unités de stockage de masse: tous ces éléments peuvent
être rendus sensibles à Internet, avec les risques de sécurité que cela
implique. Les pilotes d'imprimantes détournés peuvent compromettre Windows
NT. Des attachements malicieux aux emails peuvent passer au travers des
parefeu ("firewall"). Les fonctions qui rendent Microsoft Outlook convivial
peuvent en compromettre la sécurité.

La troisième raison c'est l'augmentation des besoins de test des systèmes
complexes. J'ai parlé ailleurs de la sécurité et des échecs aux essais. Le
seul moyen véritable de tester la sécurité d'un système est de réaliser des
évaluations de sécurité sur le système. Toutefois, plus le système est
complexe et plus l'évaluation de sécurité deviendra difficile. Un système
plus complexe aura plus d'erreurs liées à la sécurité, dans la
spécification, dans la conception et dans l'implémentation. Et
malheureusement, le nombre d'erreurs et la difficulté de l'évaluation
n'augmentent pas de pair avec la complexité, mais en fait beaucoup plus vite.

Afin de préserver la simplicité, assumons que le système propose dix
éléments configurables, chacune disposant de ses propres choix. Il y a
alors 45 paires de choix différents qui peuvent interagir de manière
inattendue, et 1024 configurations possibles. Chaque interaction possible
peut mener à une faille de sécurité, et doit être testée de manière
explicite. Maintenant, imaginez que le système propose 20 éléments. Cela
fait 109 paires de choix, et un million de configurations différentes. En
imaginer 30 vous donne 435 paires et un milliard de configurations
différentes. Chaque changement léger dans la complexité des systèmes peut
faire exploser le nombre de configurations différentes.. dont n'importe
laquelle pourrait contenir une faille de sécurité.

L'augmentation d'interactions possibles rend le travail plus difficile dans
l'évaluation de sécurité. Pour un système disposant d'un nombre modéré
d'options, étudier toutes les interactions entre deux options demande une
très grande quantité de travail. Ainsi, la difficulté de réaliser des
évaluations de sécurité augmente aussi très rapidement avec la complexité.
La combinaison des faiblesses additionnelles (potentielles) et d'une
analyse plus difficile de la sécurité produit inévitablement des systèmes à
insécurité.

La quatrième raison c'est que plus un système est complexe, et plus il est
difficile à comprendre. Il y a toutes sortes de vulnérabilités possibles,
l'interface homme-machine, les interactions système.. qui deviennent si
importantes et étendues que vous ne pouvez plus garder tout le système en
mémoire.

La cinquième (et dernière) raison, c'est la difficulté de l'analyse. Plus
un système est complexe, et plus l'analyse elle-même est difficile. Tout
devient plus compliqué: la spécification, la conception, l'implémentation
et l'utilisation. Et comme nous l'avons vu, encore et encore, tout peut
jouer et doit être pris en compte dans l'analyse de la sécurité.

Un système plus complexe perd sur tous les fronts. Il contient plus de
faiblesses avec lesquelles il doit survivre, sa modularité exacerbe ces
faiblesses, il est plus difficile à tester, plus difficile à comprendre et
plus difficile à analyser.

Et cela devient pire: l'augmentation du nombre de faiblesses de sécurité
interagit de manière destructive avec la propriété du lien-faible en
sécurité: la sécurité d'un système en globalité est limite par la sécurité
de son maillon le plus faible. Une seule faiblesse peut ainsi détruire la
sécurité de tout un système.

Les systèmes réels ne montrent aucun signe en direction d'une
simplification. En fait, ils deviennent de plus en plus complexes, et ce de
plus en plus vite. Microsoft Windows est l'exemple type de cette
complexité. Windows 3.1, distribué en 1992, avait 3 millions de lignes de
code; Windows 95 en comportait 15 millions et Windows 98 en avait 18
millions. La version originelle de Windows NT (aussi de 1992) comportait 4
millions de lignes de code, NT 4 (1996) 16.5 millions et en 1998 Windows NT
5 était estimé à environ 20 millions de lignes de code. Une fois renommé
Windows 2000 (en 1999) il avait entre 35 et 60 millions de lignes de code,
selon ce que vous croyez; pour comparer, Solaris qui est bien plus stable
atteint 7 à 8 millions de lignes de code pour ses dernières versions, et
Linux même si l'on ajoute X Window et Apache, se trouve toujours en dessous
de 5 millions de lignes de code.

La taille de Windows 2000 est absolument incroyable, et il doit contenir
bien plus de bogues que Windows NT 4 et Windows 98 combinés. Pour sa
défense, Microsoft clame qu'il a dépensé plus de 500 années/personnes pour
rendre Windows 2000 fiable. Je reprends leur chiffre ici afin d'illustrer à
quel point les 500 années/personnes sont inadaptées.

Les réseaux du futur, qui seront nécessairement bien plus complexes, seront
aussi moins sûrs. L'industrie technologique est menée par la demande de
fonctions, d'options et de vitesse. Il n'y a pas de standards concernant la
qualité et la sécurité, et il n'y a aucune garantie de fiabilité pour les
logiciels. Ainsi, il n'y a aucun besoin économique à produire de la
qualité. En fait, il y a une économie actuelle, dont la motivation
essentielle est de produire le logiciel au coût le plus faible possible et
qui restera accepté par le marché. Et à moins que les consommateurs
n'exigent plus de qualité et une meilleure sécurité, rien ne changera.

Je vois deux alternatives. La première est de reconnaître que le monde
numérique aura toujours une expansion de fonctions et options, des
distributions de plus en plus fréquentes de produits et une complexité en
croissance, et dont la sécurité sera de plus en plus faible. C'est le monde
que nous avons aujourd'hui et que nous embrassons les yeux fermés.

L'autre choix est de ralentir, de simplifier, et d'essayer d'ajouter de la
sécurité. Les demandes des consommateurs sont différentes, les conséquences
en sont bien trop complexes, c'est pourquoi les consommateurs doivent se
regrouper et former un groupe. J'imagine assez bien une organisation du
type FDA pour l'Internet, qui pourrait prendre jusqu'à dix ans pour
autoriser quelque chose, mais économiquement cela ne serait pas viable.

Je répète: la complexité est le pire ennemi de la sécurité. Les systèmes
protégés devront être aussi maigres que possible, et d'une simplicité
maximale. Il n'y a aucun substitut à la sécurité.

Malheureusement, la simplicité va contre tout ce que notre futur numérique
semble aller.


** *** ***** ******* *********** *************

              Commentaires de lecteurs

De: Shawn Hernan <svh@cert.org>
Sujet: Full Disclosure

J'ai été intrigué par votre récente série de Cryptogram concernant
l'annonce complète des failles et en particulier le CERT. Je réponds donc à
cet article.

Une partie des critiques que vous adressez au CERT sont valides et je suis
d'accord avec; mais vous avez souligné un couple de faits qui me laissent
penser que vous n'avez pas compris notre fonctionnement actuel.

Lorsque nous décidons quoi publier et quand, nous utilisons plusieurs
critères.

D'abord, tout ce que nous publions doit être *vrai*, et nous faisons
beaucoup d'efforts pour valider et vérifier tout ce qui nous est soumis, et
vous pouvez imaginer l'argumentation sur ce qui est "vrai" ou non.

Ensuite, comme règle de base, nos réunions traitent des problèmes très
sérieux. Nous avons une échelle graduée formelle, sur laquelle nous tentons
de placer les vulnérabilités sur une échelle linéaire, et nous tentons
ainsi d'estimer la gravité du problème. Nous utilisons ensuite notre propre
expérience pour juge. Généralement, les problèmes soulevés sont situés à
90% de cette échelle (que nous appelons en interne la "règle de menace").

Enfin, bien que cela ait pu être vrai dans le passé, depuis que je
travaille au CERT (cela fait quatre ans maintenant) jamais nos publications
n'ont dépendu de l'existence d'un correctif disponible. Nous préférons,
bien entendu qu'un correctif soit disponible quand nous publions nos
résultats, mais nous savons qu'elle sera exploitée que les correctifs
existent ou pas. Mon équipe (l'équipe qui à pour charge la vulnérabilité)
travaille de manière proche et journalière avec l'équipe qui recherche
toute trace d'incident, afin de savoir si une vulnérabilité particulière a
été exploitée.

Vous voyez donc que je recherche à publier l'information de manière
responsable et pratique concernant les vulnérabilités. Nous sommes une
petite organisation, et je n'ai pas envie de sacrifier la vérité pour aller
plus vite.


De: Ryan Russell <ryan@securityfocus.com>
Sujet: Distributing Exploits

Vous n'êtes pas toujours totalement constant dans ce que vous annoncez:

  >Enfin, je pense que c'est être irresponsable, et même criminel,
  >de distribuer des exploits.

Et vous avez par ailleurs indiqué que la révélation des vulnérabilités
était ce qui poussait à l'action.

  >Désassembler les systèmes de sécurité, découvrir des vulnérabilités,
  >et écrire des documents de recherche sur le sujet; tout cela nous
  >rend meilleurs pour construire des systèmes sûrs. Distribuer les
  >exploits ne fait que nous rendre plus vulnérables.

Vous reconnaissez ne pas être constant dans vos propos, mais ce n'est ni
ici ou là. Un exploit ne suffit pas toujours, il faut aussi y ajouter la
presse. Thievco a distribué un "exploit" qui permet de décoder les mots de
passe Netscape il y a plus d'un an. Netscape n'a rien fait. RST Corp. a
fait la même chose, mais en utilisant la presse.. Et l'attention de
Netscape a changé.

  >Par exemple, Mixter est un pirate allemand qui a écrit
  >l'outil Tribal Flood Network qui a été utilisé dans
  >quelques-unes des attaques de Denial of Service. Je pense
  >qu'il a beaucoup à expliquer pour cela. Son outil d'attaque
  >n'a pas servi en bien.

Ce n'est pas vrai. Sans lui, nous serions encore ne train d'imaginer ou de
chercher des outils mystérieux dont nous n'aurions ni le code source, ni
même une analyse. Mixter nous a montré exactement quel type d'outil et par
quel procédé l'attaque se réalise, afin que les journalistes ne puissent
pas courir partout en expliquant que les pirates ont des super-armes que
les experts de sécurité ignorent.

  >Cela assure la position des criminels et coûte beaucoup aux
  >compagnies. Leur existence leur les réseaux moins sûrs.

Comme vous l'indiquez, tout outil peut être utilisé en bien et en mal.
Comme vous l'avez indiqué, le problème de sécurité était déjà présent, et
les outils n'ont fait que porter la lumière dessus.

Laissez- moi parler au sujet de vos reproches à Mixter. Quelques personnes
pensent que Mixter devrait être puni. Je ne pense pas, mais j'y vois une
logique. Je pense que si l'on doit punir quelqu'un, alors que ce soit ceux
qui ont utilisé cet outil.

Est-ce que Mixter ou même les attaquants ont actuellement fait quelque
chose dans l'esprit de l'annonce complète? Oui.

Cela fait des années que nous nous plaignions au sujet du spoofing, et que
nous attendons des FAI qu'ils les filtrent. Rien n'a été fait. Mixter a
ensuite distribué son outil. Quelques réunions et discussions ont eu lieu
afin de discuter le Denial of Service. Aucun changement dans le
comportement actuel, mais une planification se met en place, ce qui est une
bonne préparation. Enfin, quelques personnes (oui, des criminels) ont
utilisé l'outil. Ils n'ont pas attaqué les sites traitant de la sécurité.
Ils n'ont pas attaqué le gouvernement. Ils ont attaqué le commerce
électronique, et ce afin de provoquer la plus grande réaction possible.

Je pense que les choses vont bouger un peu maintenant.


De: Brian Bartholomew <bb@wv.com>
Sujet: Publishing exploits

  > Puis, je crois qu'il faut donner au vendeur un peu de temps
  > d'avance. Le CERT le prend à l'extrême, et donne parfois des
  > années au vendeur pour corriger le problème. Je préfère voir
  > le chercheur annoncer au vendeur qu'il va publier la
  > vulnérabilité dans un mois, ou trois semaines (ce n'est pas
  > équitable de donner sept jours à un vendeur pour réagir).
  > Idéalement, l'annonce de la vulnérabilité sera suivie de
  > manière proche par le correctif. Cela bénéficiera à tout le monde.

Quelles que puissent être les motivations du CERT, elles augmentent la
confiance de l'utilisateur (parce qu'un nouveau Sheriff est en ville) tout
en réduisant la confiance (parce qu'ils ont en main les vulnérabilités).
C'est revenir en arrière, sous deux points.

Je préfère l'approche suivante: annoncer l'existence d'une vulnérabilité et
promettre un exploit dans le mois qui suit; donner un mois au vendeur pour
réagir, et publier l'exploit.

  > Publier les vulnérabilités de systèmes critiques qui ne peuvent 
  > être facilement corrigés et dont l'exploitation peut provoquer
  > des dégâts (le système de contrôle aérien par exemple) est mauvais.

La publication est *très importante* dans ce cas, afin de permettre aux
détenteurs d'actions de réduire leur confiance dans ces systèmes. Si le
contrôle aérien est vulnérable, alors autant le dire et je ne prendrais
plus l'avion!

Une version du ce problème est la publication d'un script qui permet de
donner à un processus actif les privilèges root (d'administrateur) en
utilisant le débogueur mémoire du moniteur console ("L1-A") sur Sun. Le
débogueur pouvait être désactivé, mais personne ne l'a fait car cela
désactive alors le bouton de redémarrage à chaud.  Cette annonce de
vulnérabilité a permis aux utilisateurs de choisir leur degré de sécurité.

  >Enfin, je pense que c'est être irresponsable, et même criminel,
  >de distribuer des exploits.

C'est un contrôle par les armes: "Ne punissez pas le meurtrier, bannissez
l'arme! Les exploits sont des outils sataniques! Les exploits peuvent
rendre un gentil garçon mauvais!". La bonne réponse est plutôt: les humains
doivent être responsables de leurs actes. Les armes, les exploits.. toutes
ces choses ne sont que des outils entre leurs mains.


De: Greg Guerin <glguerin@amug.org>
Sujet: publicity attack loops?

Je dois admettre que j'ai été surpris en lisant la lettre
Fernandes/Cryptonym dans l'édition de février 2000 de Cryptogram. En
particulier lorsqu'il s'habille à la fin dans le manteau de l'intégrité
professionnelle. J'ai déjà écrit deux essais sur la découverte de Fernandes
et sur son ZIP de "réparation" téléchargeable:

    <http://amug.org/~glguerin/opinion/win-nsa-key.html>
    <http://amug.org/~glguerin/opinion/crypto-repair-kit.html>

Bien qu'aucun ne concerne l'intégrité professionnelle de Fernandes, ils
soulignent quelques points concernant des pratiques spécifiques. Pour
résumer ces points (consultez les essais pour une explication complète):

    1) le ZIP contenait 2 EXE, 2 DLL et 1 fichier source.
    2) le ZIP à télécharger n'avait aucune signature numérique.
    3) rien dans le ZIP ne disposait de signature numérique séparée.
    4) la clef PGP de Fernandes n'a aucun introducteur.
    5) aucun lien vers d'autres choses pouvant assurer les points 2-4.
    6) le source fourni n'était pas compilable sous la forme distribuée
       (en-tête manquant).

Le point 6 est important car il signifie qu'il faut faire confiance à l'EXE
tel qu'il est fourni. Il n'y a par ailleurs qu'un seul fichier source
fourni, donc cela implique que vous faites complètement confiance à l'autre
EXE aussi. Et il faut aussi faire confiance aux deux DLL. C'est un peu
risqué, et accorder une confiance aveugle à 75% c'est comme faire confiance
aveugle à 100%. C'est comme de choisir de tuer quelque chose 3 ou 4 fois de
suite, alors qu'on peut le faire en une fois.

Notez qu'à aucun moment la notion "d'intégrité professionnelle" n'entre en
jeu, mais je parle de "pratique professionnelle". Je ne discute pas
l'intention (sur le plan de l'intégrité) mais le résultat (la pratique).
L'intégrité sans tache et l'intention ne peuvent survivre longtemps aux
erreurs prévues en pratique. En observant les pratiques un observateur peut
en déduire la compétence, l'intégrité et même les deux, ou aucune. Ces
jugements, et le critère de confiance qu'ils contiennent, sont laissés à
l'observateur. Tout ce que je peux dire c'est que de mon point de vue, mes
critères de confiance diffèrent des vôtres. Mais vous devriez aussi
chercher pourquoi vous êtes parvenus à cette conclusion.


De: "Rolf Oppliger" <rolf.oppliger@esecurity.ch>
Sujet: Distributed Denial-of-Service Attacks

Avant tout, j'aimerais vous remercier pour votre description et analyse des
attaques distribuées de Denial of Service (DOS) dans l'exemplaire de
février de Cryptogram. Je suis tout à fait d'accord avec vos déclarations,
y compris votre avis pessimiste sur le fait que toute approche visant à
régler le problème n'est pas satisfaisante d'un point de vue ou de l'autre.

Dans votre article, toutefois, vous soutenez aussi "qu'au long terme, la
signalisation hors bande pourrait être le seul moyen de régler une grande
part des vulnérabilités d'Internet, y compris les attaques DDS". Je ne suis
pas d'accord avec cela. Toute bande de signalisation peut faire l'objet
d'une attaque du type DoS et DoS distribuée. Je pense que la seule raison
pour laquelle les réseaux téléphoniques ne font l'objet d'attaques DoS à
grande échelle ou distribuées tient plus à leur prix et système de
facturation plutôt qu'à leur signalisation en hors-bande. Essayer de
réaliser une grande quantité de connexions va coûter simplement trop cher..
Je pense que la leçon à tirer des réseaux téléphoniques est que leurs
transmissions sont basées sur des paquets, et leur facturation sur ces
mêmes paquets, cela combiné avec des mécanismes de sécurité adaptés. Cela
peut être une solution viable pour se protéger contre des attaques DoS à
grande échelle sur Internet (plutôt que de reposer sur une signalisation
hors-bande). Toutefois, une facturation basée sur les paquets a beaucoup de
désavantages, comme un besoin d'administration immense. Pour conséquence,
ce système de facturation par paquet ne sera pas appliqué à Internet, et
que le filtrage "intelligent" des paquets réalisé par les FAI sera l'arme
majeure contre les attaques DoS et DoS distribuées dans le futur.


De: Ethan Benatan <benatan@duq.edu>
Sujet: Defending Against DOS Attacks: Draining the Swamp

Si vous me pardonnez l'aveuglement d'un biologiste, je voudrais apporter un
commentaire à votre analogie du marais. Je sais que vous n'avez jamais dit
que les "marais" ne sont pas "mauvais" au sens défensif, ni même qu'il soit
"bon" de les drainer, même si cela a une conséquence immédiate et
bénéfique. Je suis sûr que, dans votre propre domaine, vous pouvez trouver
beaucoup d'exemples où une solution, bien qu'efficace, ait été plus néfaste
que la maladie. Le RISQUE ici c'est d'oublier que tout système complexe
change et que cela possède un coût; plus le système est complexe (ou moins
compris) et plus il est difficile de prévoir le coût. Je pense que cela
s'applique à Internet. Cela s'applique certainement au monde réel, par
endroits. Je ne vais pas vous ennuyer avec des exemples.


De: pclites@cdsfulfillment.com
Sujet: deCCS

Dans le Cryptogram de février 2000, vous avez écrit: "Un point important
est que les DVD peuvent être copiés et piratés sans l'utilisation de deCSS
ou de tout autre outil de déchiffrement, ce qui rend l'annonce originelle
'empêche le piratage' soit la marque d'une ignorance complète soit vraiment
décevant".

Il y a un sens à l'annonce "empêche le piratage". deCSS rend facile la
copie des données d'un DVD non pas sur un autre DVD, mais sous tout autre
format, qui lui sera plus facile à copier et à transmettre. Dans ce cadre,
nous pouvons le classer dans les outils qui rendent le piratage plus
facile. C'est un peu le même raisonnement qu'entre les formes imprimées et
électroniques du code source, quand il a fallu régler le problème des
restrictions à l'exportation; mais je pense que pour les données d'un
produit utilisateur, la signification est plus utile. Je dirais que le
jugement de la cour dans ce cas est l'application correcte d'une mauvaise
loi, ce qui pourrait au final aboutir à un coup d'épée dans l'eau.


De: "Bryan Alexander" <xande1@bellsouth.net>
Sujet: Secure Linux

  > La NSA a pris un contrat avec Secure Computing Corp. pour
  > une version protégée de Linux. Personnellement, je ne sais
  > pas si la licence Linux permet à la NSA de réaliser une
  > version sécurisée du système d'exploitation s'ils ne veulent
  > pas en distribuer librement les résultats.

Actuellement, le GPL (Gnu Public Licence, qui couvre pratiquement toutes
les parties de Linux) le permet. Il n'y a rien dans la licence qui demande
à ce que vous redistribuiez tout travail basé sur GPL, mais seulement ce
que vous devez redistribuer si vous distribuez un travail basé sur le GPL.
En plus, le Projet GNU a dit de manière spécifique que la licence GNU ne
vise pas à empêcher la création (sans être forcé à distribuer) leur propres
versions modifiées de logiciels sous GPL pour leur propre usage. Le texte
du GPL se trouve à:
<http://www.gnu.org/copyleft/gpl.html>

Une déclaration où la distribution des versions modifiées est forcée et
décrite comme une "restriction inacceptable" peut être trouvée à:
<http://www.gnu.org/philosophy/apsl.html> sous le titre "Disrespect for
Privacy". C'est une part de discussion des "fatal flaws" dans la licence
APSL Apple (je ne retrouve pas la source originelle du commentaire, désolé).

** *** ***** ******* *********** *************

Cryptogram est une lettre d'information gratuite et mensuelle vous
proposant des résumés, analyses, éclaircissements et commentaires sur la
sécurité informatique et la cryptographie.

Pour vous inscrire ou vous retirer de cette liste dans sa version française:
<http://pro.wanadoo.fr/gilb/cg.html>

Version anglaise:
<http://www.counterpane.com/crypto-gram.html>

Veuillez faire suivre Cryptogram à vos collègues et amis qui
l'apprécieront. Vous êtes invités à reproduire et imprimer Cryptogram
attendu que vous le reproduisez dans son intégralité.

Cryptogram est écrit par Bruce Schneier; fondateur et CTO de Counterpane
Internet Security Inc., l'auteur de "Cryptographie appliquée", et
l'inventeur des algorithmes Blowfish, Twofish et Yarrow. Il a participé au
conseil de l'association internationale de recherche cryptologique (IACR),
EPIC et VTW. Il participe activement à la sécurité informatique et la
cryptographie.

Counterpane Internet Security, Inc. est une entreprise basée sur fonds
propres et qui apporte des solutions innovantes à l'entreprise.

http://www.counterpane.com/

Droits déposés (c) 2000 Counterpane Internet Security, Inc.
  

_________________
FWD: jmm@free.fr, 
TR: , 
voiRE: http://emedia.free.fr
guess what ?...:\ I'm buggy!





_____________________________________________
#<nettime-fr@ada.eu.org> est une liste francophone de politique,
 art,culture et net, annonces et filtrage collectif de textes.
#Cette liste est moderee, pas d'utilisation commerciale sans permission.
#Archive: http://www.nettime.org contact: nettime@bbs.thing.net
#Desabonnements http://ada.eu.org/cgi-bin/mailman/listinfo/nettime-fr 
#Contact humain <nettime-fr-admin@ada.eu.org>