Die Sicherheit von Ubuntu (Quality is a myth)

Ein Leser fragt an: [Update]

Ist die Downloadprozedur von Ubuntu-ISO-Images sicher gegen MITM-Aangriffe?

Hallo, Herr Danisch,

mal ein Kryptographieproblem, speziell zu asymmetrischer Verschlüsselung mit gpg und noch spezieller über die Sicherheit von aus dem Internet heruntergeladenen ISO-Images zur Installation von Ubuntu:

Es gibt dazu ein Tutorial bei https://ubuntu.com/tutorials/how-to-verify-ubuntu#1-overview und den damit verlinkte Folgeseiten.

Der Ubuntu-Spiegelserver http://ftp.uni-kl.de/pub/linux/ubuntu-dvd/xubuntu/releases/24.04/release/ funktioniert noch mit http statt https. Im genannten Tutorial steht, das macht nichts.

Auf dem Spiegelserver findet man noch die Datei SHA256SUMS, die für jedes dort angebotene Image deren sha256-Summe nennt und SHA256SUMS.gpg. Darin ist der mit dem privaten Schlüssel von Canonical erzeugte Hashwert von SHA256SUMS:

a@w:~/Downloads$ cat SHA256SUMS
8c47b15c4089473bcc58e369a472cabf83d137c7bf8ad7d9465ad086e7bd5272 *xubuntu-24.04-desktop-amd64.iso
09a80f22051ca998954a8df5a43c21897d0c2a3dccb0955e8bc2423725c98612 *xubuntu-24.04-minimal-amd64.iso
a@w:~/Downloads$ cat SHA256SUMS.gpg
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEhDk43yKNIvezdCvA2Uqj8O/iEJIFAmYqTb0ACgkQ2Uqj8O/i
EJJm1Q/7BE6J/HM3i0mviS7JB1ZpVwoYvZ5YRDk9gr7xskBt6LtiosAkeokQHZYV
mNO5c3zDxpYPhRHcOesY3WWDX2CxadMyVEtpOlRRGPBR7SKmi6EWpSmib+N9KkYH
PoegIqWFwDWoirUzIqQ4+kiL8ectKwb7IWIUYtB+NnkxeBO6pMlojDabd6T1PvtQ
El3+bIZxwz4eUcK6k4lrDCrSex8PktQy9ptncwFGmZ27UD+91smCbau3Nxm1x2r2
7+I8vRQEpFQpwHoUXyYWrvMUm4Qd5Hr9TvufOWjo7qWyEsGPL0VIfJ4Qsy6K3hZ6
WbGq+OjvjfJEdDFpbMLrLGcbM3jYq5p6puBdYfNtgLZ25gB8hnyfCrKqkytfAvYf
/czovolQ/7CURJCaDpt6DvnnjorTj+dnWxPcaquXegU7CqJ5vaPX93oLbGbhlgFU
SNA4/HfqM5Jwh0QmSZ0peWzcX4A4ggxH9NTOewSMTRocWFutfdoyOMgkE12kLTHV
Liui8ST8sKZa5ty8v8pBFBoqYENfS3zkzm5Vu8VWsx2Nl5LI+SJEQBYHmA9XdmTO
XMutDh+tezwDadOuqnQ/4GhDOkl3qJi+adbw2qlLmyRxi3FRzdxPHEjYhwfr0ND6
giduIxfCvSGvOsVgtXBJVrMZjiSlypWmLoCgnHZI03Wo/flOg1Q=
=L2ZE
-----END PGP SIGNATURE-----
a@w:~/Downloads$

Mit dem öffentlichen Schlüssel von Canonical soll man SHA256SUMS.gpg überprüfen. Wenn man den noch nicht hat, soll man aus SHA256SUMS.gpg dessen key-ID so auslesen und SHA256SUMS zugleich verifizieren:

a@w:~/Downloads$ gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS
gpg: enabled debug flags: memstat
gpg: Signatur vom Do 25 Apr 2024 14:34:05 CEST
gpg: mittels RSA-Schlüssel 843938DF228D22F7B3742BC0D94AA3F0EFE21092
gpg: Korrekte Signatur von "Ubuntu CD Image Automatic Signing Key (2012) " [unbekannt]
gpg: WARNUNG: Dieser Schlüssel trägt keine vertrauenswürdige Signatur!
gpg: Es gibt keinen Hinweis, daß die Signatur wirklich dem vorgeblichen Besitzer gehört.
Haupt-Fingerabdruck = 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092
gpg: keydb: handles=3 locks=0 parse=0 get=3
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=3 not=0 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=3 cached=3 good=3 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/65536 bytes in 0 blocks
a@w:~/Downloads$

Wenn einem dabei der öffentliche Schlüssel von Canonical fehlt, soll man ihn mit Hilfe der Schlüssel-ID so bekommen:

gpg --keyid-format long --keyserver hkp://keyserver.ubuntu.com --recv-keys 0x843938DF228D22F7B3742BC0D94AA3F0EFE21092

