web-dev-qa-db-fra.com

Comment savoir si les mises à jour de mon système sont fiables?

Je mets régulièrement à jour mon système chaque fois qu'il m'informe des mises à jour logicielles. C'est l'une de ces choses auxquelles je fais confiance pour travailler sans en connaître les détails, mais je suis récemment devenu curieux: comment savoir

  • le processus de vérification des mises à jour n'affichera que les mises à jour légitimes?
  • les mises à jour que je reçois et installe ne sont pas malveillantes?

Je sais que j'ai un ensemble de sources logicielles que je spécifie moi-même par URL et que si je fais confiance à ces sources, c'est ma décision. Mais que se passe-t-il une fois que j'ai spécifié ces URL?

D'après ce qui est courant ces jours-ci, je soupçonne que l'authenticité de ces sources est vérifiée avec quelque chose comme HTTPS/SSL, i. e. J'ai certains certificats qui sont vérifiés par rapport à une certaine autorité, ce qui signifie que j'ai besoin de certificats racine fiables installés quelque part (ils viennent probablement avec le système).

De plus, je suppose que les packages sont signés cryptographiquement, comme avec GPG ou similaire.

Ces hypothèses sont-elles correctes? Où puis-je inspecter les clés/certificats utilisés? Comment puis-je vérifier si ce sont les bons? Comment puis-je vérifier qu'ils sont bien utilisés? Existe-t-il des options de configuration qui rendent le processus plus ou moins prudent et quelles sont leurs valeurs par défaut? Y a-t-il des attaques connues ou y a-t-il eu des vulnérabilités récemment? Je crois me souvenir que Windows a eu un problème comme ça il n'y a pas longtemps.

Je suis le 12.04, mais je suppose que cela peut être répondu de manière plus générale.

7
Hanno Fietz

C'est une excellente question. La réponse est (bien sûr) assez complexe, mais permettez-moi de l'essayer pour vous. Voyons d'abord les processus techniques:

La chaîne de confiance

Nous n'utilisons pas SSL pour sécuriser APT, nous utilisons des hachages cryptographiques (SHA256, de nos jours) et des signatures OpenPGP. Cela vous permet de faire confiance aux miroirs non approuvés et évite d'avoir à faire confiance à l'AC PKI.

Lorsque vous ajoutez un référentiel au sources.list D'APT, vous devez également ajouter sa clé PGP au trousseau de clés de confiance d'APT, avec la commande apt-key. Le trousseau de clés est livré avec les clés des référentiels d'Ubuntu incluses. Et lorsque vous utilisez la commande apt-add-repository Pour ajouter un PPA, il ajoute la clé (obtenue à partir de Launchpad sur SSL) pour vous.

La chaîne de confiance est:

  1. Chaque sources.list Points d'entrée APT vers un fichier Release dans le référentiel, avec une signature Release.gpg (Ou ils peuvent être combinés en tant que InRelease file). Ce fichier décrit le référentiel et doit être signé par une clé du trousseau de clés de votre APT.
  2. Le fichier Release contient des hachages cryptographiques de tous les fichiers Packages et Sources. Ceux-ci répertorient tous les packages et versions disponibles dans le référentiel.
  3. Les fichiers Packages et Sources contiennent les hachages cryptographiques de chaque package.
  4. Les packages eux-mêmes ne sont pas signés. C'est inutile, il y a une chaîne de confiance, depuis le fichier Release, signé par le miroir. Cependant, les packages source, utilisés pour construire les packages binaires sont signés PGP, par le développeur qui les a téléchargés.

Vous pouvez en savoir plus sur le format du référentiel sur le wiki Debian .

Cette chaîne signifie que nous n'avons pas à faire confiance à des miroirs intermédiaires, nous pouvons avoir confiance que le package que nous installons est identique à celui présent lors de la signature du fichier Release.

Vous pouvez inspecter le trousseau de clés d'APT en exécutant Sudo apt-key finger.

