Ich wurde gerade auf einen sehr interessanten Artikel zu einem Sicherheitsproblem hingewiesen Cross Build Injektion (XBI). Im Grunde ist es ein fantastischer Name für das Schmuggeln von schlechtem Code über automatisierte Build-Systeme wie Ameise, Maven oder Efeu in eine Anwendung zur Build-Zeit.
Das Problem könnte durch die Einführung einer kryptografischen Signaturvalidierung für Abhängigkeiten gemildert werden, wie sie derzeit bei vielen Betriebssystemen zum Herunterladen von Paketen vorhanden ist.
Um es klar zu sagen: Ich bin nicht über die Bereitstellung von md5- oder sha1-Hashes für die Artefakte. Das ist bereits geschehen, aber diese Hashes werden am selben Ort wie die Artefakte gespeichert. Sobald also ein böswilliger Hacker das Repository kompromittiert und das Artefakt ersetzen kann, können sie auch die Hashes ersetzen.
Was nun tatsächlich benötigt wird, ist eine Art von PKI, die es den Entwicklern erlaubt, ihre Artefakte und Maven zu signieren, um diese Signaturen zu verifizieren. Da die Signatur mit dem privaten Schlüssel des Entwicklers erstellt wird, kann sie nicht manipuliert werden, wenn nur das Repository kompromittiert ist.
Kennt jemand den Zustand dieses in maven?
Update: Die unten genannten Prüfsummen sind in der Tat nur für Integritätsprüfungen und werden tatsächlich mit den Artefakten gespeichert, so dass sie die Frage nicht beantworten.
Eigentlich braucht man, um Artefakte zu unterzeichnen PGP mit ihnen zu einem Repository zu laden, die mit zentraler ( synchronisiert Maven GPG Plugin kann für diesen Schritt helfen). Um Signaturen zum Download zu überprüfen, werden Sie aufgefordert, einen Repository-Manager zu verwenden, der diese Funktion unterstützt. Von So erstellen Sie PGP-Signaturen mit Maven :
Wenn Sie ein Tool verwenden, das herunterlädt Artefakte aus dem Central Maven Repository, müssen Sie sicherstellen, dass Sie bemühen sich zu validieren dass diese Artefakte einen gültigen PGP haben Signatur, gegen die verifiziert werden kann ein öffentlicher Schlüsselserver. Wenn du es nicht tust Signaturen validieren, dann haben Sie keine garantiere, was du bist Herunterladen ist das Originalartefakt. Eine Möglichkeit, Signaturen zu überprüfen Artefakte ist ein Repository zu verwenden Manager wie Nexus Professional. Im Nexus Professional, das Sie konfigurieren können die Procurement Suite, um alle zu überprüfen heruntergeladenes Artefakt für ein gültiges PGP Unterschrift und validiere die Unterschrift gegen einen öffentlichen Schlüsselserver.
Wenn Sie Software mit Hilfe von entwickeln Maven, du solltest ein PGP generieren Unterschrift für Ihre Veröffentlichungen. Releasing Software mit gültigen Signaturen bedeutet, dass Ihre Kunden kann das ein Software-Artefakt verifizieren wurde vom ursprünglichen Autor erstellt und dass es nicht von geändert wurde jemand auf der Durchreise. Die meisten großen OSS schmiedet wie die Apache Software Foundation benötigt alle Projekte veröffentlicht von einem Release-Manager, dessen Schlüssel wurde von anderen Mitgliedern unterzeichnet von der Organisation, und wenn Sie wollen um Ihre Softwareartefakte zu synchronisieren nach Maven Central müssen Sie bietet PGP-Signaturen .
checksumPolicy ).
Maven Repository Manager können / sollten auch damit umgehen können. Siehe zum Beispiel:
tl; dr :
Nicht vorhandene Verifizierungsmechanismen in Maven und fehlende Sprachkonstrukte in der POM-DSL sind eine ernsthafte Sicherheitsbedrohung. Bis MNG-6026 angesprochen wird, verwenden Sie etwas wie Gradle Witness .
Keine der Antworten scheint das Problem zu lösen. Das Signieren von Artefakten ist nur ein erster Schritt in die richtige Richtung. Aber die Bedingung, wenn ein Schlüssel, der zum Signieren des Artefakts verwendet wird, als vertrauenswürdig / gültig angesehen wird, ist sehr undurchsichtig. Zum Beispiel: Wie funktioniert pgpverify-maven-plugin oder Nexus Professional tatsächlich überprüfen, ob die Signatur für das Artefakt gültig ist? Nur das Abrufen des Schlüssels vom Schlüsselserver und das Überprüfen des Artefakts reichen nicht aus.
Sonatype erwähnt dies kurz in ihrem Blogpost :
PGP Signaturen: Eine andere Ebene
Auf der Verbrauchsseite können Sie die Beschaffung in Nexus Professional verwenden um auf das Vorhandensein einer Signatur zu prüfen, und auf der Veröffentlichungsseite Signieren Sie Ihre Releases mit einer PGP-Signatur und machen Sie PGP-Signaturen auf einem öffentlichen Schlüsselserver verfügbar ist, wird den Leuten helfen, dies zu überprüfen Artefakte und Prüfsummen sind konsistent. Hinweis: Ich denke, da ist mehr Es muss daran gearbeitet werden, Tools zu erstellen, die die Verwendung von PGP-Schlüsseln fördern und, noch wichtiger, geben Sie Repository-Administratoren eine gewisse Kontrolle über welche Schlüssel vertrauenswürdig sind.
(Betonung meiner)
Was wir brauchen, ist die Möglichkeit, eine Vertrauensbeziehung von Ihrem Projekt oder Artefakt zu den erklärten Abhängigkeiten zu modellieren. Wenn also alle Beteiligten eine solche Beziehung deklarieren, können wir eine "Vertrauenskette" von der Wurzel (z. B. dem Projekt) über ihre Abhängigkeiten bis zur allerletzten transitiven Abhängigkeit erzeugen. Das Project Object Model (POM) muss um eine & lt; verification / & gt; Element für Abhängigkeiten.
Im Moment haben wir etwas wie
%Vor%Für harte Abhängigkeiten, & lt; Verifizierung / & gt; könnte die sha256sum von Artefakten und ihre POM-Datei enthalten:
%Vor%Wenn weiche oder bereichsabhängige Abhängigkeiten verwendet werden, können wir den öffentlichen Schlüssel (oder mehrere) des Schlüsselpaars angeben, das zum Signieren der Artefakte verwendet wird
%Vor%Dank Peter auslösenden mir, ich habe ein Feature-Request für Apache Maven angehoben: MNG -6026 . Mal sehen, was als nächstes passiert.
Gradle Witness macht etwas Ähnliches für Großartiges. Aber es hat einige Nachteile:
Dasselbe scheint auch für das Maven Enforcer Plugin zu gelten.
pgpverify-maven-plugin folgt offenbar auch diesem Ansatz. Obwohl Dokumentation dort fehlt, ist ein Test für ein so genanntes keysMap Eigentum , die auch href="https://github.com/s4u/pgpverify-maven-plugin/blob/7dc1cb0f2c74352e7995c7cf1261dba040b7eb30/src/it/sigOkKeysMap/pom.xml#L46"> keysMapLocation .
"Das Problem könnte durch die Einführung einer kryptografischen Signaturvalidierung für Abhängigkeiten gemildert werden, wie sie derzeit bei vielen Betriebssystemen zum Herunterladen von Paketen vorhanden ist."
Was Sie suchen, um Ihre JAR-Dateien zu signieren. Ссылка
Sie müssen Ihren privaten Schlüssel mit geeigneten Maßnahmen schützen. Aber wenn Sie über eine solche Gelassenheit paranoid sind, müssen Sie sich vielleicht über PKI, Public Key Infrastructures informieren.
Es ist jetzt möglich, PGP-Signaturen in maven mit diesem Plugin zu validieren: Ссылка
So konfigurieren Sie es in Ihrem übergeordneten pom.xml :
Diese Konfiguration bindet die PGP-Prüfung an die Phase install .
Wenn Sie den Check nicht ständig ausführen möchten, entfernen Sie das Element <executions /> und führen Sie es wie folgt manuell aus:
Tags und Links maven security build-automation pom.xml