DrScott
Ehemalige
Anmeldungsdatum: 7. Juli 2005
Beiträge: 6018
Wohnort: Nürnberg
|
Bis gerade war ich auch noch auf dem Holzweg zu glauben, dass durch das Signieren von Paketen ein Angriff nicht möglich ist, wenn die Echtheit des Schlüssels sichergestellt ist. Bis gerade 😉 Auf /. gibt es bereits eine Diskussion http://it.slashdot.org/it/08/07/10/227220.shtml Hier wird auch das eigentliche Papier genannt ( http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html ) welches ich aber derzeit nicht abrufen kann. Im Grunde geht der Angriff so von statten (wie immer: System muß von außen erreichbar sein...): 1. Einen (ordentlichen!) Mirror anmelden und natürlich eine Zeitlang ordentlich betreiben um Nutzer zu erlangen. (Alternative: Fremdquellen, siehe weiter unten) 2. Bei einem sicherheitskritischen Bug (zb. sshd) das alte Paket als das neue ausgeben (Die alte Signatur bleibt gültig!) ⇒ Beim Versuch, das Update zu holen wird dem Angreifer bereits mitgeteilt, dass ein bestimmter Fehler vorliegt. Der Fehler bleibt weiterhin aktiv ⇒ In sekundenschnelle kann der Mirrorbetreiber etliche Opfer übernehmen. 2b. Der tatsächliche Bugfix wird herausgegeben. Es bleibt dennoch genügend Zeit, um das anfordernde System zu kapern. Hmm, im Prinzip hilft da wohl nur, Sicherheitsupdates nur von "Canonical" selbst zu akzeptieren. Oder zumindest von vertrauenswürdigen Opfern. Jemand, der Fremdquellen aktiviert hat, sollte schnellstens kalte Füße bekommen: Der Anbieter der Fremdquelle kann eine alte sshd-Version nehmen und als Update anbieten. Es findet also tatsächlich ein downgrade statt. Wenn ich die Kommentare richtig gelesen habe, so ist in der Signatur nicht die Versionsinformation enthalten, (jedenfalls nicht ausreichend genau).
|
Rorschach
Anmeldungsdatum: 22. Mai 2008
Beiträge: 786
|
Natürlich kann man sobald mein eine Paketquelle betreibt die Systeme der User kompromitieren. Also ich versteh nicht ganz worauf du hinaus willst ☺ ? Das von dir beschriebene Szenario scheint mir sogar übermässig kompliziert zu sein um das gewünschte Ziel zu erreichen. Wenn ich ne Paketquelle für ein Programm bereitstellen kann ich das jederzeit kompromitieren und als eine neue oder bugfix Version "verkaufen".
|
Red_Radish
Anmeldungsdatum: 7. September 2007
Beiträge: 770
|
Rorschach hat geschrieben: Wenn ich ne Paketquelle für ein Programm bereitstellen kann ich das jederzeit kompromitieren und als eine neue oder bugfix Version "verkaufen".
Klar - das sind dann aber deine eignen Pakete, signiert durch deinen eigenen GPG Schlüssel, den andere extra importieren müssen. Der von DrScott verlinkte Trick funktioniert dagegen mit Paketen, die von Ubuntu selbst signiert wurden. Das ist ein großer und wichtiger Unterschied. Man kann eine zeitlang Mirror spielen und irgendwann dann damit beginnen veraltet Pakete mit sicherheitskritischen Fehlern auszuliefern, diese aber als _Sicherheitsupdates_ ausgeben. Und der Paketmanager wird nicht meckern - denn die Pakete selbst wurden offiziell von Canonical signiert. Das Problem ist eben, dass zwar die einzelnen Pakten signiert sind, nicht aber alle Metadaten zu den Paketen. Wären die Metadaten wenigsten vernünftig signiert, wäre zumindest ein "downgrade" nicht möglich. Mit signierten Metadaten könnten man sogar sicherstellen, dass der Mirror auf einem Stand ist, der halbwegs aktuell und von Ubuntu abgesegnet ist. Nur ist das eben nicht implementiert. Ich würde das schon als schlechtes Design bezeichnen. Eigene Paketquellen bereitstellen, mit eigner Signatur, ist was anderes. Wer einen Schlüssel importiert und so der Quelle vertraut - der sollte zumindest wissen, auf was er sich einlässt,... DrScott hat geschrieben: Hmm, im Prinzip hilft da wohl nur, Sicherheitsupdates nur von "Canonical" selbst zu akzeptieren. Oder zumindest von vertrauenswürdigen Opfern.
Nicht mal das hilft zu 100%. Soweit ich weiß, werden die Pakete nicht per SSL mit entsprechendem Zertifkat übertragen. Man-In-The-Middle Attacken sind also möglich (auch wenn das natürlich weitaus unwahrscheinlicher und komplizierter ist als einen fehlerhaften Mirror ins Netz zu stellen,...)
|
xrolly
Anmeldungsdatum: 26. September 2007
Beiträge: 4322
Wohnort: NRW; 51° 39′ N, 7° 21′ O
|
Hallo @DrScott, Hallo @radieschen, ziemlich verwirrend die Erklärungen, wie darf ich das als Newbie verstehen, oder welchen Gefahren sollte ich aus dem Weg gehen? Allgemein habe ich das so verstanden, das nicht nur aus Fremdquellen sondern auch aus Partnerquellen (bei gültigem GPG-Schlüssel), Gefahren bei der Install. von Paketen bestehen. Da der eigentliche Mirror, dann ein anderer ist oder schädliche Daten in sich hat. Ist das so okay? Netten Gruß xrolly
|
DrScott
Ehemalige
(Themenstarter)
Anmeldungsdatum: 7. Juli 2005
Beiträge: 6018
Wohnort: Nürnberg
|
Rorschach hat geschrieben: Das von dir beschriebene Szenario scheint mir sogar übermässig kompliziert zu sein um das gewünschte Ziel zu erreichen.
Ich zitiere einfach mal das Paper:
We were able to get our mirror listed on every distribution we tried (Ubuntu, Fedora, OpenSuSE, CentOS, and Debian) and our mirrors were contacted by thousands of clients, even including military and government computers!
Das scheint also alles andere als kompliziert zu sein. Ich vermute mal, dass sie es auf diese offizielle Liste geschaft haben: https://launchpad.net/ubuntu/+archivemirrors Sowohl in Ubuntu als auch Kubuntu (zumindest ab 8.04) gibt es das Feature "Find best server", welches genau diese Liste verwendet. Unter Kubuntu 8.04 war ich gerade nicht in der Lage, damit etwas zu erreichen, da ich auf der Konsole nur die Fehlermeldung "ASSERT failure in QWidget: "Widgets must be created in the GUI thread." erhalte. Vielleicht ergeht es Ubuntu da ja schlechter. xrolly: Ich denke das es derzeit wichtig ist, nur die Mirrors zu verwenden, die bereits bei der Installation eingestellt werden. Bei uns wäre das dann de.archive.ubuntu.com/ubuntu/. Zu deiner Frage: Der "eigentliche" Mirror ist kein anderer. Es ist schon der, für den er sich ausgibt. Wenn aber der Betreiber des Mirrors es will, dann kann er Dir wichtige Update vorenthalten. Dadurch gelangt nicht extra Schadcode auf dein System. Aber bekannte Sicherheitslücken werden dann nicht geschlossen und können ausgenutzt werden. Selbst wenn bald vielleicht auch die Metadaten (also z.b. auch die Versionsnummer) Teil der Signatur sind, sollte man dennoch nicht einfach auf irgendwelche Mirrors zugreifen: Der Mirrorbetreiber kann nämlich sogar ganz brav das neue, tolle Update ausliefern. Aber zwischen dem Anfordern des Pakets und dem Verschwinden der Lücke liegt nun mal der Download und die Installation. Das kann einige Sekunden dauern. In dieser Zeit kann der (böse) Mirrorbetreiber bereits den Angriff auf dein System starten und noch vor Lückenschluß ausnutzen, um eine "Backdoor" zu öffnen. Da du das Update angefordert hast, hast Du ihm ja quasi mitgeteilt: "Hallo, ich bin angreifbar!". Damit keine Panik entsteht: Wirklich problematisch ist dies nur, wenn auf dem System Dienste laufen, die zusätzlich "von außen" erreichbar sind. Das ist bei einer normalen Ubuntuinstallation nicht der Fall.
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
DrScott hat geschrieben: Jemand, der Fremdquellen aktiviert hat, sollte schnellstens kalte Füße bekommen: Der Anbieter der Fremdquelle kann eine alte sshd-Version nehmen und als Update anbieten. Es findet also tatsächlich ein downgrade statt. Wenn ich die Kommentare richtig gelesen habe, so ist in der Signatur nicht die Versionsinformation enthalten, (jedenfalls nicht ausreichend genau).
Es wird Zeit, dass endlich automatisches Apt-Pinning in die "Software-Quellen"-GUI aufgenommen wird. (Oder ein entsprechendes Ersatz-Programm geschrieben wird.) Es gibt überhaupt keinen Grund, warum eine Software-Quelle, die man für ein bestimmtes Programm einträgt, den sshd up-/downgraden dürfen soll. DrScott hat geschrieben: Sowohl in Ubuntu als auch Kubuntu (zumindest ab 8.04) gibt es das Feature "Find best server", welches genau diese Liste verwendet.
Wo gibt es denn dieses Feature? Ich kann das nicht finden. Letztendlich ein Design-Fehler im Apt-Protokoll. Bis das gefixt ist, kann es ein bisschen dauern. Canonical bzw. das Debian-Projekt tun gut daran, vielleicht vorerst keine neuen Mirror zu akzeptieren und die existierenden stichpunktartig zu überprüfen. User sollten am besten die "offiziellen" Mirror benutzen.
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
Noch etwas, was mir grad eingefallen ist: Security-Updates werden gar nicht aus dem normalen, dutzendfach gespiegelten Repository eingespielt, sondern immer von security.ubuntu.com. Ein Apt-Pinning, dass diese Quelle der normalen immer vorgezogen wird, dürfte diese potentielle Attacke also erfolgreich blockieren. Einziger Nachteil, der mir gerade einfällt: Wenn ein Paket, dass bereits in der laufenden Release aus Sicherheitsgründen gepatcht wurde, einen weiteres, nicht-sicherheitsrelevantes Update erhält, wird dieses auch blockiert.
|
xrolly
Anmeldungsdatum: 26. September 2007
Beiträge: 4322
Wohnort: NRW; 51° 39′ N, 7° 21′ O
|
Hallo DrScott, vielen dank für die Informationen.
Aber zwischen dem Anfordern des Pakets und dem Verschwinden der Lücke liegt nun mal der Download und die Installation. Das kann einige Sekunden dauern. ... um eine "Backdoor" zu öffnen.
Das ist besser zu verstehen 😉. Eine frage noch:
... wenn auf dem System Dienste laufen, die zusätzlich "von außen" erreichbar sind.
... das wären zum Beispiel? Netten Gruß xrolly
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
xrolly hat geschrieben: ... wenn auf dem System Dienste laufen, die zusätzlich "von außen" erreichbar sind.
... das wären zum Beispiel?
Wenn du irgendwelche SSH-, FTP-, Web- oder sonstige Server laufen hast, die aus dem Internet zugänglich sind.
|
xrolly
Anmeldungsdatum: 26. September 2007
Beiträge: 4322
Wohnort: NRW; 51° 39′ N, 7° 21′ O
|
Hallo otzenpunk, vielen Dank für die schnelle Antwort. Das gefällt mir hier, das Themen der Sicherheit auch für Newbies verständlich gemacht werden. Nochmals vielen Dank an euch. Netten Gruß xrolly
|
DrScott
Ehemalige
(Themenstarter)
Anmeldungsdatum: 7. Juli 2005
Beiträge: 6018
Wohnort: Nürnberg
|
otzenpunk hat geschrieben: Wo gibt es denn dieses Feature? Ich kann das nicht finden.
Der Dialog ist für Ubuntu z.b. in folgendem Blog-Beitrag erläutert: http://ubuntu-tutorials.com/2008/07/02/automatically-find-fastest-repository-server-in-ubuntu-804/ Bei Kubuntu findet man den gleichen Dialog unter System->Adept-Manager->Adept->Paketquellen verwalten. Dort tritt dann allerdings Bug Find Best Server fails auf. (Für die Konsole gibt es dann wohl noch die Pakete netselect und netselect-apt, bin mir da aber nicht sicher, welche Serverliste verwendet wird...)
|
Lunar
Anmeldungsdatum: 17. März 2006
Beiträge: 5792
|
Ach, ich als Gentoo-User sehe das nicht so tragisch. Immerhin sind Debian und Ubuntu schon so weit, dass man über Fehler im APT-Protokoll reden kann. Angesichts der Tatsache, dass die meisten Distributionen (u.a. Gentoo) noch immer keine signierten Quellen bereit stellen, ist das schon ein gewaltiger Fortschritt. 😉
|
DaDa_is_Muss
Anmeldungsdatum: 10. Juni 2007
Beiträge: 268
|
Was für APT halt noch wichtig wäre ist das erwähnte signieren der Metadaten. Ausserdem sollte Ubuntu mal Paketserver mit HTTPS anbieten. Ich konnte da keine finden, APT kann das aber schon. Gibt es Debian-Server die das benutzen?
|
otzenpunk
Anmeldungsdatum: 17. Oktober 2005
Beiträge: 8691
Wohnort: Hamburg-Altona
|
DaDa_is_Muss hat geschrieben: Ausserdem sollte Ubuntu mal Paketserver mit HTTPS anbieten. Ich konnte da keine finden, APT kann das aber schon. Gibt es Debian-Server die das benutzen?
Ist auch eine Frage der Last. Verschlüsselung ist sehr teuer, was Rechenzeit angeht. Auf deinem Einzelrechner merkst du das nicht, aber bei einem Server ist es ein himmelweiter Unterschied, ob 100 User gleichzeitig mit oder ohne Verschlüsselung zugreifen. Ich würde mal schätzen, Faktor 10 bestimmt. Und was soll das dann bringen? Dass niemand merkt, dass du gerade Ubuntu updatest?
|
DaDa_is_Muss
Anmeldungsdatum: 10. Juni 2007
Beiträge: 268
|
otzenpunk hat geschrieben: DaDa_is_Muss hat geschrieben: Ausserdem sollte Ubuntu mal Paketserver mit HTTPS anbieten. Ich konnte da keine finden, APT kann das aber schon. Gibt es Debian-Server die das benutzen?
Ist auch eine Frage der Last. Verschlüsselung ist sehr teuer, was Rechenzeit angeht. Auf deinem Einzelrechner merkst du das nicht, aber bei einem Server ist es ein himmelweiter Unterschied, ob 100 User gleichzeitig mit oder ohne Verschlüsselung zugreifen. Ich würde mal schätzen, Faktor 10 bestimmt. Und was soll das dann bringen? Dass niemand merkt, dass du gerade Ubuntu updatest?
Im "Paper" auf das der OP linkt ist das alles erklärt: verhindert/erschwert Man-in-the-Middle Attacken.
|