Skip to content
KitploitKITPLOIT
FerramentasBlog
Log in
Enviar
FerramentasBlog
Enviar

Ferramentas de Hacking, PenTest e Cibersegurança para o seu Arsenal de Segurança!

Kitploit é um diretório de ferramentas de hacking, cibersegurança e pentesting. Descubra as últimas atualizações de projetos para encontrar vulnerabilidades, analisar sistemas, automatizar testes e fortalecer sua segurança.

··Feeds·Contato·Privacidade·© 2026 Kitploit

Diretório de Ferramentas

Categorias

Ver todas as categorias
Loading categories
dasel-hardened-container — Pacote e imagem Endurecido dasel v3.3.1 construídos via Melange e apko. Corrigindo CVE-2026-33320. | Kitploit
Ferramentas/GitHubGitHub/nedlir/dasel-hardened-container
Utilitários de Propósito GeralSegurança de ContêineresAnálise de VulnerabilidadesAuditoria de ConfiguraçãoDevSecOpsDetecção de SegredosSegurança da Cadeia de Suprimentos
GitHubnedlir/dasel-hardened-container

dasel-hardened-container

Pacote e imagem Endurecido dasel v3.3.1 construídos via Melange e apko. Corrigindo CVE-2026-33320.

Ver Repositório
20há 4 mesesAinda não revisado

Mais Populares

Ver todos →

Descubra as ferramentas mais usadas pela nossa comunidade.

Explore todas as ferramentas

Navegue pela nossa coleção de ferramentas

Ver todas as ferramentas →
Compartilhar

dasel v3.3.1 contentor protegido

Este é um pacote melange e uma imagem de contentor apko para dasel v3.3.1 com uma correção em tempo de compilação para CVE-2026-33320 (expansão ilimitada de aliases YAML). A imagem é construída inteiramente a partir de um APK produzido localmente - nenhuma imagem pré-construída de upstream é usada.

Pré-requisitos

FerramentaVersão testadaFinalidade
Docker29.3.1Runtime de contentor, executa melange/apko via compose.yaml
melange0.50.5 (imagem Docker cgr.dev/chainguard/melange@sha256:b6f11bb45a6090c182986028fd2249fb1a18dcb6e173c4ce001dd3fb4cb1dd71)Construtor de pacotes APK
apko1.2.10 (imagem Docker cgr.dev/chainguard/apko@sha256:20dfc1f5e3461b5eaf3279f762cd4bf86c7f3635d2a9642f905cf583525f9ee6)Construtor de imagens OCI
  • Arquitetura: x86_64 apenas
  • Acesso à Internet necessário para a compilação inicial (descarrega o tarball de origem, módulos Go, pacotes Wolfi)

Requisitos Windows

Todos os comandos de compilação e carregamento funcionam em qualquer terminal (PowerShell, CMD ou bash). Ainda é necessário um shell Unix para um passo:

  • bash tests/test.sh — o script de teste usa bash e coreutils (timeout, grep, sed)

Instale o Git Bash (incluído no Git for Windows) antes de executar os testes da imagem.

Estrutura do Projeto

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

Compilação

Usando Make

make build        # keygen (se necessário) + pacote + imagem
make test         # testes do pacote + testes da imagem
make all          # compilar + testar
make clean        # remover todos os artefactos gerados
make help         # listar todos os alvos e variáveis

Comandos manuais

# 1. Gerar chaves de assinatura (única vez)
docker compose run --rm melange keygen keys/melange.rsa

# 2. Compilar o pacote APK (descarrega a origem, aplica o patch CVE, compila)
docker compose run --rm melange build melange/dasel.yaml --arch x86_64 --signing-key keys/melange.rsa

# 3. Compilar a imagem OCI (consome o APK local)
docker compose run --rm apko build apko/dasel.yaml dasel:3.3.1 dasel.tar --arch x86_64 --sbom-path sbom/

