gdcm-security-poc

Paquete privado de reproducción de sanitizador de extremo a extremo para seis hallazgos de GDCM

master es una instantánea con fecha, no una rama en movimiento. Ambas revisiones son accesibles desde el repositorio público, por lo que bootstrap.sh puede preparar cualquiera de ellas sin ningún código fuente privado.

Alcance de los hallazgos

La evidencia en tiempo de ejecución de este repositorio corresponde a v3.2.6. Los rangos más amplios a continuación provienen de la inspección del historial del código fuente; los patrones implicados también permanecen en la instantánea de master fijada.

Contenido

• fixtures/ - las entradas DICOM inertes, fijadas con SHA-256 en manifest/expectations.json y verificadas antes de cada ejecución de disparador
• generators/ - generadores de código fuente deterministas y sin dependencias para cada fixture
• harnesses/ - harnesses mínimos de lectura/codificación/decodificación; el hallazgo 2 se muestra tanto a través de la CLI gdcmconv como de la API de transcodificación de la biblioteca que llamaría un servidor
• manifest/expectations.json - comandos legibles por máquina, señales decisivas y criterios de aceptación para el objetivo fixed
• scripts/ - preparación de código fuente fijado, compilaciones con sanitizer, ejecución acotada, limpieza
• evidence/ - resultados concisos ya observados, con objetivos no probados declarados explícitamente
• LICENSE - licencia MIT

Requisitos previos

Un entorno de compilación Linux o macOS desechable con Git, Python 3, CMake 3.20+, Ninja y una cadena de herramientas C++11 (Clang o GCC). En Ubuntu: git python3 cmake ninja-build clang zlib1g-dev. Configure CC/CXX para usar GCC en su lugar.

La preparación del código fuente clona por HTTPS a menos que GDCM_SOURCE_REPO apunte a un clon local existente. No se utiliza ningún host SSH.

Preparar y compilar

Estos comandos preparan únicamente el código fuente y los artefactos de compilación; no abren ningún fixture.

El tercer argumento es el perfil. debug es -O0 -g; release es -O2 -g -DNDEBUG, que elimina los gdcm_debug_assert() de GDCM y coincide con cómo las distribuciones compilan la biblioteca. Ejecutar la matriz bajo ambos responde a la primera pregunta que hace un mantenedor, que es si los informes son un artefacto de una compilación con aserciones habilitadas.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON es el valor predeterminado del propio GDCM y se deja tal cual. Sobrescriba el paralelismo conservador con JOBS=8.

Cada compilación escribe build-info.json (revisión, compilador, flags, plataforma) en su árbol de compilación de GDCM, y cada resumen de ejecución lo incorpora, de modo que la evidencia archivada se describe a sí misma.

Ejecutar

run-matrix.sh ejecuta cada caso automatizado para cada objetivo, no se detiene en el primer fallo y escribe _runs/matrix-<stamp>.json además de un _runs/matrix-<stamp>.md renderizado. El caso f1-exploit de dos etapas permanece manual y se informa como tal en lugar de clasificarse erróneamente como un caso automatizado fallido.

Cada proceso hijo tiene los core dumps deshabilitados y un tiempo de espera de 15 segundos; el hallazgo 5 además recibe un límite de pila acotado. Las salidas permanecen bajo _runs/. El clasificador compara la clase de sanitizer y la función implicada, nunca direcciones, PIDs ni números de línea del código fuente.

Para vulnerable, un caso pasa cuando aparece la señal decisiva y su control permanece limpio. Para master, el ejecutor registra la observación en lugar de un veredicto predeclarado. Para fixed, un caso pasa solo cuando la señal está ausente, no aparece ningún otro sanitizer o señal fatal, y el harness devuelve un resultado limpio permitido. Estas reglas son provisionales hasta que FIXED_REV nombre un parche real; deben revisarse contra el comportamiento previsto de rechazo o procesamiento de ese parche.

Casos

Otros dos harnesses son investigación de explotabilidad en lugar de casos de reproducción, y solo se compilan en el perfil sin sanitizer en Linux x86-64:

Evidencia conservada

evidence/v3.2.6-macos-arm64-debug.md registra la matriz de depuración completa de v3.2.6, incluyendo cada control y ambas comprobaciones acotadas de propagación del hallazgo 3.

