Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
dasel-hardened-container — Gehärtetes dasel v3.3.1 Paket und Image erstellt mit Melange und apko. Patchen von CVE-2026-33320. | Kitploit
Tools/GitHubGitHub/nedlir/dasel-hardened-container
Allgemeine DienstprogrammeContainer-SicherheitSchwachstellenanalyseKonfigurationsprüfungDevSecOpsSecret-ErkennungLieferkettensicherheit
GitHubnedlir/dasel-hardened-container

dasel-hardened-container

Gehärtetes dasel v3.3.1 Paket und Image erstellt mit Melange und apko. Patchen von CVE-2026-33320.

Repository anzeigen
34vor 4 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

dasel v3.3.1 gehärteter Container

Dies ist ein Melange-Paket und ein apko-Container-Image für dasel v3.3.1 mit einem Build-Zeit-Patch für CVE-2026-33320 (unbegrenzte YAML-Alias-Expansion). Das Image wird vollständig aus einem lokal erstellten APK erstellt – es wird kein vorab erstelltes Upstream-Image verwendet.

Voraussetzungen

WerkzeugGetestete VersionZweck
Docker29.3.1Container-Laufzeit, führt melange/apko via compose.yaml aus
melange0.50.5 (Docker-Image cgr.dev/chainguard/melange@sha256:b6f11bb45a6090c182986028fd2249fb1a18dcb6e173c4ce001dd3fb4cb1dd71)APK-Paket-Builder
apko1.2.10 (Docker-Image cgr.dev/chainguard/apko@sha256:20dfc1f5e3461b5eaf3279f762cd4bf86c7f3635d2a9642f905cf583525f9ee6)OCI-Image-Builder
  • Architektur: x86_64 nur
  • Internetzugang für den Erstbau erforderlich (holt Quell-Tarball, Go-Module, Wolfi-Pakete)

Windows-Anforderungen

Alle Build- und Ladebefehle funktionieren von jedem Terminal (PowerShell, CMD oder bash). Ein Schritt erfordert noch eine Unix-Shell:

  • bash tests/test.sh – das Testskript verwendet bash und coreutils (timeout, grep, sed)

Installieren Sie Git Bash (wird mit Git für Windows ausgeliefert), bevor Sie die Image-Tests ausführen.

Projektstruktur

.
├── .github/
├── melange/
│   ├── dasel.yaml
│   └── CVE-2026-33320.patch
├── apko/
│   └── dasel.yaml
├── tests/
│   └── test.sh
├── Makefile
├── compose.yaml
├── keys/                       # Generiert, gitignoriert
│   ├── melange.rsa
│   └── melange.rsa.pub
├── sbom/                       # Generiert, gitignoriert
│   ├── sbom-x86_64.spdx.json
│   └── sbom-index.spdx.json
├── packages/                   # Generiert, gitignoriert
│   └── x86_64/
│       ├── dasel-3.3.1-r0.apk
│       └── APKINDEX.tar.gz
└── README.md

Build

Mit Make

make build        # keygen (falls nötig) + Paket + Image
make test         # Paket-Tests + Image-Tests
make all          # build + test
make clean        # Entfernt alle generierten Artefakte
make help         # Listet alle Ziele und Variablen

Manuelle Befehle

# 1. Signierschlüssel generieren (einmalig)
docker compose run --rm melange keygen keys/melange.rsa

# 2. APK-Paket bauen (holt Quelle, wendet CVE-Patch an, kompiliert)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. OCI-Image bauen (verbraucht lokales APK)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

Schritt 2 erzeugt und signiert automatisch packages/x86_64/APKINDEX.tar.gz.

Ausführen

Nach dem Laden des Images, führen Sie dasel aus:

docker load --input dasel.tar

# Beispiel: Abfrage einer JSON-Datei
echo '{"name": "dasel"}' | docker run --rm \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  -i dasel:3.3.1-amd64 \
  -i json 'name'

Diese Flags setzen die Laufzeitschicht der abwehr-in-der-Tiefe-Strategie durch, die in Image-Härtung beschrieben wird: ein unveränderliches Root-Dateisystem, null Linux-Fähigkeiten und keine Privilegieneskalationspfade.

