Base-Images mit Schwachstellen

Was ist Base-Images mit Schwachstellen?

Anwendungsabhängigkeiten werden bei Änderungen überprüft; die darunterliegende Betriebssystemschicht häufig nicht. Ein veränderlicher Tag wie node:18 kann bei jedem Build auf andere Inhalte zeigen. Zudem werden Schwachstellen erst mit der Zeit entdeckt: Ein bei Auslieferung unauffälliges Image kann heute kritisch sein. Sie scannen ein veraltetes Image, finden CVE-2023-4863 in libwebp und bestätigen einen Weg zur Ausführung von Schadcode aus der Ferne. Dann legen Sie das Base-Image per Digest fest, bauen neu und scannen erneut. Dafür ist künftig ein regelmäßiger Neubau erforderlich.

Was Sie lernen in Base-Images mit Schwachstellen

• Erkennen Sie, dass sich die Betriebssystemschicht unter Ihrem Code bei einem veränderlichen Base-Tag zwischen Builds ohne bewusste Entscheidung ändern kann
• Prüfen Sie ein laufendes Image auf bekannte Schwachstellen und bestätigen Sie, dass CVE-2023-4863 in libwebp die Ausführung von Schadcode aus der Ferne ermöglicht
• Erklären Sie, warum eine Schwachstelle in der Betriebssystemschicht in keiner Anwendungs-Lockfile steht und durch einen Wechsel des Base-Images behoben wird
• Fixieren Sie das Base-Image auf einen exakten Digest, sodass jeder Build dieselben Bytes abruft und eine Änderung der Base zu einem überprüfbaren Commit wird
• Bauen Sie das Image neu und prüfen Sie es erneut, um die Behebung zu bestätigen. Planen Sie anschließend regelmäßige Aktualisierungen des fixierten Base-Images.

Base-Images mit Schwachstellen — Trainingsschritte

1. Das Scheduler-Image in der Registry

   Bob hat mit einem offengelegten Robot-Token Lesezugriff auf Bremhollows Container-Registry. Er untersucht nicht den Code, sondern das Alter der Images. Ein Dienst, dessen Image seit Langem nicht neu gebaut wurde, nutzt womöglich ein längst veraltetes Base-Image. Der Scheduler verarbeitet hochgeladene Bilder. Deshalb interessiert Bob besonders, worauf sein Image aufbaut. Öffnen Sie den Eintrag in der Registry.

2. Ein Image, das stehen geblieben ist

   Der Eintrag in der Registry ist korrekt und trotzdem für Bob hilfreich: Eine Zeile verrät ihm, dass das Image in Produktion alt ist und auf einem veränderlichen Base-Tag beruht.

3. Das Base-Image auf Schwachstellen prüfen

   Bob lädt das Image herunter und prüft es mit einem Schwachstellenscanner – demselben Tool, das auch die Verteidiger nutzen würden. Er sucht keinen Fehler im Anwendungscode, sondern eine bekannte Schwachstelle in den Betriebssystempaketen des Base-Images. Für solche Schwachstellen gibt es oft bereits funktionierende Exploits.

4. Die CVE für einen Shell-Zugriff nutzen

   Ein Scannerfund allein beweist noch keinen funktionierenden Angriff. Für CVE-2023-4863 gibt es einen öffentlichen Proof of Concept: ein präpariertes WebP-Bild, das beim Dekodieren einen Überlauf in libwebp auslöst. Der Scheduler dekodiert jedes hochgeladene Bild. Bob bindet die PoC-Datei in einen kurzlebigen Container mit dem anfälligen Image ein und dekodiert sie dort. So bestätigt er den Weg zur Ausführung von Schadcode aus der Ferne, bevor er das Produktivsystem angreift.

5. Wo die Schwachstelle steckt

6. Der Scanner meldet eine Schwachstelle in den laufenden Images

   Bremhollow hat einen Image-Scan in seine Pipeline aufgenommen. Der erste vollständige Scan der bereits in Produktion laufenden Images liefert einen dringenden Befund.

7. Selbst nachsehen

   Bevor sie etwas ändert, führt Alice denselben Scan am bereitgestellten Image aus. Sie will den Fund, seine Herkunft und das verwendete Base-Image selbst prüfen.

8. Das Dockerfile öffnen

   Das Base-Image wird in einer Zeile des Dockerfiles festgelegt. Über diese Zeile kam auch das vom Scanner gefundene Paket ins Image.

9. Den veränderlichen Base-Tag finden

   Hier ist nichts falsch geschrieben oder fehlerhaft. Das Problem ist eine einzige Zeile, die weniger aussagt, als sie sollte.

10. Die Base per Digest fixieren

    A tag is a label someone can move; a digest is the image's content fingerprint and can never point at anything else. Node 18 reached end of life in April 2025, so no patched node:18 base will ever come. Alice moves the base to a slim Node 22 LTS build and pins it by its digest, so every build from now on pulls the same audited bytes, and moving that pin becomes a deliberate, reviewable change.