Schließlich soll man sein heruntergeladenes ISO-Image so prüfen:

a@w:~/Downloads$ sha256sum -c SHA256SUMS 2>&1 | grep OK
xubuntu-24.04-desktop-amd64.iso: OK
a@w:~/Downloads$

Wenn ein Angreifer ISO-Images auf einem Spiegelserver manipuliert und die beiden SHA256SUMS-Dateien für das manipulierte ISO Image passend ebenfalls, dann fehlt ihm eigentlich nur der private Schlüssel von Canonical. Er könnte sich aber selbst ein Schlüsselpaar erzeugen, das angeblich gehört und den gpg-Hashwert von SHA256SUMS mit dem gefälschten privaten Schlüssel signieren.

Wenn sich der Angreifer sich danach in die Abfrage bei Canonical klemmt und den da gelieferten öffentlichen Schlüssel einfach gegen seinem gefälschten öffentlichen angeblich-Canonical-Schlüssel austauscht, kann der Downloader die Manipulation nicht mehr feststellen.

Mir fehlt in der ganzen Prozedur die Überprüfung des Fingerprints auf einem unabhängigen Weg, in den sich MITM nicht einklinken kann.

In man gpg heißt es übrigens:

–keyserver name
This option is deprecated – please use the –keyserver in ‘dirmngr.conf’ instead.