Vérification des clés d'archive d'Ubuntu

Comment savez-vous ce qui devrait être là? Si vous ne faites pas confiance à votre ordinateur, vous ne pouvez faire confiance à aucun programme sur celui-ci pour ne pas vous mentir (comme apt-key), Et cet exercice est futile. Supposons donc que cela ne soit pas d'intérêt académique et vérifions le contenu du trousseau de clés du package source définitif, qui est PGP signé par le développeur qui l'a téléchargé.

Téléchargez le package source ubuntu-keyring Et voyez ce qui devrait s'y trouver:

$ apt-get source ubuntu-keyring
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 20.0 kB of source archives.
Get:1 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (dsc) [1542 B]
Get:2 http://localhost/ubuntu/ quantal/main ubuntu-keyring 2012.05.19 (tar) [18.5 kB]
Fetched 20.0 kB in 0s (0 B/s)               
dpkg-source: info: extracting ubuntu-keyring in ubuntu-keyring-2012.05.19
dpkg-source: info: unpacking ubuntu-keyring_2012.05.19.tar.gz
$ gpg --verify ubuntu-keyring_2012.05.19.dsc
gpg: Signature made Sat May 19 03:33:12 2012 SAST
gpg:                using RSA key 0x393587D97D86500B
gpg: Good signature from "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
gpg:                 aka "Colin Watson <[email protected]>"
$ gpg --no-default-keyring --keyring ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg --fingerprint
ubuntu-keyring-2012.05.19/keyrings/ubuntu-archive-keyring.gpg
-------------------------------------------------------------
pub   1024D/0x40976EAF437D05B5 2004-09-12
      Key fingerprint = 6302 39CC 130E 1A7F D81A  27B1 4097 6EAF 437D 05B5
uid                            Ubuntu Archive Automatic Signing Key <[email protected]>
sub   2048g/0x251BEFF479164387 2004-09-12

pub   1024D/0x46181433FBB75451 2004-12-30
      Key fingerprint = C598 6B4F 1257 FFA8 6632  CBA7 4618 1433 FBB7 5451
uid                            Ubuntu CD Image Automatic Signing Key <[email protected]>

pub   4096R/0x3B4FE6ACC0B21F32 2012-05-11
      Key fingerprint = 790B C727 7767 219C 42C8  6F93 3B4F E6AC C0B2 1F32
uid                            Ubuntu Archive Automatic Signing Key (2012) <[email protected]>

pub   4096R/0xD94AA3F0EFE21092 2012-05-11
      Key fingerprint = 8439 38DF 228D 22F7 B374  2BC0 D94A A3F0 EFE2 1092
uid                            Ubuntu CD Image Automatic Signing Key (2012) <[email protected]>

Je sais que c'est en fait la signature de Colin Watson, car je l'ai rencontré plusieurs fois et nous avons vérifié l'identité de chacun et signé les clés de l'autre. Si vous avez une clé dans l'ensemble fort PGP, vous devriez pouvoir lui trouver un chemin de confiance. Je sais également que je peux lui faire confiance pour télécharger le bon package ubuntu-keyring.

Pour Debian, il y a un paquet (debian-keyring) Contenant les clés PGP de tous les développeurs Debian, et vous pouvez l'utiliser pour vérifier les signatures des paquets sources. Ubuntu n'a pas d'équivalent, mais de nombreux développeurs Ubuntu sont également des développeurs Debian, et toutes les clés PGP de nos développeurs sont disponibles sur leurs profils dans Launchpad.

Les autres questions

Comment savoir si les mises à jour ne sont pas malveillantes?

Cela revient à faire confiance. Vous devez faire entièrement confiance à chaque référentiel que vous utilisez. Vous donnez aux responsables de chaque référentiel l'autorisation d'exécuter des choses en tant que root sur votre machine.