Test

Mit Make

make test          # alle Tests (Paket + Image)
make package-test  # nur Melange-Paket-Tests
make image-test    # nur Image-Tests (erfordert bash)

Manuelle Befehle

# Paket-Tests
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Image-Tests (erfordert Git Bash unter Windows)
docker load --input dasel.tar
bash tests/test.sh

Das Testskript überprüft:

  • Image lädt und dasel version meldet v3.3.1
  • JSON-Schlüsselextraktion (-i json 'test')
  • JSON-zu-YAML-Konvertierung (-i json -o yaml --root)
  • CVE-Patch: bösartiges Billion-Laughs-YAML löst "yaml expansion budget exceeded" aus statt hängen zu bleiben

CVE-2026-33320-Fix

Die Schwachstelle ermöglicht unbegrenzten CPU-/Speicherverbrauch über exponentiell verschachtelte YAML-Aliase (Billion-Laughs-Angriff). Der Patch unter melange/CVE-2026-33320.patch fügt zwei Sicherungen in das YAML-Lese-Modul von dasel ein: eine Expansionstiefenbegrenzung (32), die rekursive Alias-Verschachtelung begrenzt, und ein Expansionsbudget (1000), das die Gesamtzahl der Alias-Dereferenzierungen pro Dokument begrenzt. Wenn eine dieser Grenzen erreicht wird, gibt die Decodierung sofort einen Fehler zurück.

Sicherheit, Reproduzierbarkeit & Minimalität

  • Sicherheit: CVE-2026-33320 zur Bauzeit gepatcht. Alle Pakete sind signiert. Image enthält nur 3 APK-Pakete (wolfi-baselayout, ca-certificates-bundle, dasel)
  • Reproduzierbarkeit: Deklaratives YAML für sowohl Paket als auch Image. Quell-Tarball per SHA256 festgelegt. Alle Tool-Versionen dokumentiert. Go-Binary mit -trimpath gebaut, um lokale Build-Pfade zu entfernen
  • Minimalität: Keine Shell, kein Paketmanager im endgültigen Image – nur das dasel-Binary, CA-Zertifikate und Baselayout

Image-Härtung

Das Image wendet über die Minimalverpackung hinaus eine abwehr-in-der-Tiefe an:

SchichtMaßnahmeWirkung
BuildNicht-Root-Benutzer (UID 65532)Container-Prozess läuft nie als Root
Build-s -w ldflags + auto -trimpathGestripptes Binary, kein lokaler Pfadverlust
BuildNur 3 PaketeMinimale Angriffsfläche, keine Shell oder Paketmanager
Runtime--read-onlyUnveränderliches Root-Dateisystem
Runtime--cap-drop=ALLNull Linux-Fähigkeiten
Runtime--no-new-privilegesVerhindert Privilegieneskalation via setuid/setgid

Schwachstellenscan

Das erstellte Image (dasel.tar) wurde mit branchenüblichen Tools gescannt, um das Sicherheitsniveau über den CVE-Patch hinaus zu validieren.

Syft (SBOM-Generierung)

Syft extrahierte 36 Pakete aus dem Image, indem es die Modul-Metadaten des Go-Binarys untersuchte:

  • 3 APK-Pakete: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
  • 32 Go-Module: darunter go.yaml.in/yaml/v4, github.com/hashicorp/hcl/v2, github.com/pelletier/go-toml/v2, github.com/goccy/go-json, github.com/charmbracelet/bubbletea, golang.org/x/sys, golang.org/x/text, stdlib go1.25.9 und 25 weitere
  • 19 inventarisierte Dateien: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, APK-DB, SBOMs pro Paket und Baselayout-Konfigurationsdateien

Grype (Schwachstellenscanner)

Das erzeugte SBOM wurde mit Grype untersucht, wobei keine weiteren Schwachstellen in den 32 Go-Modulen oder den 3 APK-Paketen gefunden wurden.

Einreichung

Annahmen

Tool herunterladen