![[OpenBSD]](../images/smalltitle.gif){kind=small}
| Index | |
|
Buts de Sécurité du Projet. Politique de transparence totale. Procédé d'audit du code source. "Secure by Default". Utilisation de la Cryptographie.
Regard sur les changements.
|
Pour les bulletins de sécurité concernant des révisions spécifiques,
cliquez ci-dessous : 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 2.7, 2.8, 2.9, 3.0, 3.1, 3.2, 3.3, 3.4, 3.5, 3.6, 3.7, 3.8, 3.9, 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6, 4.7, 4.8, 4.9, 5.0, 5.1. |
OpenBSD croit en la sécurité forte. Notre objectif est d'être NUMÉRO UN dans l'industrie de la sécurité (si nous ne le sommes pas déjà). Notre modèle de développement logiciel ouvert nous permet de rester plus intransigeants vis-à-vis de l'amélioration de la sécurité que Sun, SGI, IBM, HP, ou d'autres vendeurs qui pourraient l'être. Nous pouvons réaliser des changements auxquels les vendeurs se refusent. Aussi, depuis qu'OpenBSD est fourni avec de la cryptographie, nous sommes en mesure d'avoir une approche cryptographique pour la résolution des problèmes de sécurité.
Comme beaucoup de lecteurs de la liste de diffusion BUGTRAQ, nous croyons en la divulgation totale des problèmes de sécurité. Dans l'arène des systèmes d'exploitation, nous fûmes probablement les premiers à mettre en application ce concept. Beaucoup de vendeurs, même de logiciels libres, continuent de cacher les problèmes de sécurité à leurs utilisateurs.
L'information sur la sécurité se déplace très vite dans le cercle des crackers. D'un autre côté, notre expérience est telle que le codage et la mise en production de nos propres correctifs de sécurité demandent environ une heure de travail -- le travail d'haleine afin de faire des correctifs très rapidement est possible. C'est pour cela que nous pensons que la transparence totale aide les personnes qui se soucient vraiment de la sécurité.
Notre équipe d'audit de la sécurité est en général de six à douze membres qui continuent de chercher et de corriger les nouvelles failles de sécurité. Nous auditons depuis l'été 1996. Le procédé que nous suivons afin d'améliorer la sécurité est simplement une analyse complète, fichier par fichier, de chaque composant logiciel critique. Nous ne recherchons pas plus énergiquement les failles de sécurité que les bogues logiciels basiques, et si ces dernières années quelqu'un découvrait un problème s'avérant être un problème de sécurité, nous le corrigions même si ce n'était qu'un bogue, tout allait au mieux. Des failles ont été trouvées dans pratiquement chaque partie du système. Des ensembles entiers de problèmes de sécurité ont été trouvés pendant notre audit et le code source qui a déjà été audité doit souvent l'être à nouveau avec les nouvelles expériences en tête. Le code doit souvent être audité plusieurs fois, et par différentes personnes avec leurs compétences d'audit propres.
Des membres de notre équipe d'audit de la sécurité travaillent pour Secure Networks, la société qui créa le premier logiciel de sécurité de balayage réseau, appelé Ballista (Secure Networks fut racheté par Network Associates, Ballista fut renommé Cybercop Scanner, etc.) Cette société fit un grand nombre de recherches sur la sécurité, ce qui correspondait bien à la position d'OpenBSD. OpenBSD réussit les tests de Ballista avec mention dès le premier jour.
Un autre aspect de notre procédé d'audit de la sécurité est son caractère proactif. Nous avons vu dans la plupart des cas que la découverte d'un exploit potentiel n'est pas forcément un problème. Pendant notre processus continu d'audit, nous trouvons beaucoup de bogues, et nous faisons l'effort de les corriger même si l'exploitabilité n'est pas prouvée. Nous corrigeons le bogue, et nous cherchons d'autres bogues à corriger. Nous avons corrigé beaucoup de négligences de programmation, erreurs simples et évidentes dans le code et découvert seulement ces derniers mois que les problèmes étaient en fait exploitables. (Ou plus communément quelqu'un sur BUGTRAQ pouvait rapporter que les autres systèmes d'exploitation étaient vulnérables à un `nouveau problème découvert', et il était ensuite constaté qu'OpenBSD avait été corrigé lors des révisions précédentes). Dans d'autres cas, nous avons été sauvés de l'exploitation totale d'une attaque étape par étape complexe car nous avions corrigé l'une des étapes intermédiaires auparavant. Un exemple de ce déroulement couronné de succès est le bulletin sur lpd publié par Secure Networks.
De la même manière que nous auditons le code source, nous inventons souvent de nouveaux moyens pour résoudre les problèmes. Parfois, ces idées ont été utilisées auparavant dans des applications diverses, mais peut-être pas à un tel niveau.
Notre procédé d'audit proactif a réellement été fructueux. Des propos comme ``Ce problème a été corrigé dans OpenBSD il y a environ six mois'' sont devenus chose courante dans les forums de sécurité comme BUGTRAQ.
La partie la plus importante de notre audit de sécurité a commencé juste avant la révision OpenBSD 2.0 et pendant la transition 2.0->2.1, pendant le dernier trimestre de 1996 et le premier semestre de 1997. Des milliers (oui, des milliers) de problèmes de sécurité furent corrigés rapidement pendant cette période; des bogues comme les débordements de tampons classiques, les manques dans l'implémentation des protocoles, la collecte d'information, et les situations de compétition dans les systèmes de fichiers. Par conséquent, la plupart des problèmes rencontrés furent corrigés avant notre révision 2.1. Nous ne trouvons plus aujourd'hui autant de problèmes, à en juger par le nombre de retours qui diminue. Les problèmes que nous avons trouvé et corrigé récemment étaient significativement plus obscurs ou compliqués. Nous continuons pour différentes raisons :
Le processus d'audit n'est pas encore terminé, et comme vous le voyez nous continuons de trouver et de corriger de nouvelles failles de sécurité.
Afin que les utilisateurs novices d'OpenBSD n'aient pas à devenir des experts en sécurité pendant la nuit (un point de vue que les autres vendeurs semblent avoir) nous fournissons le système d'exploitation dans un mode "sécurisé par défaut". Tous les services qui ne sont pas essentiels sont désactivés. Quand l'utilisateur/administrateur devient plus familier avec le système, il découvre qu'il a besoin d'activer des démons et d'autres parties du système. Pendant le processus d'apprentissage d'activation d'un nouveau service, le novice est plus apte à apprendre les considérations de sécurité.
C'est un contraste saisissant avec le nombre croissant de systèmes fournis avec NFS, mountd, des serveurs web, et d'autres services activés par défaut, créant ainsi des problèmes de sécurité à leurs utilisateurs quelques minutes après la première installation.
Et bien sûr, depuis que le projet OpenBSD est basé au Canada, il nous est possible d'intégrer la cryptographie. Pour plus d'informations, lisez la page intitulée ce que nous avons fait avec la cryptographie.
OpenBSD 4.9 et les versions antérieures ne sont dorénavant plus
supportées. Les paragraphes suivants listent uniquement les problèmes
survenus lorsqu'elles étaient maintenues; ces versions sont certainement
concernées par les bulletins sur les versions plus récentes.
Depuis que nous avons pris une approche proactive de la sécurité, nous recherchons et corrigeons continuellement de nouveaux problèmes de sécurité. Certains de ces problèmes ont été rapportés tardivement (et analysés récemment) car beaucoup d'entre eux n'étaient à priori pas exploitables; beaucoup de simples bogues que nous corrigeons peuvent avoir des conséquences sur la sécurité que nous ne pouvions prédire. Nous n'avons ni le temps ni les moyens de rendre disponible ces changements dans le format ci-dessus.
Ainsi il y a régulièrement des corrections de sécurité mineures dans le code source de current au delà des révisions précédentes de OpenBSD. Nous donnons la garantie limitée que ces problèmes ont un impact minimal et une exploitabilité non prouvée. Si nous découvrons qu'un problème a un effet sur la sécurité, les "patches" apparaitront ici TRÈS rapidement.
Les gens qui sont réellement concernés par la sécurité peuvent faire un certain nombre de choses :
Si vous trouvez un nouveau problème de sécurité, vous pouvez l'envoyer
par mail à deraadt@openbsd.org.
Si vous désirez l'encoder avec PGP (mais je vous prie de le faire
seulement si la confidentialité est vraiment importante, sinon c'est un
inconvénient) utilisez cette
clef PGP.
De nombreux documents ont été écrits par des membres de l'équipe OpenBSD, la plupart dédiés à la sécurité.
www@openbsd.org