Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
dasel-hardened-container — Pacchetto e immagine dasel v3.3.1 induriti, costruiti tramite Melange e apko. Patch per la CVE-2026-33320. | Kitploit
Strumenti/GitHubGitHub/nedlir/dasel-hardened-container
Utilità GenericheSicurezza dei ContenitoriAnalisi delle VulnerabilitàAudit di ConfigurazioneDevSecOpsRilevamento SegretiSicurezza della Supply Chain
GitHubnedlir/dasel-hardened-container

dasel-hardened-container

Pacchetto e immagine dasel v3.3.1 induriti, costruiti tramite Melange e apko. Patch per la CVE-2026-33320.

Vedi Repository
204 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

dasel v3.3.1 container indurito

Questo è un pacchetto melange e una immagine container apko per dasel v3.3.1 con una patch in fase di build per CVE-2026-33320 (espansione illimitata degli alias YAML). L'immagine è costruita interamente da un APK prodotto localmente - non viene utilizzata alcuna immagine upstream precompilata.

Prerequisiti

ToolVersione testataScopo
Docker29.3.1Runtime container, esegue melange/apko tramite compose.yaml
melange0.50.5 (immagine Docker cgr.dev/chainguard/melange@sha256:b6f11bb45a6090c182986028fd2249fb1a18dcb6e173c4ce001dd3fb4cb1dd71)Builder di pacchetti APK
apko1.2.10 (immagine Docker cgr.dev/chainguard/apko@sha256:20dfc1f5e3461b5eaf3279f762cd4bf86c7f3635d2a9642f905cf583525f9ee6)Builder di immagini OCI
  • Architettura: solo x86_64
  • Accesso a Internet richiesto per la build iniziale (scarica il tarball dei sorgenti, i moduli Go e i pacchetti Wolfi)

Requisiti Windows

Tutti i comandi di build e caricamento funzionano da qualsiasi terminale (PowerShell, CMD o bash). Un passaggio richiede ancora una shell Unix:

  • bash tests/test.sh — lo script di test usa bash e coreutils (timeout, grep, sed)

Installa Git Bash (incluso in Git for Windows) prima di eseguire i test dell'immagine.

Struttura del Progetto

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

Build

Uso di Make

make build        # keygen (if needed) + package + image
make test         # package tests + image tests
make all          # build + test
make clean        # remove all generated artifacts
make help         # list all targets and variables

Comandi manuali

# 1. Generate signing keys (one-time)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Build the APK package (fetches source, applies CVE patch, compiles)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Build the OCI image (consumes the local APK)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

Il passaggio 2 genera e firma automaticamente packages/x86_64/APKINDEX.tar.gz.

Esecuzione

Dopo aver caricato l'immagine, esegui dasel:

docker load --input dasel.tar

# Example: query a JSON file
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'

Questi flag applicano il livello runtime della strategia di difesa in profondità descritta in Indurimento dell'immagine: un filesystem root immutabile, zero capacità Linux e nessun percorso di escalation dei privilegi.

Test

Uso di Make

make test          # all tests (package + image)
make package-test  # melange package tests only
make image-test    # image tests only (requires bash)

Comandi manuali

# Package tests
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Image tests (requires Git Bash on Windows)
docker load --input dasel.tar
bash tests/test.sh

Lo script di test verifica:

  • L'immagine viene caricata e dasel version riporta v3.3.1
  • Estrazione di chiavi JSON (-i json 'test')
  • Conversione da JSON a YAML (-i json -o yaml --root)
  • Patch CVE: uno YAML dannoso billion-laughs attiva "yaml expansion budget exceeded" invece di bloccarsi

Fix CVE-2026-33320

La vulnerabilità consente un consumo illimitato di CPU/memoria tramite alias YAML annidati esponenzialmente (attacco billion laughs). La patch in melange/CVE-2026-33320.patch aggiunge due salvaguardie al lettore YAML di dasel: un limite di profondità di espansione (32) che limita l'annidamento ricorsivo degli alias e un budget di espansione (1000) che limita il totale dei dereferenziamenti di alias per documento. Quando viene raggiunto uno dei due limiti, la decodifica restituisce immediatamente un errore.

Sicurezza, Riproducibilità e Minimalità

  • Sicurezza: CVE-2026-33320 corretta in fase di build. Tutti i pacchetti sono firmati. L'immagine contiene solo 3 pacchetti APK (wolfi-baselayout, ca-certificates-bundle, dasel)
  • Riproducibilità: YAML dichiarativo sia per il pacchetto sia per l'immagine. Tarball dei sorgenti ancorato tramite SHA256. Tutte le versioni degli strumenti documentate. Binario Go compilato con -trimpath per rimuovere i percorsi di build locali
  • Minimalità: Nessuna shell, nessun package manager nell'immagine finale - solo il binario dasel, i certificati CA e baselayout

Indurimento dell'immagine

L'immagine applica una difesa in profondità oltre al packaging minimale:

LivelloMisuraEffetto
BuildUtente non-root (UID 65532)Il processo del container non viene mai eseguito come root
Build-s -w ldflags + -trimpath automaticoBinario ripulito, nessuna fuga di percorsi locali
BuildSolo 3 pacchettiSuperficie d'attacco minima, nessuna shell o package manager
Runtime--read-onlyFilesystem root immutabile
Runtime--cap-drop=ALLZero capacità Linux
Runtime--no-new-privilegesImpedisce l'escalation dei privilegi tramite setuid/setgid

Scansione delle Vulnerabilità

L'immagine costruita (dasel.tar) è stata scansionata con strumenti standard di settore per validare la postura di sicurezza oltre alla patch CVE in sé.

Syft (generazione SBOM)

Syft ha estratto 36 pacchetti dall'immagine ispezionando i metadati dei moduli del binario Go:

  • 3 pacchetti APK: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
  • 32 moduli Go: inclusi 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 e altri 25
  • 19 file inventariati: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, database APK, SBOM per pacchetto e file di configurazione baselayout

Grype (scanner di vulnerabilità)

Lo SBOM che ho generato è stato esaminato con Grype e non sono state trovate altre vulnerabilità in nessuno dei 32 moduli Go o dei 3 pacchetti APK.

Consegna

Assunzioni

Scarica lo strumento