FAQ de l'équipe Debian sur la sécurité

Une annonce de sécurité (DSA) est reçue émanant de debian-security-announce, comment mettre à niveau le paquet vulnérable ?
La signature des avis de sécurité ne semble pas authentique !
Comment la sécurité est-elle gérée dans Debian ?
Pourquoi vous embêtez-vous avec une vieille version de ce paquet ?
Le numéro de version d'un paquet indique-t-il une version vulnérable ?
J'ai reçu une annonce, mais la construction pour une architecture de processeur semble manquer.
Comment est gérée la sécurité pour unstable ?
Comment est gérée la sécurité pour testing ?
Comment est gérée la sécurité pour contrib, non-free et non-free-firmware ?
L'annonce dit que la distribution unstable est corrigée dans la version 1.2.3-1, mais unstable a la version 1.2.5-1, que se passe-t-il ?
Pourquoi n'y a-t-il pas de miroir officiel de security.debian.org ?
J'ai vu les DSA 100 et DSA 102, mais où est la DSA 101 ?
Comment joindre l'équipe chargée de la sécurité ?
Je pense avoir trouvé un problème de sécurité, que suis-je censé faire ?
Que suis-je censé faire si l'un de mes paquets présente un problème de sécurité ?
J'ai essayé de télécharger un paquet mentionné dans un bulletin d'alerte, mais j'ai eu une erreur « fichier non trouvé ».
Je possède un correctif, puis-je le mettre en ligne sur security.debian.org directement ?
Je possède un correctif, puis-je le mettre en ligne dans proposed-updates ?
Je suis presque persuadé que mes paquets sont correctement construits, comment puis-je les mettre en ligne ?
Comment puis-je fournir de l'aide sur la sécurité ?
Quel est le contenu de « proposed-updates » ?
De quelle façon est constituée l'équipe chargée de la sécurité ?
Pendant combien de temps les mises à jour de sécurité seront-elles fournies ?
Comment puis-je contrôler l'intégrité des paquets ?
Que faire si un paquet est cassé suite à une mise à jour de sécurité ?
Qu’est-ce qu’un identifiant CVE ?
Est-ce que Debian réalise une annonce de sécurité (DSA) pour chaque identifiant CVE ?
Debian peut-elle assigner des identifiants CVE ?
Est-ce que Debian a une politique de divulgation de vulnérabilité ?
Notre politique de gestion de vulnérabilités a montré que les problèmes suivants sont à résoudre (liste de CVE avec des évaluations variables). Quand cela sera-t’il réglé ?
Que signifie local (remote) ?

Question : Une annonce de sécurité (DSA) est reçue émanant de debian-security-announce, comment mettre à niveau le paquet vulnérable ?

Réponse : Comme il est indiqué dans le courriel de DSA, vous devez mettre à niveau les paquets touchés par cette vulnérabilité annoncée. Cela peut être fait simplement en mettant à niveau (après une mise à jour de la liste des paquets disponibles avec apt-get update) tous les paquets composant votre système avec apt-get upgrade, ou en mettant à niveau un paquet particulier avec apt-get install paquet.

Le courriel d’annonce mentionne le paquet source dans lequel la vulnérabilité était présente. Par conséquent, tous les paquets binaires issus de ce paquet source doivent être mis à niveau. Pour connaître les paquets binaires à mettre à niveau, consultez https://packages.debian.org/src:nom_paquet_source et cliquez sur [recherche ... noms de paquets source] pour la distribution à mettre à jour.

Il peut être nécessaire de redémarrer un service ou un processus en cours. La commande checkrestart fournie par le paquet debian-goodies peut aider à déterminer lesquels.

Q. : La signature des avis de sécurité ne semble pas authentique !

R. : C'est sans doute dû à un problème de votre côté. La liste debian-security-announce a un filtre qui n'autorise que les messages avec une signature valable d'un membre de l'équipe chargée de la sécurité.

Un de vos outils de messagerie doit légèrement modifier le message, ce qui corrompt la signature. Vérifiez qu'aucun logiciel ne fait d'encodage ou de décodage MIME, ou de substitutions entre espaces et tabulations.