Use name as your keyserver. This is the server that –receive-keys, –send-keys, and –search-keys will communi‐
cate with to receive keys from, send keys to, and search for keys on. The format of the name is a URI:
`scheme:[//]keyservername[:port]’ The scheme is the type of keyserver: “hkp” for the HTTP (or compatible) key‐
servers, “ldap” for the LDAP keyservers, or “mailto” for the Graff email keyserver. Note that your particular in‐
stallation of GnuPG may have other keyserver types available as well. Keyserver schemes are case-insensitive. Af‐
ter the keyserver name, optional keyserver configuration options may be provided. These are the same as the global
–keyserver-options from below, but apply only to this particular keyserver.

Most keyservers synchronize with each other, so there is generally no need to send keys to more than one server.
The keyserver hkp://keys.gnupg.net uses round robin DNS to give a different keyserver each time you use it.

Was meinen Sie dazu?

Das hat der Leser richtig erkannt. Erschwerend kommt hinzu, dass die gpg-Schlüssel auch nicht fremdsigniert sind.

Genau in diesem Zusammenhang hatte ich vor einiger Zeit mal einen Bug bei Ubuntu aufgemacht, eben weil die https-Zertifikate der Server fehlerhaft sind. Eben weil die da murksen, wollte ich die Images per https runterladen.

Dabei tritt aber folgendes Problem auf: Man soll die Images nicht von cdimages.ubuntu.com laden, sondern von der Länderversion mit vorangestelltem Länderkürzel, also etwa de.cdimages.ubuntu.com, damit man sich nicht mehr darum scheren muss, wer die Landesspiegel sind, sondern man dann einfach eine Liste von A und AAAA-Records bekommt, die direkt auf die Länderspiegel zeigen.

Das funktionierte aber nicht, und anscheinend auch heute noch nicht, und man sollte unter https://de.cdimages.ubuntu.com/ eigentlich auch eine Fehlermeldung des Browsers bekommen. Weil nämlich diese Server exakte Kopien des Hauptservers sind, und deshalb auch eine Kopie von dessen TLS-Zertifikat haben. Was an sich schon ein Unding ist, das Zertifikat auf Server Dritter weltweit umzuverteilen. Das Zertifikat enhält aber nur die Hostnamen cdimage.ubuntu.com und cdimages.ubuntu.com, aber nicht die Länderhostnamen, obwohl man beispielsweise auch auf *.cdimages.ubuntu.com hätte umstellen können. Und damit ist das Zertifikat für diese Ländernamen nicht gültig, weshalb sich der Browser beschweren sollte.

Schon das haben sie aber nicht kapiert. Und auch nicht geändert. Da sind selbst in sicherheitskritischen Bereichen heute eine Menge Leute unterwegs, die nicht verstehen, was sie tun. Davon abgesehen habe ich auch den Eindruck, dass sich Ubuntu übernommen hat, und schlicht die Manpower nicht mehr hat, um alle ihre Sonderlocken zu pflegen und entwickeln.

Ich kann deshalb nur empfehlen, zumindest die SHA256SUM-Dateien von https://cdimages.ubuntu.com (ohne Länderkürzel) zu ziehen. Auch wenn das Zertifikat auf x Server weltweit verteilt ist.

Noch eins

Das ist nicht deren einziges Problem.

Wenn man auf die Webseite https://ask.ubuntu.com geht, wo man Fragen stellen kann, muss man sich zunächst irgendwie authentifizieren. Am naheliegensten über die Ubuntu-eigene Authentifikationslösung launchpad.net.

Früher ging das bei mir. Vor – weiß nicht mehr genau – ein, zwei Jahren ging das bei mir plötzlich nicht mehr, konnte ich mich da nicht mehr einloggen. Es war aber nicht so, dass mein launchpad.net-Account gesperrt oder mein Passwort falsch war, denn auf anderen Seiten, wie etwa der Bugreport-Seite, konnte ich mich damit völlig problemlos anmelden. Irgendwas muss da im LDAP oder sonstwo in der Datenbank durcheinander geraten sein. Ich habe über Wochen niemanden gefunden, der überhaupt in der Lage war, das Problem, die Fehlermeldung zu verstehen, geschweige denn zu verstehen.

Bei Ubuntu selbst kam ich nur auf Leute mit Callcenter-Abwimmel-Attitüte, die gar nichts verstanden.

Dann hieß es, das sich Bugs bezüglich ask.ubuntu.com nur auf ask.ubuntu.com selbst melden könne, was ja aber nicht ging, weil ich mich ja nicht einloggen konnte. Und als ich einen zweiten Account mit fremder Authentifikation dort aufmachte, bekam ich auch keine Antwort mehr.

Ubuntu ist so tolerant, dass die da anscheinend nur noch im OS-Team selbst, aber nicht mehr beim dem Drumherumvolk, das die Webseiten betreibt, Security-Sachkunde haben.

Das ist heute so. Quality is a myth und IT-Security war gestern.

Update:

Ich habe die Sache zum Anlass genommen, nochmal die Ubuntu-Leute anzuschreiben.

1. Zu http/https meinen sie, dass es doch reiche, dass man den Einstieg über https://ubuntu.com nehmen könne und von dort auf die Downloadseiten per https komme, die Downloads also gesichert sind. Dass aber die Seiten auch per http (ohne s) erreichbar sind und noch jede Menge http:// -URLs in Umlauf sind, oder sie sogar ihre Mirrors wie ftp.uni-kl.de selbst noch als aktuell mit Links wie http:// und ftp:// angeben, oder dass die Downloadseiten mit dem Länderprefix wie de. kein gültiges Zertifikat haben, interessiert sie anscheinend nicht.
2. Zu PGP meinen sie, dass es doch ausreicht und sicher ist, dass man den Fingerprint über https://ubuntu.com sicher holen könne, was die Sicherheit gewährleistet, konnten aber nicht mal selbst genau angeben, wo der da stehen soll, und auch per google-suche wie “fingerprint site:ubuntu.com” und ähnliches habe ich den nicht gefunden.

   Tatsächlich steht der Fingerprint im schon erwähnten Tutorial ganz unten auf Seite 4, aber so schwammig formuliert, dass jemand, der sich nicht fortgeschritten mit PGP auskennt, das nicht nur nicht nachvollziehen kann, sondern auch nicht merkt, dass die Ausgabe nicht nur im Prinzip und optisch so aussehen soll, sondern das er tatsächlich die Hex-Strings exakt prüfen muss.

   Wie man von den Download-Seiten dorthin kommen soll, ist nicht ersichtlich.

   Und selbst wenn die Download-Seiten einen Link enthielten: Solange die Downloads per http:// erreichbar sind und sogar offiziell angeboten und für sicher erklärt werden, könnte jemand, der es schafft, sie zu fälschen und manipulierte Images unterzujubeln, natürlich auch den Link zum Tutorial fälschen und dort eine Kopie des Tutorials mit dem Fake-Fingerprint anbieten.

   Das ist eigentlich ein bekanntes Phänomen, dass man von http-Seiten nicht sicher auf https-Seiten verweisen und damit keinen Sicherheitsgewinn erreichen kann, weil ja schon der Link von der http-Seite nicht verlässlich ist.

Und wie ich das hier so schreibe, fällt mir noch ein Angriffsvektor auf.

Sie beschreiben auf Seite 4 ihres Tutorials, zwar schlecht und missverständlich, aber immerhin, wie man den Fingerprint des Ubuntu-Schlüssels prüft.

Auf Seite fünf beschreiben sie dann, wie man die Prüfsummendatei prüft:

gpg --keyid-format long --verify SHA256SUMS.gpg SHA256SUMS

und dazu

This time the command should return something like this:

„something like this“ …

Das heißt, dass man zwar den Ubuntu-Key mit dem Fingerprint verifiziert, wenn man es tatsächlich so weit schafft, dieses Tutorial in allen Tiefen nachzumachen, aber es steht nicht da, dass die Datei auch mit genau diesem Ubuntu-Schlüssel signiert sein müsse. Sie könnte auch mit einem anderen Schlüssel gleicher Namensangabe signiert sein, der dem Opfer irgendwie untergejubelt wurde. Das würde dann auch wie „something like this“ aussehen.

Es steht nicht da, dass man auch hier wieder den Fingerprint prüfen oder gleich im Befehl den Schlüssel angeben müsste.

Wer sich nicht mindestens gut auskennt, würde das nicht merken, dass das mit einem anderen Schlüssel signiert wurde, selbst wenn er vorher die Verifikation von Seite 4 durchgeführt hat.