staging.inyokaproject.org

noisefloor schrieb:

korrigiert mich, wenn ich falsch liege, aber: ein kompromittierter Schlüssel ist doch nur die halbe Miete, weil der muss doch nichts desto trotz zu den Paketquellen passen. D.h. wenn man dem Nutzer "falsche" Pakete unterjubeln will, muss man doch auch noch die zugehörige Quelle kompromittieren? Und ein kompromittierter Schlüssel alleine ermöglicht doch auch noch nicht, dass ein Paket z.B. von source.of.all.evil.org statt z.B. aus den Canonical Quellen gezogen wird.

Nehmen wir an, das Paket systemd hat im Ubuntu-Repo die Version 4.0. Ein Fremdanbieter kann in seinem Repo eine Version 4.1 von systemd bereitstellen. APT wählt dann automatisch die höhere Version aus (aber nur unter der Voraussetzung, dass es den zum Fremd-Repo passenden Fremd-Schlüssel im generellen Schlüsselbund von Ubuntu findet). Und schon haben wir dann tief im System Closed-Source-Binärcode, der alles mögliche anstellen kann, z.B. Trojaner laden und aktivieren.
So jedenfalls habe ich die Problematik verstanden.

Ein zweiter Aspekt ist dann noch, ob der Fremdschlüssel in /etc/apt/keyrings/ oder /usr/share/keyrings/ abgelegt wird. Zu dem Thema wurde der bekannte Debian-Artikel erst im Mai/Juni '22 entsprechend ergänzt, weshalb überall Verwirrung auftrat.

noisefloor schrieb:

bzgl. "kinderlich": korrigier' mich, wenn ich falsch liege, aber ist IP-Spoofing nicht eine "man in den middle" Attacke, d.h. man braucht irgendwie irgendwo Zugriff auf den (unverschlüsselten) Netzwerkverkehr?

Ja.

Es geht aber auch, dass ein Serverumzug stattgefunden hat (DNS noch nicht umgestellt bzw. lange TTL) und der neue nun die IP hat und und dann mit seinem Schlüssel Kram für die Canonical-Quelle bereitstellen kann, was das System akzeptiert. Mit der neuen Variante geht das nur noch für das Repo des Angreifers selbst, nicht für andere Repos.

Zusammengefasst: Das hier geschlossene Sicherheitsproblem ist relativ klein und die Auswirkungen der Änderung sind sehr groß.

Hallo,

So jedenfalls habe ich die Problematik verstanden.

Das ist IMHO falsch. Wenn Quelle $FOO eine höhere Version von eines installierten Pakets bereit stellt, dann wird das _immer_ gezogen, sofern du nicht apt-pinning oder so verwendest. Egal wie wo welcher Schlüssel liegt, eine freigeschaltete Quelle reicht.

Genau darum gibt es ja auch die Fremdquellen Warnung im Wiki.

Gruß, noisefloor

noisefloor schrieb:

So jedenfalls habe ich die Problematik verstanden.

Das ist IMHO falsch. Wenn Quelle $FOO eine höhere Version von eines installierten Pakets bereit stellt, dann wird das _immer_ gezogen, sofern du nicht apt-pinning oder so verwendest. Egal wie wo welcher Schlüssel liegt, eine freigeschaltete Quelle reicht.

Dann würde ich mal sagen:

Further research is neccessary"

Hallo,

na ja, den potentiellen Angriffsvektor wie von DJKUhpisse erklärt kann ich schon nachvollziehen, auch wenn ich den nicht als "kinderleicht" bezeichnen würde.

Was IMHO jetzt auch klar gestellt ist, ist das durch einen "suboptimal" abgelegten Schlüssel "einfach so" Pakete gegen andere (kompromittierte) ausgetauscht werden können - was ja auch mal im Raum stand. Könnt den Aluhut also wieder abnehmen... *SCNR*

Also ich habe nichts dagegen, wenn das Verschieben eines Schlüssels erklärt wird mit einer kurzen Erklärung warum. Aber bitte faktisch und nicht spekulativ.

Gruß, noisefloor

noisefloor schrieb:

Hallo,

So jedenfalls habe ich die Problematik verstanden.

Das ist IMHO falsch. Wenn Quelle $FOO eine höhere Version von eines installierten Pakets bereit stellt, dann wird das _immer_ gezogen, sofern du nicht apt-pinning oder so verwendest. Egal wie wo welcher Schlüssel liegt, eine freigeschaltete Quelle reicht.

Genau darum gibt es ja auch die Fremdquellen Warnung im Wiki.

Richtig, nur dass jetzt einer Quelle genau ein Schlüssel zugeordnet ist und wenn man apt-pinning verwendet eben kein MITM mehr unbemerkt möglich ist. Die meisten Leute sind durch die Änderung nicht sicherer.

DJKUhpisse schrieb:

Richtig, nur dass jetzt einer Quelle genau ein Schlüssel zugeordnet ist und wenn man apt-pinning verwendet eben kein MITM mehr unbemerkt möglich ist. Die meisten Leute sind durch die Änderung nicht sicherer.