Les coupables habituels sont fetchmail (avec l'option mimedecode activée), formail (venant de procmail 3.14 seulement) et evolution.

Q. : Comment la sécurité est-elle gérée dans Debian ?

R. : Dès que l'équipe en charge de la sécurité reçoit une notification d'incident, un ou plusieurs de ses membres examinent la situation et évaluent l'impact sur la version stable de Debian (c'est-à-dire si elle est vulnérable ou non). Si notre système est vulnérable, nous préparons une correction du problème. Le responsable du paquet est lui aussi contacté, s'il n'a pas déjà contacté l'équipe en charge de la sécurité. Enfin, la correction est testée et de nouveaux paquets sont préparés ; ces paquets sont compilés sur toutes les architectures stables puis envoyés. Après toutes ces étapes, une annonce est publiée.

Q. : Pourquoi vous embêtez-vous avec une vieille version de ce paquet ?

R. : La règle la plus importante lors de la construction d'un nouveau paquet qui corrige un problème de sécurité est de faire le moins de modifications possibles. Nos utilisateurs et nos développeurs s'attendent à ce que la distribution conserve son comportement d'origine. Ainsi, toute modification, aussi petite soit-elle, peut éventuellement casser le système de quelqu'un. C'est particulièrement vrai avec des bibliothèques : assurez-vous de ne jamais modifier l'interface de programmation d'applications (API) ou l'interface binaire de l'application (ABI : Application Binary Interface).

Cela signifie que passer à une version amont plus récente n'est pas une bonne solution. La modification doit plutôt être rétroportée. En règle générale, les mainteneurs amont donnent un coup de main, sinon l'équipe en charge de la sécurité pourrait aider.

Dans certains cas, rétroporter un correctif de sécurité n'est pas possible, par exemple si une grande partie du code source doit être modifiée ou réécrite. Dans ce cas, il sera peut-être nécessaire de passer à une nouvelle version amont, mais cela devra se faire en coordination avec l'équipe en charge de la sécurité.

Q. : Le numéro de version d'un paquet indique-t-il une version vulnérable ?

R. : Au lieu de passer à une nouvelle version, nous réalisons un rétroportage (backport) du correctif de sécurité dans la version de la distribution stable. La raison d'agir ainsi est simple : une version publiée (release) doit changer le moins possible ; ainsi, les correctifs de sécurité ne seront pas la cause de problèmes annexes. Vous pouvez vérifier si une version d'un paquet est sécurisée en examinant son journal de modifications, ou en comparant son numéro exact de version et celui indiqué par le bulletin d'alerte de l'équipe Debian chargée de la sécurité.

Q. : J'ai reçu une annonce, mais la construction pour une architecture de processeur semble manquer.

R. : Normalement, l'équipe chargée de la sécurité publie une annonce avec les constructions des paquets mis à jour pour toutes les architectures prises en charge par Debian. Néanmoins, c'est plus lent pour certaines architectures que pour d'autres et il peut arriver que les constructions pour la plupart des architectures soient prêtes alors qu'il en manque d'autres. Ces architectures plus petites représentent une petite partie de notre base d'utilisateurs. En fonction de l'urgence du problème, il peut être décidé de publier l'annonce sans délai. Les constructions manquantes seront ajoutées à l'archive dès qu'elles seront disponibles, mais aucun avis ne sera publié à ce sujet. Évidemment, il ne sera jamais publié d'annonce sans les constructions pour i386 ou amd64.

Q. : Comment est gérée la sécurité pour unstable ?

R. : La sécurité pour unstable est d’abord gérée par les responsables de paquets et non par l’équipe chargée de la sécurité. Bien que l’équipe chargée de la sécurité puisse envoyer des correctifs de sécurité urgents quand les responsables ont l’air inactifs, la prise en charge de stable sera toujours la priorité. Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable.

Q. : Comment est gérée la sécurité pour testing ?

R. : La sécurité pour testing bénéficie des efforts sur la sécurité réalisés par tout le projet pour unstable. Cependant, un délai minimal de deux jours existe pour la migration, et les correctifs de sécurité peuvent parfois être retenus par les transitions. L’équipe chargée de la sécurité aide à faire avancer ces transitions qui retiennent les envois de sécurité importants, mais ce n’est pas toujours possible et des contretemps peuvent survenir. En particulier, les mois qui suivent une nouvelle publication de stable, quand de nombreuses nouvelles versions sont envoyées dans unstable, les correctifs de sécurité pourraient être mis en attente. Si vous souhaitez un serveur sûr (et stable), vous devriez garder la distribution stable.

