Woher weiß ich, dass meine Systemupdates vertrauenswürdig sind?


7

Ich aktualisiere mein System regelmäßig, wenn ich über Software-Updates informiert werde. Dies ist eines der Dinge, denen ich einfach vertraue, ohne die Details zu kennen, aber ich bin in letzter Zeit neugierig geworden: Woher weiß ich das?

  • Bei der Überprüfung auf Aktualisierungen werden nur legitime Aktualisierungen angezeigt.
  • Die Updates, die ich erhalte und installiere, sind nicht böswillig?

Ich weiß, dass ich eine Reihe von Softwarequellen habe, die ich selbst per URL spezifiziere, und dass es meine Entscheidung ist, ob ich diesen Quellen vertraue. Aber was passiert, wenn ich diese URLs angegeben habe?

Nach dem, was heutzutage üblich ist, würde ich vermuten, dass die Authentizität dieser Quellen mit etwas in der Art von HTTPS / SSL überprüft wird, dh ich habe einige Zertifikate, die gegen eine Autorität überprüft wurden, was bedeutet, dass ich irgendwo zuverlässige Stammzertifikate installieren muss ( wahrscheinlich kommen sie mit dem System).

Außerdem sind die Pakete kryptografisch signiert, wie bei GPG oder ähnlichem.

Sind diese Annahmen richtig? Wo kann ich die verwendeten Schlüssel / Zertifikate überprüfen? Wie kann ich überprüfen, ob sie die richtigen sind? Wie kann ich überprüfen, ob sie tatsächlich verwendet werden? Gibt es Konfigurationsoptionen, die den Prozess mehr oder weniger umsichtig machen, und welche Standardeinstellungen gelten? Gibt es bekannte Angriffe oder gab es in letzter Zeit Schwachstellen? Ich erinnere mich an Windows, das vor nicht allzu langer Zeit ein solches Problem hatte.

Ich bin am 12.04, aber ich gehe davon aus, dass dies allgemeiner beantwortet werden kann.

Antworten:


3

Das ist eine gute Frage. Die Antwort ist (natürlich) ziemlich komplex, aber lassen Sie mich versuchen, sie für Sie aufzuschlüsseln. Schauen wir uns zunächst die technischen Prozesse an:

Die Vertrauenskette

Wir verwenden kein SSL, um APT zu sichern, wir verwenden kryptografische Hashes (heutzutage SHA256) und OpenPGP-Signaturen. Auf diese Weise können Sie nicht vertrauenswürdigen Spiegeln vertrauen und müssen der CA-PKI nicht vertrauen.

Wenn Sie APTs ein Repository hinzufügen sources.list, müssen Sie mit dem apt-keyBefehl auch den PGP-Schlüssel zum vertrauenswürdigen Schlüsselring von APT hinzufügen . Der Schlüsselring enthält die Schlüssel für die Ubuntu-Repositorys. Wenn Sie den apt-add-repositoryBefehl zum Hinzufügen eines PPA verwenden, wird der Schlüssel (von Launchpad über SSL bezogen) für Sie hinzugefügt.

Die Vertrauenskette ist:

  1. Jeder sources.listEintrag verweist APT auf eine ReleaseDatei im Repository mit einer Release.gpgSignatur (oder sie können als InReleaseDatei kombiniert werden). Diese Datei beschreibt das Repository und muss mit einem Schlüssel im Schlüsselbund Ihres APT signiert sein.
  2. Die ReleaseDatei enthält kryptografische Hashes aller Packagesund Sources-Dateien. Diese listen alle im Repository verfügbaren Pakete und Versionen auf.
  3. Die Packagesund Sources-Dateien enthalten die kryptografischen Hashes jedes Pakets.
  4. Die Pakete selbst sind nicht signiert. Es ist unnötig, es gibt eine Vertrauenskette aus der Release-Datei, die vom Spiegel signiert wurde. Die Quellpakete, die zum Erstellen der Binärpakete verwendet werden, sind jedoch vom Entwickler, der sie hochgeladen hat, PGP-signiert.

Weitere Informationen zum Repository-Format finden Sie im Debian-Wiki .

