shoucheng3/jenkinsci__workflow-cps-plugin_cve-2022-25173_2646-v6ed3b5b01ff1Exploit für CVE-2022-25173, der den CPS-Interpreter-Sandbox-Bypass des Jenkins Pipeline Groovy Plugin angreift und die Ausführung beliebigen Codes innerhalb des Jenkins-Controllers durch manipulierte Pipeline-Skripte ermöglicht.
Ein wesentlicher Bestandteil der Pipeline-Plugin-Suite, stellt dies die standardmäßige Ausführungsengine für Pipeline-Schritte bereit, basierend auf einem benutzerdefinierten Groovy-Interpreter, der im Jenkins-Controller-Prozess läuft.
(Prinzipiell könnten andere Ausführungsengines unterstützt werden, wobei FlowDefinition der API-Einstiegspunkt ist, aber keine wurde prototypisiert und es wäre wahrscheinlich ein sehr erheblicher Aufwand, eine zu schreiben.)
Pipeline-Groovy-Skriptcode wie
retry(3) {
for (int i = 0; i < 10; i++) {
branches["branch${i}"] = {
node {
retry(3) {
checkout scm
}
sh 'make world'
}
}
}
parallel branches
wird als Groovy-Programm ausgeführt, wobei bestimmte spezielle Funktionsaufrufe namens Steps Jenkins-spezifische Operationen ausführen.
In diesem Beispiel wird der Schritt parallel in diesem Plugin definiert, während node, retry, checkout und sh in anderen Plugins der Pipeline-Suite definiert sind. Die globale Variable scm wird im Pipeline Multibranch Plugin definiert.
Das Groovy-Skript wird in eine Klasse namens WorkflowScript kompiliert, sodass dieser Name in Stacktraces anstelle des Skriptdateinamens (z.B. Jenkinsfile) angezeigt wird.
Im Gegensatz zu einem regulären Groovy-Programm, das von der Kommandozeile ausgeführt wird, wird der vollständige Zustand eines Pipeline-Build-Programms jedes Mal auf die Festplatte gespeichert, wenn eine asynchrone Operation ausgeführt wird, zu der die meisten Pipeline-Schritte gehören. Jenkins kann während eines laufenden Builds neu gestartet werden und wird die Ausführung des Programms an der Stelle fortsetzen, an der es unterbrochen wurde. Dies ist nicht auf Effizienz ausgelegt und sollte daher auf hochrangigen „Klebecode“ beschränkt werden, der direkt mit Jenkins-Funktionen zusammenhängt; die eigene Build-Logik Ihres Projekts sollte über externe Programme auf einem Build-Knoten in einem sh- oder bat-Schritt ausgeführt werden.
Der Pipeline Groovy Epic in JIRA behandelt einige bekannte Einschränkungen des Groovy-Interpreters. Diese Probleme rühren daher, dass Pipeline Groovy nicht direkt ausführen kann, sondern jeden Vorgang abfangen muss, um den Programmzustand zu speichern.
Der Pipeline Sandbox Epic behandelt Probleme mit der Groovy-Sandbox, die verwendet wird, um zu verhindern, dass bösartige Pipeline-Skripte die Kontrolle über Jenkins übernehmen. Skripte, die mit deaktivierter Sandbox ausgeführt werden, können direkte Aufrufe von Jenkins-internen APIs tätigen, was eine nützliche Problemumgehung für fehlende Schrittfunktionalität sein kann, aber aus Sicherheitsgründen nur Administratoren solche Skripte genehmigen können.
Der Pipeline Snippet Generator Epic behandelt Probleme mit dem Werkzeug, das verwendet wird, um Beispiele der Schrittsyntax basierend auf Live-Konfigurationsformularen bereitzustellen.
Dieses Plugin hieß zuvor "Workflow CPS Plugin" oder "Workflow Groovy Plugin". Dementsprechend hat es die Maven artifactId workflow-cps, nicht pipeline-groovy.
Das Plugin verwendet die Groovy CPS Library zur Implementierung einer Continuation-Passing-Style-Transformation des Programms während der Kompilierung. Der standardmäßige Groovy-Compiler wird verwendet, um den AST zu erstellen, aber die Generierung von Bytecode wird durch einen CompilationCustomizer abgefangen, der die meisten Operationen durch Varianten ersetzt, die einen speziellen „Fehler“, CpsCallableInvocation, auslösen. Dieser wird dann von der Engine abgefangen, die die daraus gewonnenen Informationen (wie Argumente, die an einen Methodenaufruf übergeben werden sollen) nutzt, um die Kontrolle an die nächste Fortsetzung weiterzugeben.
Pipeline-Skripte können bestimmte Methoden mit der Annotation @NonCPS kennzeichnen. Diese werden dann normal kompiliert (mit Ausnahme von Sandbox-Sicherheitsprüfungen) und verhalten sich daher ähnlich wie „binäre“ Methoden der Java-Plattform, der Groovy-Laufzeit oder des Jenkins-Core- oder Plugin-Codes. @NonCPS-Methoden können sicher nicht Serializable-Objekte als lokale Variablen verwenden, sollten jedoch keine nicht serialisierbaren Parameter akzeptieren oder nicht serialisierbare Werte zurückgeben oder speichern. Sie dürfen von einer @NonCPS-Methode aus keine regulären (CPS-transformierten) Methoden oder Pipeline-Schritte aufrufen, daher werden sie am besten verwendet, um einige Berechnungen durchzuführen, bevor eine Zusammenfassung an das Hauptskript zurückgegeben wird. Beachten Sie insbesondere, dass @Overrides von Methoden, die in binären Klassen definiert sind, wie z.B. Object.toString(), im Allgemeinen mit @NonCPS gekennzeichnet werden sollten, da sie üblicherweise von binärem Code aufgerufen werden.
Einige Arten von Objekten sind an sich nicht sicher serialisierbar, dennoch möchten wir eine Referenz auf sie im Programmdiagramm behalten. Ein Beispiel ist der Executor (~ Executor-Slot auf einem Built-In- oder Agent-Knoten), der Teil des Kontexts ist, der von einem node-Schritt an jeden Schritt in seinem Block übergeben wird, insbesondere sh/bat. Pipeline verwendet die Pickle-API, um serialisierungssichere Versionen dieser Objekte zu ersetzen. Wenn ein WorkflowRun nach einem Neustart von der Festplatte geladen wird, wird der Programmzustand deserialisiert und Pickles werden parallel deserialisiert („rehydriert“). Wenn und sobald alle Pickles erfolgreich deserialisiert wurden und die resultierenden Objekte wieder in den Programmzustand eingefügt wurden, beginnt das Programm erneut zu laufen, und StepExecution.onResume wird aufgerufen, um Timer und dergleichen wiederherzustellen.
Die gesamte Programmlogik wird in einem „CPS VM Thread“ ausgeführt, der lediglich ein Java-Thread-Pool ist, der binäre Methoden ausführen und bestimmen kann, welche Fortsetzung als nächstes an der Reihe ist. Der parallel-Schritt verwendet „Green Threads“ (auch bekannt als kooperatives Multitasking): Er zeichnet logische Thread- (~ Branch-)Namen für verschiedene Aktionen auf, führt sie aber nicht buchstäblich gleichzeitig aus. Das Programm scheint Aufgaben parallel auszuführen, aber nur weil die meisten Schritte asynchron ausgeführt werden, während der VM-Thread inaktiv ist, und sie sich zeitlich überlappen können. Es wird kein Java-Thread verbraucht, außer in den normalerweise kurzen Intervallen, in denen tatsächlich Groovy-Code auf dem VM-Thread ausgeführt wird. Das Executor-Widget zeigt nur dann einen Eintrag für den „Flyweight“-Executor auf dem Built-In-Knoten an, wenn der VM-Thread beschäftigt ist; normalerweise ist er ausgeblendet.