evidence/v3.2.6-linux-x86_64-finding01-groom.md y evidence/v3.2.6-linux-x86_64-finding03-leak.md registran los dos resultados de explotabilidad a continuación. Los resultados de master actual, la matriz completa del perfil de release y f1-exploit no se afirman hasta que se conserven sus transcripciones.

Limpieza

La limpieza se niega a ejecutarse sin el marcador del paquete y elimina únicamente _work, _build, _generated, _runs y las cachés de bytecode de Python bajo este repositorio. La evidencia conservada bajo evidence/ no se elimina.

Primitiva de explotación (hallazgo 1)

f1-exploit es solo para Linux-x86_64 y se ejecuta a mano; manifest/expectations.json contiene la secuencia de comandos exacta. Bajo el diseño de asignación determinista del harness, prueba tres hechos separados, cada uno con un caso negativo emparejado:

• el desbordamiento alcanza memoria que el asignador entregó después del búfer objetivo;
• los bytes que aterrizan allí son los bytes exactos que pidió el DICOM manipulado. Plantar un valor diferente, o usar el fixture f1 simple, informa corrupción pero explícitamente no control de contenido, por lo que la comprobación es falsable;
• el puntero de función de la víctima sintética termina conteniendo una dirección proporcionada por el archivo, y llamarlo transfiere el control a una función dentro del harness.

Aproximadamente la mitad de las ventanas de 8 bytes dentro del desbordamiento de 12288 bytes aceptan un valor arbitrario. El resto están acopladas, porque DoYBRFull422 duplica un byte de origen en dos posiciones de salida; el desplazamiento 6144 es una de las ventanas libres. La decodificación del fotograma 1 se ejecuta al final, por lo que es el contenido del fotograma 1 el que persiste más allá de la asignación.

El harness registra si ImageReader::Read() devuelve true mientras el objeto adyacente se modifica. Debe conservarse una transcripción exitosa de Linux x86-64 antes de describir ese resultado como evidencia observada.

Qué ocurre sin la instrumentación

f1-exploit proporciona su propio diseño de víctima, por lo que no puede responder si un proceso sin modificar tiene ese diseño. finding01_groom usa glibc estándar, PIE predeterminado y ASLR, con hooks de asignación globales que registran pero no reubican las asignaciones. En las pruebas conservadas:

• la asignación siguiente al búfer de 24576 bytes fue un fragmento de scratch de GDCM de 2049 bytes liberado en las 20 pruebas registradas. No se observó ningún objeto vivo ni vtable;
• corromper los metadatos de la lista libre de ese fragmento activa la propia comprobación de consistencia de glibc, que aborta. El harness finding01 simple muere de la misma manera sin ninguna instrumentación.

En la compilación de glibc probada, el hallazgo 1 causó de forma fiable denegación de servicio; no se encontró ninguna ruta de ejecución de código. La geometría probada era fija, y otros asignadores o plataformas pueden disponer el heap de manera diferente.

finding03_leak es el resultado más sólido. En la compilación probada, la lectura fuera de límites alcanza 131070 bytes, un puntero de vtable de gdcm::ByteValue entra en los píxeles decodificados, y el harness deriva la base de carga de la biblioteca usando el desplazamiento de vtable conocido de esa compilación. Este es un resultado de divulgación local a nivel de API: requiere la aplicación de LUT y acceso al búfer de píxeles decodificados. No demuestra que un servicio de red devuelva esos píxeles.

Los dos no pueden encadenarse en ejecución de código aquí, y no solo porque no se encontró ninguna víctima: necesitan valores de PhotometricInterpretation diferentes, por lo que necesitan dos archivos, y una base filtrada solo es útil mientras el proceso que la filtra sigue vivo.

Límite de la evidencia

Un informe de sanitizer prueba el evento declarado de seguridad de memoria o comportamiento indefinido en el proceso y la revisión probados. f1-exploit prueba el control de bytes y una sobrescritura de puntero de función adyacente bajo un asignador instrumentado que proporciona deliberadamente el diseño objetivo. No establece ese diseño en un consumidor sin modificar. Las pruebas conservadas de finding01_groom no observaron ese diseño para la geometría probada y la compilación de glibc.

Nada de esto prueba la alcanzabilidad remota en ningún producto particular, la persistencia ni la aplicabilidad posterior. El argumento de alcanzabilidad para un despliegue dado es una afirmación separada, hecha en el texto de divulgación y no por este paquete.