O passo 2 gera e assina automaticamente packages/x86_64/APKINDEX.tar.gz.

Executar

Após carregar a imagem, execute o dasel:

docker load --input dasel.tar

# Exemplo: consultar um ficheiro JSON
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'

Estas opções aplicam a camada de runtime da estratégia de defesa em profundidade descrita em Proteção da Imagem: sistema de ficheiros raiz imutável, zero capacidades Linux e sem caminhos de escalada de privilégios.

Teste

Usando Make

make test          # todos os testes (pacote + imagem)
make package-test  # apenas testes do pacote melange
make image-test    # apenas testes da imagem (requer bash)

Comandos manuais

# Testes do pacote
docker compose run --rm melange test melange/dasel.yaml --arch x86_64

# Testes da imagem (requer Git Bash no Windows)
docker load --input dasel.tar
bash tests/test.sh

O script de teste verifica:

  • A imagem carrega e dasel version reporta v3.3.1
  • Extração de chave JSON (-i json 'test')
  • Conversão JSON para YAML (-i json -o yaml --root)
  • Correção CVE: YAML malicioso "billion laughs" desencadeia "yaml expansion budget exceeded" em vez de ficar suspenso

Correção CVE-2026-33320

A vulnerabilidade permite consumo ilimitado de CPU/memória através de aliases YAML aninhados exponencialmente (ataque billion laughs). O patch em melange/CVE-2026-33320.patch adiciona duas medidas de segurança ao leitor YAML do dasel: um limite de profundidade de expansão (32) que limita o aninhamento recursivo de aliases, e um orçamento de expansão (1000) que limita o total de desreferências de alias por documento. Quando qualquer limite é atingido, a descodificação retorna um erro imediatamente.

Segurança, Reprodutibilidade e Minimalidade

  • Segurança: CVE-2026-33320 corrigido em tempo de compilação. Todos os pacotes são assinados. A imagem contém apenas 3 pacotes APK (wolfi-baselayout, ca-certificates-bundle, dasel)
  • Reprodutibilidade: YAML declarativo para pacote e imagem. Tarball de origem fixado por SHA256. Todas as versões de ferramentas documentadas. Binário Go compilado com -trimpath para remover caminhos de compilação locais
  • Minimalidade: Sem shell, sem gestor de pacotes na imagem final - apenas o binário dasel, certificados CA e baselayout

Proteção da Imagem

A imagem aplica defesa em profundidade além da embalagem mínima:

CamadaMedidaEfeito
CompilaçãoUtilizador não-root (UID 65532)Processo do contentor nunca executa como root
Compilação-s -w ldflags + auto -trimpathBinário reduzido, sem fuga de caminhos locais
Compilação3 pacotes apenasSuperfície de ataque mínima, sem shell ou gestor de pacotes
Runtime--read-onlySistema de ficheiros raiz imutável
Runtime--cap-drop=ALLZero capacidades Linux
Runtime--no-new-privilegesImpede escalada de privilégios via setuid/setgid

Verificação de Vulnerabilidades

A imagem construída (dasel.tar) foi analisada com ferramentas padrão da indústria para validar a postura de segurança além da correção CVE em si.

Syft (geração de SBOM)

O Syft extraiu 36 pacotes da imagem inspecionando os metadados do módulo Go do binário:

  • 3 pacotes APK: wolfi-baselayout 20230201-r29, ca-certificates-bundle 20260413-r0, dasel 3.3.1-r0
  • 32 módulos Go: incluindo 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 mais 25
  • 19 ficheiros inventariados: /usr/bin/dasel, /etc/ssl/certs/ca-certificates.crt, APK DB, SBOMs por pacote, e ficheiros de configuração do baselayout

Grype (scanner de vulnerabilidades)

O SBOM que gerei foi inspecionado com o Grype sem outras vulnerabilidades encontradas em qualquer um dos 32 módulos Go ou 3 pacotes APK.

Submissão

Pressupostos

Baixar ferramenta