Q. : Comment est gérée la sécurité pour contrib, non-free et non-free-firmware ?

R. : La réponse courte est : elle ne l'est pas. contrib, non-free et non-free-firmware ne font pas officiellement partie de la distribution Debian et ne sont pas publiées, c'est pourquoi elles ne sont pas prises en charge par l'équipe en charge de la sécurité. Certains paquets de non-free sont distribués sans les sources ou avec une licence ne permettant pas la distribution de versions modifiées. Dans ces deux derniers cas, les corrections de sécurité sont simplement impossibles à faire. S'il est possible de corriger le problème, et que le responsable du paquet ou quelqu'un d'autre fournit des paquets correctement mis à jour, alors l'équipe en charge de la sécurité, dans la plupart des cas, intégrera ces paquets et publiera une annonce de sécurité.

Q. : L'annonce dit que la distribution unstable est corrigée dans la version 1.2.3-1, mais unstable a la version 1.2.5-1, que se passe-t-il ?

R. : Nous essayons de donner le numéro de la première version qui a résolu le problème dans unstable. Parfois, le mainteneur du paquet a pu mettre à disposition entre temps une version plus récente. Comparez la version qui se trouve dans unstable avec la version que nous indiquons dans l'annonce, si la version dans unstable est égale ou supérieure vous devriez être à l'abri de la vulnérabilité. Pour en être sûr, le journal des modifications peut être consulté avec apt-get changelog nom_paquet et l’entrée annonçant la résolution du problème recherchée.

Q. : Pourquoi n'y a-t-il pas de miroir officiel de security.debian.org ?

R. : En fait, il y a plusieurs miroirs officiels, mis en œuvre à l'aide d'alias DNS. Le but de security.debian.org est de mettre à disposition les mises à jour de sécurité aussi rapidement et facilement que possible.

Encourager l'utilisation des sites miroirs ne ferait qu'ajouter de la complexité là où elle n'est pas nécessaire, et pourrait causer des problèmes s'ils n'étaient pas à jour.

Q. : J'ai vu les DSA 100 et DSA 102, mais où est la DSA 101 ?