Les packages Ubuntu ne peuvent être téléchargés que par les développeurs Ubuntu qui ont obtenu des droits de téléchargement par le Developer Membership Board (que je sers actuellement). Pour demander des droits de téléchargement, vous devez être recommandé par plusieurs développeurs Ubuntu existants qui ont travaillé avec vous et qui font confiance à vos capacités pour travailler par vous-même. Sans droits de téléchargement, les téléchargements doivent être parrainés par des développeurs qui en ont les droits (ce qui devrait inclure l'examen du téléchargement).

Pour les mises à jour post-version, Ubuntu a politiques strictes sur le contenu des mises à jour. Ils ne devraient contenir qu'un minimum de correctifs pour corriger les bogues connus. Les correctifs sont examinés par les membres des équipes SRU/Sécurité avant d'être acceptés.

De toute évidence, les PPA et les référentiels tiers n'ont pas toutes ces restrictions. Vous devez faire confiance aux propriétaires de PPA pour être sensé.

Tous les packages Ubuntu et PPA ont la source disponible, ils peuvent donc être inspectés par n'importe qui.

Existe-t-il des options de configuration qui rendent le processus plus ou moins prudent et quelles sont leurs valeurs par défaut?

Vous pouvez désactiver la vérification de signature dans APT, mais bien sûr, elle est activée par défaut. Lorsque vous essayez d'installer quelque chose à partir d'un référentiel non signé/non approuvé, apt vous fait confirmer que vous voulez vraiment le faire.

Y a-t-il des attaques connues ou y a-t-il eu des vulnérabilités récemment?

Je m'en souviens, bogue Debian 499897 . Debian contourne ce problème en donnant aux fichiers de versions une date d'expiration, après quoi ils ne peuvent pas leur faire confiance. Ubuntu ne le supporte pas encore .

3
tumbleweed

Il n'y a pas de SSL/https que je sache, et il n'y a pas d'autorité de certification en dehors de votre propre ordinateur.

Pour vérifier les mises à jour, votre ordinateur contacte les serveurs que vous avez désignés comme sources. Il téléchargera un fichier d'index à partir de ces serveurs en utilisant http normal. Ces fichiers d'index sont signés, donc personne ne peut vous donner un faux index, mais le fichier correct peut être servi depuis n'importe quel ordinateur, ce qui permet une utilisation facile des miroirs.

En utilisant cet index, votre propre ordinateur calculera les nouveaux packages à télécharger. Encore une fois, les packages seront récupérés à l'aide de http normal. Une somme md5 de chaque package sera vérifiée avec le fichier de version. De plus, les packages des dépôts officiels d'Ubuntu sont également signés. Certaines sources tierces peuvent avoir des packages non signés (mais la vérification md5 est toujours utilisée), lorsque cela se produit, le programme d'installation (apt, Ubuntu Software Center, ...) vous avertira.

Pour résumer, la sécurité n'est pas dans les serveurs ou dans les connexions, mais dans les packages eux-mêmes. Un attaquant pénétrant dans un serveur de mise à jour ne peut pas endommager votre ordinateur, mais quelqu'un qui peut obtenir une signature valide le peut.

Vous pouvez trouver plus de détails dans une explication de l'apt sécurisé ici . Pour résumer: tous les packages ont une signature GPG et font confiance à ceux qui ont été émis par les personnes dont la clé publique se trouve dans le trousseau apt (/etc/apt/trusted.gpg)

4
Javier Rivera

Réponse connexe: au-delà de la vérification de l'authenticité des signatures de package, vous pouvez aller plus loin et vérifier que les systèmes sont entièrement à jour avec les derniers correctifs de sécurité applicables avec la fonction de rapport de conformité de Landscape.

Il s'agit d'un camembert mis à jour sur place vous indiquant combien et quels systèmes sont encore vulnérables. C'est probablement exagéré pour une seule personne, mais c'est un FAQ pour les grandes entreprises et les petites entreprises.

0
0xF2