Plugin- und Theme-Komponenten-Signierung

Merkmal
1

Ich habe heute dieses Thema gesehen: Third-party plugin repository hijacked

Es ist schön, dass dieses Problem für dieses Repository „gelöst“ ist. Aber das eigentliche Problem besteht weiterhin. Wie signiert man und was ist die Quelle für den Schlüssel, mit dem die Signatur verifiziert wird?

Mein erster Versuch, dieses Problem zu lösen, wäre also, den eingebauten Signaturmechanismus von Git zu nutzen. Discourse müsste dann den Unterzeichner eines installierten Plugins verfolgen. Wenn sich dieser ändert, sollte er den Administrator warnen.

Das hat offensichtlich viele Schwachstellen.

Woher bekommt man die Schlüssel des Unterzeichners? Metadaten in plugin.rb und about.json. Keyserver sind nett… aber ziemlich kompliziert. Oder… meta.discourse.org dient als Keyserver, also sollten Autoren ihre öffentlichen Schlüssel registrieren.

Nur den neuesten Commit verifizieren? Wahrscheinlich ausreichend, man kann nicht viel gegen gestohlene Schlüssel tun.

Aber wenn ein Schlüssel gestohlen wird, wie prüft man den Widerruf? Wenn meta den Schlüssel bereitstellt, könnte dieses Problem gelöst werden.

Das ist großartig für die Admin-Oberfläche, aber was ist mit den Plugin-Installationen in einem Docker-Container? Speichern Sie zuvor akzeptierte Signierschlüssel gemeinsam und fügen Sie einen Verifizierungsschritt zum Neuerstellen hinzu. Wahrscheinlich eine Vorabprüfung, um zu verhindern, dass das System heruntergefahren wird und dann der Klon abgelehnt wird; und dann eine Nach-Checkout-Prüfung, nur für den Fall, dass jemand in der Zwischenzeit am Repository herumgefummelt hat?

Was ist mit alten, unsignierten Repos? Große Warnung, dass der Inhalt nicht verifiziert werden kann. + Ja/Nein/Abbrechen-Aufforderung

11 „Gefällt mir“
2

trägt die Verantwortung. Der Serverbesitzer sollte sicherstellen, dass ein Server den gewünschten Code lädt. Ob er die Schuld auf GitHub, Upstream zu seiner TLD (z. B. .com) oder weiter Downstream schiebt.

1 „Gefällt mir“
3

Auf jeden Fall, absolut.

Aber machen Sie meine Arbeit als Administrator einfacher. Ich als Plugin-Entwickler möchte Ihre Arbeit einfacher machen.

Derzeit vertraut das Upgrade absolut der Quell-URI. Das beunruhigt mich, da sich gezeigt hat, dass die Quelle (GitHub) nicht vertrauenswürdig ist, insbesondere nicht in bestimmten Schritten beim Neuerstellen eines Containers. Warnen Sie mich als Administrator, dass sich die Vertrauensbeziehungen ändern.

Ich als Administrator habe jede Plugin- oder Theme-Komponente überprüft, bevor ich sie hinzugefügt habe. Danach gibt mir Discourse wenig bis gar keine Anleitung zur Überprüfung. Heute musste ich meinen Container neu erstellen, was alle Plugins neu klont. Ich habe ziemlich die Kontrolle verloren, es sei denn, ich nehme eine fortgeschrittene Änderung an der Einrichtung vor, um eine Veröffentlichung zu fixieren.

Das mag für mich als gut ausgeruhten Softwareentwickler funktionieren, wenn ich Wartungsarbeiten durchführen muss. Aber das sind ziemlich viele Einschränkungen. Neben der Tatsache, dass Discourse eine großartige Plattform für Diskussionen ist. Wir müssen sie auch zu einer technisch sicheren Plattform für Diskussionen machen. Kompromittierte Plugins können ernsthaften Schaden anrichten. Kompromittierte Theme-Komponenten können erheblichen Schaden anrichten.

5 „Gefällt mir“
4

Ich finde das sehr sinnvoll. Wir haben SRI für Javascript, MS Authenticode für Windows.
Es gab viele Supply-Chain-Angriffe auf zum Beispiel NPM und RubyGems.

Das Einzige, was mir Sorgen bereitet, ist, dass es eine Hürde für Leute geben könnte, ihre Plugin- oder Theme-Komponente „akzeptiert“ zu bekommen, so wie Microsoft Smartscreen Benutzer daran hindert, weniger bekannte Software von einzelnen Entwicklern auszuführen.

5 „Gefällt mir“
5

Wie ich in diesem Beitrag erwähnt habe, sind auch zusätzlich eingezogene Abhängigkeiten ein Angriffsvektor.

Bei Plugins ist es recht einfach, zusätzliche Gems zu installieren. Dies ist für einen Administrator ziemlich unsichtbar.

Darüber hinaus scheint es bei diesem Ansatz kein SRI zu geben. Ich kenne mich mit dem Ruby-Ökosystem nicht so gut aus, ist das Gem-Repository unveränderlich?