R. : Plusieurs distributeurs (la plupart de GNU/Linux, mais aussi des dérivés BSD) coordonnent leurs alertes de sécurité pour certains incidents et se mettent d'accord sur une date de parution, afin de permettre aux distributeurs de sortir l'avis en même temps. Cela a été décidé afin de ne pas faire de tort à certains distributeurs qui ont besoin de plus de temps (par exemple lorsque le distributeur doit passer par de longues phases de tests imposés par son assurance qualité, ou doit fournir des solutions sur une multitude d'architectures). Notre propre équipe en charge de la sécurité prépare ainsi ses avis à l'avance. De temps en temps, d'autres problèmes de sécurité doivent être traités avant que l'avis en attente ne soit rendu public, et ainsi la continuité de la numérotation est temporairement rompue.

Q. : Comment joindre l'équipe chargée de la sécurité ?

R. : Les informations relatives à la sécurité peuvent être envoyées à [email protected] ou à [email protected], chacune de ces adresses est lue par l'équipe chargée de la sécurité.

Si nécessaire, le message peut-être chiffré avec la clé publique du contact sécurité Debian (identifiant de clef 0x0D59D2B15144766A14D241C66BAF400B05C3E651). Pour les clés OpenPGP individuelles des membres de l'équipe chargée de la sécurité, veuillez consulter le serveur de clés keyring.debian.org.

Q. : Je pense avoir trouvé un problème de sécurité, que suis-je censé faire ?

R. : Si vous êtes informé de l'existence d'un problème de sécurité, soit dans un de vos paquets, soit dans le paquet de quelqu'un d'autre, prenez systématiquement contact avec l'équipe en charge de la sécurité. Si celle-ci confirme la faille et que d'autres distributeurs sont également concernés, elle prendra également contact avec eux. Si la vulnérabilité n'est pas encore publique, l'équipe essayera de coordonner l'annonce avec les autres distributeurs, de telle sorte que les distributions principales soient synchronisées.

Si la vulnérabilité a déjà été rendue publique, assurez-vous de remplir un rapport de bogue dans le système de suivi des bogues (BTS) de Debian, avec la marque security.

Si vous êtes un développeur Debian, regardez ci-dessous.

Q. : Que suis-je censé faire si l'un de mes paquets présente un problème de sécurité ?

R. : Si vous entendez parler d'un problème de sécurité, soit dans votre paquet, soit dans le paquet de quelqu'un d'autre, vous devez toujours prendre contact avec l'équipe en charge de la sécurité par courriel à l'adresse [email protected]. Cette équipe s'occupe du suivi des problèmes de sécurité, peut aider les responsables de paquets à corriger les problèmes de sécurité ou les corrige elle-même. Elle est responsable de l'envoi des bulletins d'alerte de sécurité et de l'entretien du site security.debian.org.

La Référence du développeur contient les instructions complètes sur la démarche à suivre.

Il est très important de ne pas envoyer de paquets ailleurs que dans la distribution unstable sans y avoir été préalablement invité par l'équipe en charge de la sécurité. Si vous ne respectez pas cette règle, cela entraînera de la confusion et nécessitera plus de travail.

Q. : J'ai essayé de télécharger un paquet mentionné dans un bulletin d'alerte, mais j'ai eu une erreur « fichier non trouvé ».

R. : À chaque fois qu'une nouvelle correction de bogue de sécurité remplace un paquet plus ancien de security.debian.org, il y a de grandes chances que l'ancien paquet soit supprimé, lorsque le nouveau est installé. Par conséquent, ce genre d'erreur peut survenir. Nous ne voulons pas distribuer des paquets avec des bogues de sécurité connus plus longtemps qu'il n'est nécessaire.

Veuillez utiliser les paquets des bulletins d'alerte les plus récents, qui sont distribués sur la liste de diffusion debian-security-announce. Mieux vaut lancer simplement apt-get update avant de mettre à niveau le paquet.

Q. : Je possède un correctif, puis-je le mettre en ligne sur security.debian.org directement ?

R. : Non, vous ne pouvez pas. Les archives de security.debian.org sont entretenues par l'équipe en charge de la sécurité, qui doit approuver tous les paquets. Vous devez envoyer vos correctifs ou des paquets source corrects à l'équipe en charge de la sécurité par courriel à l'adresse [email protected]. Ils seront revus par l'équipe en charge de la sécurité et éventuellement mis en ligne, avec ou sans modification.

La Référence du développeur contient les instructions complètes sur la démarche à suivre.

Q. : Je possède un correctif, puis-je le mettre en ligne dans proposed-updates ?

R. : Techniquement parlant, vous pouvez. Cependant, vous ne devriez pas. En effet, cela interfère de façon néfaste avec le travail de l'équipe en charge de la sécurité. Les paquets situés dans security.debian.org seront automatiquement copiés dans proposed-updates. Si un paquet avec un numéro de version identique ou supérieur est d'ores et déjà installé dans l'archive, la mise à jour de sécurité sera rejetée par le système d'archive. En définitive, la distribution stable se retrouvera dépourvue de la mise à jour de sécurité, à moins que les mauvais paquets du répertoire proposed-updates ne soient rejetés. Veuillez prendre contact avec l'équipe en charge de la sécurité, ajoutez tous les détails de la faille et joignez les fichiers source (c'est-à-dire les fichiers diff.gz et dsc) à votre courrier électronique.

La Référence du développeur contient les instructions complètes sur la démarche à suivre.

Q. : Je suis presque persuadé que mes paquets sont correctement construits, comment puis-je les mettre en ligne ?