Diese Kette bedeutet, dass wir keinen Zwischenspiegeln vertrauen müssen. Wir können darauf vertrauen, dass das von uns installierte Paket mit dem identisch ist, das zum Zeitpunkt der Signatur der Release-Datei vorhanden war.

Sie können den Schlüsselring von APT durch Ausführen überprüfen sudo apt-key finger.

Überprüfen der Archivschlüssel von Ubuntu

Woher weißt du, was da sein soll? Wenn Sie Ihrem Computer nicht vertrauen, können Sie keinem Programm darauf vertrauen, dass es Sie nicht anlügt (z. B. apt-key), und diese Übung ist zwecklos. Nehmen wir also an, dies ist nur aus akademischem Interesse und überprüfen Sie den Inhalt des Schlüsselbunds aus dem endgültigen Quellpaket, das vom Entwickler, der es hochgeladen hat, mit PGP signiert ist.

Laden Sie das ubuntu-keyringQuellpaket herunter und sehen Sie, was dort sein sollte:

$ 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 <cjwatson@chiark.greenend.org.uk>"
gpg:                 aka "Colin Watson <cjwatson@debian.org>"
gpg:                 aka "Colin Watson <cjwatson@ubuntu.com>"
gpg:                 aka "Colin Watson <cjwatson@canonical.com>"
$ 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 <ftpmaster@ubuntu.com>
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 <cdimage@ubuntu.com>

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) <ftpmaster@ubuntu.com>

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) <cdimage@ubuntu.com>

Ich weiß, dass dies tatsächlich Colin Watsons Unterschrift ist, da ich ihn mehrmals getroffen habe und wir die Identität des anderen überprüft und die Schlüssel des anderen unterschrieben haben. Wenn Sie einen Schlüssel in der PGP-Gruppe haben, sollten Sie in der Lage sein, einen Vertrauenspfad zu ihm zu finden. Ich weiß auch, dass ich ihm vertrauen kann, dass er das richtige ubuntu-keyringPaket hochlädt.

Für Debian gibt es ein Paket ( debian-keyring), das die PGP-Schlüssel aller Debian-Entwickler enthält, und Sie können dies verwenden, um die Signaturen des Quellpakets zu überprüfen. Ubuntu hat kein Äquivalent, aber viele Ubuntu-Entwickler sind auch Debian-Entwickler, und alle PGP-Schlüssel unserer Entwickler sind in ihren Profilen im Launchpad verfügbar.

Die anderen Fragen

Woher weiß ich, dass Updates nicht bösartig sind?

Es kommt darauf an zu vertrauen. Sie müssen jedem von Ihnen verwendeten Repository voll vertrauen. Sie erteilen den Betreuern jedes Repositorys die Berechtigung, Dinge als Root auf Ihrem Computer auszuführen.

Ubuntu-Pakete können nur von Ubuntu-Entwicklern hochgeladen werden, denen vom Developer Membership Board (dem ich derzeit diene) Upload-Rechte gewährt wurden . Um Upload-Rechte zu beantragen, müssen Sie von mehreren vorhandenen Ubuntu-Entwicklern unterstützt werden, die mit Ihnen zusammengearbeitet haben und darauf vertrauen, dass Sie selbstständig arbeiten können. Ohne Upload-Rechte müssen Uploads von Entwicklern gesponsert werden, die über die Rechte verfügen (einschließlich der Überprüfung des Uploads).

Für Updates nach der Veröffentlichung hat Ubuntu strenge Richtlinien bezüglich des Inhalts von Updates. Sie sollten nur minimale Patches enthalten, um bekannte Fehler zu beheben. Die Patches werden von Mitgliedern der SRU / Sicherheitsteams überprüft, bevor sie akzeptiert werden.

Offensichtlich haben PPAs und Repositorys von Drittanbietern nicht alle diese Einschränkungen. Sie müssen den PPA-Besitzern vertrauen, um vernünftig zu sein.

Alle Ubuntu & PPA-Pakete verfügen über die verfügbare Quelle, sodass sie von jedem überprüft werden können.

