gdcm-security-poc

Pacote privado de reprodução de sanitizador ponta a ponta para seis descobertas do GDCM

master é um snapshot datado, não um branch móvel. Ambas as revisões são alcançáveis a partir do repositório público, então bootstrap.sh pode preparar qualquer uma sem nenhum código-fonte privado.

Escopo dos achados

A evidência de runtime neste repositório é para a v3.2.6. Os intervalos mais amplos abaixo vêm da inspeção do histórico do código-fonte; os padrões implicados também permanecem no snapshot fixado do master.

Conteúdo

• fixtures/ - as entradas DICOM inertes, com SHA-256 fixado em manifest/expectations.json e verificadas antes de cada execução de gatilho
• generators/ - geradores de código-fonte determinísticos e sem dependências para cada fixture
• harnesses/ - harnesses mínimos de leitura/codificação/decodificação; o Achado 2 é demonstrado tanto pela CLI gdcmconv quanto pela API de transcodificação da biblioteca que um servidor chamaria
• manifest/expectations.json - comandos legíveis por máquina, sinais decisivos e critérios de aceitação para o alvo fixed
• scripts/ - preparação de código-fonte fixado, builds com sanitizer, execução limitada, limpeza
• evidence/ - resultados concisos já observados, com alvos não testados declarados explicitamente
• LICENSE - licença MIT

Pré-requisitos

Um ambiente de build descartável Linux ou macOS com Git, Python 3, CMake 3.20+, Ninja e uma toolchain C++11 (Clang ou GCC). No Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. Defina CC/CXX para usar GCC em vez disso.

A preparação do código-fonte clona via HTTPS a menos que GDCM_SOURCE_REPO aponte para um clone local existente. Nenhum host SSH é usado.

Preparar e compilar

Estes comandos preparam apenas o código-fonte e os artefatos de build; eles não abrem nenhuma fixture.

O terceiro argumento é o perfil. debug é -O0 -g; release é -O2 -g -DNDEBUG, que elimina os gdcm_debug_assert() do GDCM e corresponde a como as distribuições compilam a biblioteca. Executar a matriz em ambos responde à primeira pergunta que um mantenedor faz, que é se os relatórios são um artefato de um build com assertions habilitadas.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON é o próprio padrão do GDCM e é deixado como está. Substitua o paralelismo conservador com JOBS=8.

Cada build grava build-info.json (revisão, compilador, flags, plataforma) em sua árvore de build do GDCM, e cada resumo de execução o incorpora, então a evidência arquivada é autodescritiva.

Executar

run-matrix.sh executa todos os casos automatizados para cada alvo, não para na primeira falha, e grava _runs/matrix-<stamp>.json mais um _runs/matrix-<stamp>.md renderizado. O caso f1-exploit de dois estágios permanece manual e é reportado como tal em vez de ser classificado erroneamente como um caso automatizado falho.

Cada processo filho tem core dumps desabilitados e um timeout de 15 segundos; o Achado 5 recebe adicionalmente um limite de pilha limitado. As saídas permanecem sob _runs/. O classificador corresponde à classe do sanitizer e à função implicada, nunca a endereços, PIDs ou números de linha do código-fonte.

Para vulnerable, um caso passa quando o sinal decisivo aparece e seu controle permanece limpo. Para master, o executor registra observação em vez de um veredito pré-declarado. Para fixed, um caso passa apenas quando o sinal está ausente, nenhum outro sanitizer ou sinal fatal aparece, e o harness retorna um resultado limpo permitido. Essas regras são provisórias até que FIXED_REV nomeie um patch real; elas devem ser revisadas contra o comportamento pretendido de rejeitar-ou-processar desse patch.

Casos

Dois harnesses adicionais são pesquisa de explorabilidade em vez de casos de reprodução, e compilam apenas no perfil sem sanitizer em Linux x86-64:

Evidência retida

evidence/v3.2.6-macos-arm64-debug.md registra a matriz de debug completa da v3.2.6, incluindo cada controle e ambas as verificações limitadas de propagação do Achado 3.