R. : Si vous êtes certain de ne pas avoir cassé quoi que ce soit, que le numéro de version est le bon (c'est-à-dire supérieur à celui de la version qui se trouve dans stable et inférieur à celui qui se trouve dans testing et unstable), que vous n'avez pas modifié le comportement du paquet, et que vous avez pallié le problème de sécurité, que vous l'avez compilé pour la bonne distribution (qui est oldstable-security ou stable-security), que le paquet contient les sources originales si le paquet est nouveau sur security.debian.org, que vous pouvez confirmer que le correctif pour la plus récente version est propre et ne concerne que le problème de sécurité dont il est question (vérifiez-le avec la commande interdiff -z et également les fichiers .diff.gz), que vous avez relu la rustine au moins trois fois, et que debdiff n'affiche aucun changement, vous pouvez mettre en ligne les fichiers dans le répertoire incoming ftp://ftp.security.upload.debian.org/pub/SecurityUploadQueue qui se trouve sur security.debian.org directement. Veillez également à notifier à l'équipe en charge de la sécurité sur [email protected] tous les détails et liens.

Q. : Comment puis-je fournir de l'aide sur la sécurité ?

R. : S'il vous plaît, réexaminez chaque problème avant de le signaler. Si vous en avez la possibilité, fournissez des correctifs, ce qui accélérera le processus. Ne renvoyez pas simplement des messages en provenance du bugtraq, car nous les recevons déjà — mais fournissez-nous des informations complémentaires à celles fournies par bugtraq.

Une bonne façon de commencer à contribuer est d'apporter votre aide sur le « Debian Security Tracker » en suivant les instructions.

Q. : Quel est le contenu de « proposed-updates » ?

R. : Ce répertoire contient les paquets qui ont été proposés dans le but d'être incorporés dans la prochaine version stable de Debian. Chaque fois que des paquets sont envoyés par des responsables pour la version stable, ils atterrissent dans ce répertoire. Comme la distribution « stable » est supposée être stable, aucune mise à jour automatique n'est réalisée. De même, lorsque l'équipe chargée de la sécurité met à disposition les paquets mentionnés dans ses bulletins d'alerte pour les incorporer dans stable, ils sont placés en premier lieu dans « proposed-updates ». Tous les deux mois, les responsables de la version stable vérifient la liste des paquets de « proposed-updates » et décident si un paquet est approprié ou non pour stable. Ces modifications sont rassemblées dans une nouvelle version (revision) de « stable » (par exemple 2.2r3 ou 2.2r4). Les paquets qui ne correspondent pas seront probablement rejetés et seront aussi retirés de proposed-updates.

Veuillez noter que les paquets mis en ligne par les responsables de paquets (et non par l'équipe en charge de la sécurité) dans le répertoire proposed-updates ne sont pas maintenus par l'équipe en charge de la sécurité.

Q. : De quelle façon est constituée l'équipe chargée de la sécurité ?

R. : L'équipe en charge de la sécurité comporte plusieurs membres et assistants. L'équipe chargée de la sécurité nomme elle-même ses membres.

Q. : Pendant combien de temps les mises à jour de sécurité seront-elles fournies ?

R. : L'équipe en charge de la sécurité prend en charge la distribution stable pendant trois années après sa publication. Il n'est pas possible de prendre en charge trois distributions, c'est déjà bien assez difficile avec deux.

Q. : Comment puis-je contrôler l'intégrité des paquets ?

R. : Ce processus consiste à contrôler la signature du fichier Release à l'aide de la clef publique utilisée pour l'archive. Le fichier Release contient les sommes de contrôle des fichiers Packages et Sources qui contiennent respectivement les sommes de contrôle des paquets binaires et des paquets source. Des instructions détaillées sur la façon de contrôler l'intégrité des paquets peuvent être obtenues dans le manuel de sécurisation Debian.

Q. : Que faire si un paquet est cassé suite à une mise à jour de sécurité ?

R. : Premièrement, vous devez essayer de comprendre pourquoi le paquet est défaillant et comment il interagit avec la mise à jour de sécurité. Ensuite, prenez contact avec l'équipe en charge de la sécurité s'il s'agit de quelque chose de sérieux ou bien avec le responsable de la distribution stable s'il s'agit de quelque chose de moins grave. Nous parlons ici de paquets quelconques qui cessent de fonctionner après une mise à jour de sécurité d'un autre paquet. Si vous ne parvenez pas à identifier la cause du problème, mais que vous connaissez le correctif, parlez-en également à l'équipe en charge de la sécurité. Il est toutefois possible qu'on vous renvoie vers le responsable de la distribution stable.

Q. : Qu’est-ce qu’un identifiant CVE ?

R. : Le projet Common Vulnerabilities and Exposures (CVE) assigne des noms uniques, appelés identifiants CVE, pour les vulnérabilités spécifiques à la sécurité, afin de faciliter la référence unique à un problème spécifique. Des renseignements supplémentaires sont disponibles sur Wikipédia.

Q. : Est-ce que Debian réalise une annonce de sécurité (DSA) pour chaque identifiant CVE ?

R. : L’équipe de sécurité Debian suit tous les identifiants CVE publiés, les connecte aux paquets Debian correspondants et évalue leur impact dans le contexte de Debian — le fait qu’un identifiant CVE soit attribué n’implique pas forcément que le problème représente une menace sévère pour un système Debian. Ces renseignements sont suivis dans le Debian Security Tracker et une annonce de sécurité Debian sera envoyée pour les problèmes considérés sérieux.

Les problèmes ayant un faible impact pour lesquels aucune DSA ne sera publiée peuvent être corrigés dans la publication de Debian suivante, lors d’une mise à jour intermédiaire des distributions stable ou oldstable actuelles. Un correctif pour ces problèmes peut aussi être inclus dans une DSA publiée pour une vulnérabilité plus sérieuse.

Q. : Debian peut-elle assigner des identifiants CVE ?

R. : Debian est une autorité de numération CVE et peut assigner des identifiants CVE, mais conformément à la politique de CVE, uniquement pour des problèmes non encore publics. Si vous avez une vulnérabilité de sécurité non publique pour un logiciel dans Debian et que vous voudriez obtenir un identifiant pour ce problème, contactez l’équipe de sécurité Debian. Dans le cas où la vulnérabilité est déjà publique, veuillez suivre la procédure détaillée dans le CVE OpenSource Request HOWTO.

Q. : Est-ce que Debian a une politique de divulgation de vulnérabilité ?

R.: Debian a publié sa politique de divulgation de vulnérabilité dans le cadre de sa participation au programme CVE.

Q. : Notre politique de gestion de vulnérabilités a montré que les problèmes suivants sont à résoudre (liste de CVE avec des évaluations variables). Quand cela sera-t’il réglé ?

A : Debian ne fournit pas d’évaluations CVSS et n’utilise pas les évaluations de sources externes pour prioritiser les problèmes de sécurité.

Vous pouvez connaitre l’état de chaque identifiant de CVE particulier dans le Debian Security Tracker en fournissant son identifiant.

Une section Notes contiendra des informations supplémentaires, par exemple, un problème de sécurité ne mérite pas une mise à jour de sécurité dans Debian, mais pourrait être corrigé dans une publication intermédiaire à venir.

Les paquets pour lesquels une mise à jour de sécurité est prévue est disponible dans la liste nécessitant une DSA.

Si vous trouvez une erreur dans cette liste, merci de bien vouloir le faire connaitre. L’équipe de sécurité de Debian généralement ne répondra pas aux demandes d’informations supplémentaires, vous devrez plutôt contacter votre fournisseur d’outil de gestion de vulnérabilité, après tout ce sont les seuls qui vous alertent sur les problèmes de sécurité, mais pas Debian.

FAQ obsolète de l'équipe Debian sur la sécurité

Q. : Que signifie local (remote) ?

Le champ Type de problème dans les courriels DSA n’est plus utilisé depuis avril 2014.
R. : Certaines annonces couvrent des vulnérabilités qui ne peuvent pas être classées suivant la distinction habituelle d'une exploitation locale ou distante. Certaines vulnérabilités ne peuvent pas être exploitées à distance, c'est-à-dire sans démon à l'écoute d'un port réseau. Si elles peuvent être exploitées avec des fichiers spéciaux issus du réseau alors que le service vulnérable n'est pas connecté de manière permanente au réseau, nous écrivons alors local (remote).

Ce genre de vulnérabilité est en quelque sorte en partie local et distant, et concerne souvent des fichiers disponibles par le réseau, comme les pièces jointes des courriers électroniques, ou depuis une page de téléchargement.