Gibt es Konfigurationsoptionen, die den Prozess mehr oder weniger umsichtig machen, und welche Standardeinstellungen gelten?

Sie können die Signaturüberprüfung in APT deaktivieren, diese ist jedoch standardmäßig aktiviert. Wenn Sie versuchen, etwas aus einem nicht signierten / nicht vertrauenswürdigen Repository zu installieren, bestätigen Sie mit apt, dass Sie dies wirklich tun möchten.

Gibt es bekannte Angriffe oder gab es in letzter Zeit Schwachstellen?

Ich erinnere mich an einen, Debian-Fehler 499897 . Debian umgeht dies, indem es Release-Dateien ein Ablaufdatum gibt, nach dem ihnen nicht mehr vertraut werden kann. Ubuntu unterstützt dies noch nicht .


4

Es gibt kein mir bekanntes SSL / https und keine Zertifizierungsstelle außerhalb Ihres eigenen Computers.

Um nach Updates zu suchen, kontaktiert Ihr Computer die Server, die Sie als Quellen festgelegt haben. Es wird eine Indexdatei von diesen Servern unter Verwendung von normalem http heruntergeladen. Diese Indexdateien sind signiert, sodass Ihnen niemand einen falschen Index geben kann. Die richtige Datei kann jedoch von jedem Computer aus bereitgestellt werden, sodass die Verwendung von Spiegeln einfach ist.

Anhand dieses Index berechnet Ihr eigener Computer, welche neuen Pakete heruntergeladen werden müssen. Auch diese Pakete werden mit normalem http abgerufen. Eine MD5-Summe jedes Pakets wird mit der Release-Datei überprüft. Darüber hinaus sind auch offizielle Ubuntu-Repositorys-Pakete signiert. Einige Quellen von Drittanbietern haben möglicherweise nicht signierte Pakete (aber die md5-Prüfung wird weiterhin verwendet). In diesem Fall werden Sie vom Installationsprogramm (apt, Ubuntu Software Center, ...) gewarnt.

Zusammenfassend ist die Sicherheit nicht in den Servern oder in den Verbindungen, sondern in den Paketen selbst. Ein Angreifer, der in einen Update-Server eindringt, kann Ihren Computer nicht beschädigen, aber jemand, der eine gültige Signatur erhalten kann, kann dies.

Weitere Details finden Sie in einer Erklärung zu Secure Apt hier . Zusammenfassend: Alle Pakete haben eine GPG-Signatur und apt vertraut denen, die von Personen ausgestellt wurden, deren öffentlicher Schlüssel sich im apt-Schlüsselbund befindet ( /etc/apt/trusted.gpg)


1
Kleinere Details: Einzelne Pakete werden nicht signiert, stattdessen wird eine Prüfsumme über ihren Inhalt berechnet (es wird angezeigt, dass sowohl SHA als auch MD5 verwendet werden), und diese Prüfsummen befinden sich in der signierten Indexdatei. Der praktische Vorteil davon ist, dass es weniger zufällige Sammlungen von fast funktionierenden Paketen gibt, als es für RPM gibt.
Taneli

Offizielle Ubuntu-Repositories erfordern, dass die Pakete signiert sind und die MD5-Summe mit der De-Release-Datei verglichen wird. Siehe wiki.ubuntu.com/PackagingGuide/Complete . Es ist möglich, nicht signierte Pakete in einem Repository zu haben, diese zeigen jedoch normalerweise während der Installation eine Warnung an. Ich werde eine Bearbeitung vornehmen.
Javier Rivera

0

Verwandte Antwort: Abgesehen von der Überprüfung der Paketsignaturen auf Authentizität können Sie noch einen Schritt weiter gehen und sicherstellen, dass die Systeme mit der Funktion für den Compliance-Bericht von Landscape auf dem neuesten Stand der geltenden Sicherheitspatches sind.

Es ist ein vor Ort aktualisiertes Kreisdiagramm, das Ihnen zeigt, wie viele und welche Systeme noch anfällig sind. Dies ist wahrscheinlich ein Overkill für eine einzelne Person, aber es ist eine FAQ für große Unternehmen und kleine Unternehmen.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.