evidence/v3.2.6-linux-x86_64-finding01-groom.md e evidence/v3.2.6-linux-x86_64-finding03-leak.md registram os dois resultados de explorabilidade abaixo. Resultados do master atual, da matriz completa do perfil release e do f1-exploit não são reivindicados até que suas transcrições sejam retidas.

Limpeza

A limpeza se recusa a executar sem o marcador do pacote e remove apenas _work, _build, _generated, _runs e caches de bytecode Python sob este repositório. A evidência retida em evidence/ não é removida.

Primitiva de exploração (Achado 1)

f1-exploit é apenas para Linux-x86_64 e é executado manualmente; manifest/expectations.json contém a sequência exata de comandos. Sob o layout de alocação determinístico do harness, ele testa três fatos separados, cada um com um caso negativo correspondente:

• o overflow alcança memória que o alocador entregou após o buffer alvo;
• os bytes que chegam lá são exatamente os bytes que o DICOM elaborado pediu. Plantar um valor diferente, ou usar a fixture simples f1, reporta corrupção mas explicitamente não controle de conteúdo, então a verificação é falseável;
• o ponteiro de função da vítima sintética acaba contendo um endereço fornecido pelo arquivo, e chamá-lo transfere o controle para uma função dentro do harness.

Cerca de metade das janelas de 8 bytes dentro do overflow de 12288 bytes aceitam um valor arbitrário. O restante é acoplado, porque DoYBRFull422 duplica um byte de origem em duas posições de saída; o offset 6144 é uma das janelas livres. A decodificação do Frame 1 é executada por último, então é o conteúdo do frame 1 que persiste após a alocação.

O harness registra se ImageReader::Read() retorna true enquanto o objeto adjacente é modificado. Uma transcrição bem-sucedida de Linux x86-64 deve ser retida antes de descrever esse resultado como evidência observada.

O que acontece sem a instrumentação

f1-exploit fornece seu próprio layout de vítima, então não pode responder se um processo não modificado tem esse layout. finding01_groom usa glibc padrão, PIE padrão e ASLR, com hooks globais de alocação que registram mas não realocam alocações. Nos testes retidos:

• a alocação seguinte ao buffer de 24576 bytes foi um chunk de scratch do GDCM de 2049 bytes liberado em todas as 20 tentativas registradas. Nenhum objeto vivo ou vtable foi observado;
• corromper os metadados da free-list desse chunk dispara a própria verificação de consistência da glibc, que aborta. O harness simples finding01 morre da mesma forma sem nenhuma instrumentação.

No build glibc testado, o Achado 1 causou confiavelmente negação de serviço; nenhum caminho de execução de código foi encontrado. A geometria testada era fixa, e outros alocadores ou plataformas podem dispor o heap de forma diferente.

finding03_leak é o resultado mais forte. No build testado, a leitura fora dos limites alcança 131070 bytes, um ponteiro de vtable de gdcm::ByteValue entra nos pixels decodificados, e o harness deriva a base de carregamento da biblioteca usando o offset de vtable conhecido desse build. Este é um resultado de divulgação local em nível de API: requer aplicação de LUT e acesso ao buffer de pixels decodificados. Não mostra que um serviço de rede retorna esses pixels.

Os dois não podem ser encadeados em execução de código aqui, e não apenas porque nenhuma vítima foi encontrada: eles precisam de valores diferentes de PhotometricInterpretation, então precisam de dois arquivos, e uma base vazada só é útil enquanto o processo que vaza ainda está vivo.

Limite da evidência

Um relatório de sanitizer prova o evento declarado de segurança de memória ou comportamento indefinido no processo e revisão testados. f1-exploit testa controle de bytes e uma sobrescrita adjacente de ponteiro de função sob um alocador instrumentado que deliberadamente fornece o layout alvo. Ele não estabelece esse layout em um consumidor não modificado. As tentativas retidas de finding01_groom não observaram esse layout para a geometria testada e o build glibc.

Nada disso prova alcançabilidade remota em qualquer produto específico, persistência ou aplicabilidade downstream. O argumento de alcançabilidade para uma dada implantação é uma reivindicação separada, feita no texto de divulgação e não por este pacote.