Dann sollte man im Artikel vielleicht auch das Apt-Pinning erwähnen und im Zusammenspiel mit Fremd-Schlüsseln und -Quellen quasi als Notwendigkeit bewerten.

Hier findet sich Beispielmaterial: https://forum.ubuntuusers.de/post/9164647/

Hallo,

Dann sollte man im Artikel vielleicht auch das Apt-Pinning erwähnen und im Zusammenspiel mit Fremd-Schlüsseln und -Quellen quasi als Notwendigkeit bewerten.

Nee, halte ich für falsch. Korrigiert mich, wenn ich falsch liegt, aber apt Pinning lässt sich "nur" auf eine Paketversion beschränken und nicht noch auf Quellen. D.h. mit apt Pinning würden auch Updates aus den Canonical Quellen unterbunden.

Nochmal: die Fremdquellen-Warnung ist _nicht_ zum Spaß im Wiki. Und apt Pinning macht Fremdquellen nicht besser (oder schlechter). BTW: wenn man möglichst viel per snap oder Flatpak installiert hat man diese Probleme nicht... Aber manchmal rutsch der Aluhut ja auch über die Augen und man hat keine so gute Sicht mehr auf die Dinge *SCNR*

Gruß, noisefloor

noisefloor schrieb:

Korrigiert mich, wenn ich falsch liegt, aber apt Pinning lässt sich "nur" auf eine Paketversion beschränken und nicht noch auf Quellen. D.h. mit apt Pinning würden auch Updates aus den Canonical Quellen unterbunden.

Doch, wieso, geht doch. In meinem Beispiel oben habe ich die Nemo-Pakete auf die Linux-Mint-Quelle gepinnt. In Fall von Skype oder MS-Teams müsste man es genau umgekehrt machen, also nur die Pakete aus der MS-Quelle freischalten, die nicht schon aus der Ubuntu-Quelle bezogen werden.

Hier sollte noch ein Weg rein, wie man anhand der Schlüssel-ID den Schlüssel hinzufügt.

Weiß das jemand von euch ad-hoc?

DJKUhpisse schrieb:

Weiß das jemand von euch ad-hoc?

Meinst Du so was hier:

sudo mkdir -pm700 /root/.gnupg && sudo mkdir -pm755 /etc/apt/keyrings    ## falls die Verzeichnisse noch nicht existieren
sudo -H gpg --no-default-keyring --keyserver keyserver.ubuntu.com --recv-keys A6616109451BBBF2 --keyring /etc/apt/keyrings/linux-mint-archive.gpg
sudo apt update && sudo apt install nemo-fileroller nemo-audio-tab nemo-compare nemo-share 

Für dieses Beispiel ist allerdings das oben erwähnte Pinning Voraussetzung, damit nur die gewünschen Pakete aus der Fremdquelle gezogen werden.

Was ich auch noch gut fände, wenn man in dem Artikel erwähnen würde, dass anschließend immer noch manuell sudo apt update ausgeführt werden muss, was bei sudo add-apt-repository ja nicht mehr nötig ist.

UlfZibis schrieb:

DJKUhpisse schrieb:

Weiß das jemand von euch ad-hoc?

Meinst Du so was hier:

Oder einfach

sudo -H gpg --no-default-keyring --keyring /etc/apt/keyrings/<file>.gpg --import A6616109451BBBF2 

Das hier?

Das ist ja ein echt gruseliger Artikel! Der Abschnitt „Schlüssel hinzufügen“ ist ein Paradebeispiel dafür, wie man es als sicherheitsbewusster Administrator ganz bestimmt nicht machen sollte. Es fehlt die unverzichtbare Validierung des Schlüssels als Voraussetzung der Vertrauensstellung, welche man ja dem (möglicherweise angeblichem?) Eigentümer einräumt. Außerdem: root braucht kein gpg und gpg braucht keine Rootrechte zur Formatumwandlung des Schlüssels, diese selbst ist auch eigentlich unnötig.

Es fehlt die unverzichtbare Validierung des Schlüssels als Voraussetzung der Vertrauensstellung

Diese wurde bisher auch nicht durchgeführt. Wie würdest du diese Durchführen?

Außerdem: root braucht kein gpg und gpg braucht keine Rootrechte zur Formatumwandlung des Schlüssels, diese selbst ist auch eigentlich unnötig.

Was würdest du alternativ vorschlagen?

kB schrieb:

[...] Außerdem: root braucht kein gpg und gpg braucht keine Rootrechte zur Formatumwandlung des Schlüssels [...]

Auch nicht wenn der Schlüssel bzw. Keyring im Wurzelverzeichnis liegt?

kB schrieb:

Es fehlt die unverzichtbare Validierung des Schlüssels als Voraussetzung der Vertrauensstellung, welche man ja dem (möglicherweise angeblichem?) Eigentümer einräumt.

Mit gpg --verify? Dann müsste man die Signatur allerdings erst exportieren.