master는 이동하는 브랜치가 아니라 날짜가 지정된 스냅샷입니다. 두 리비전 모두 공개 저장소에서 접근 가능하므로 bootstrap.sh는 비공개 소스 없이 어느 쪽이든 준비할 수 있습니다.

Finding 범위

이 저장소의 런타임 증거는 v3.2.6에 대한 것입니다. 아래의 더 넓은 범위는 소스 이력 검사에서 나온 것이며, 관련된 패턴은 고정된 master 스냅샷에도 남아 있습니다.

내용물

• fixtures/ - 비활성 DICOM 입력으로, manifest/expectations.json에 SHA-256으로 고정되어 있으며 모든 트리거 실행 전에 검증됨
• generators/ - 모든 픽스처에 대한 결정적이고 의존성 없는 소스 생성기
• harnesses/ - 최소한의 읽기/인코딩/디코딩 하네스; Finding 2는 gdcmconv CLI와 서버가 호출할 라이브러리 트랜스코드 API 양쪽을 통해 보여짐
• manifest/expectations.json - fixed 대상에 대한 기계 판독 가능한 명령, 결정적 신호, 수용 기준
• scripts/ - 고정 소스 준비, 새니타이저 빌드, 경계가 정해진 실행, 정리
• evidence/ - 이미 관찰된 간결한 결과로, 테스트되지 않은 대상은 명시적으로 기재됨
• LICENSE - MIT 라이선스

사전 요구사항

Git, Python 3, CMake 3.20+, Ninja, 그리고 C++11 툴체인(Clang 또는 GCC)이 있는 일회용 Linux 또는 macOS 빌드 환경. Ubuntu에서는: git python3 cmake ninja-build clang zlib1g-dev. GCC를 대신 사용하려면 CC/CXX를 설정하십시오.

소스 준비는 GDCM_SOURCE_REPO가 기존 로컬 클론을 가리키지 않는 한 HTTPS를 통해 클론합니다. SSH 호스트는 사용되지 않습니다.

준비 및 빌드

이 명령들은 소스와 빌드 산출물만 준비하며, 어떤 픽스처도 열지 않습니다.

세 번째 인수는 프로파일입니다. debug는 -O0 -g이고, release는 -O2 -g -DNDEBUG로, GDCM의 gdcm_debug_assert()를 제거하며 배포판이 라이브러리를 빌드하는 방식과 일치합니다. 두 프로파일 모두에서 매트릭스를 실행하면 유지관리자가 가장 먼저 묻는 질문, 즉 보고서가 어서션 활성화 빌드의 산물인지에 답할 수 있습니다.

GDCM_SUPPORT_BROKEN_IMPLEMENTATION=ON은 GDCM 자체의 기본값이며 그대로 둡니다. 보수적인 병렬 처리는 JOBS=8로 재정의하십시오.

모든 빌드는 build-info.json(리비전, 컴파일러, 플래그, 플랫폼)을 해당 GDCM 빌드 트리에 기록하고, 모든 실행 요약이 이를 포함하므로 보관된 증거는 자기 설명적입니다.

실행

run-matrix.sh는 모든 대상에 대해 모든 자동화 케이스를 실행하고, 첫 실패에서 멈추지 않으며, _runs/matrix-<stamp>.json과 렌더링된 _runs/matrix-<stamp>.md를 기록합니다. 2단계 f1-exploit 케이스는 수동으로 남아 있으며, 실패한 자동화 케이스로 잘못 분류되지 않고 그대로 보고됩니다.

각 자식 프로세스는 코어 덤프가 비활성화되고 15초 타임아웃이 적용되며, Finding 5는 추가로 경계가 정해진 스택 제한을 받습니다. 출력은 _runs/ 아래에 유지됩니다. 분류기는 새니타이저 클래스와 관련 함수를 일치시키며, 주소, PID, 소스 줄 번호는 절대 사용하지 않습니다.

vulnerable의 경우, 결정적 신호가 나타나고 그 대조군이 깨끗하게 유지되면 케이스가 통과합니다. master의 경우, 러너는 미리 선언된 판정 대신 관찰을 기록합니다. fixed의 경우, 신호가 없고 다른 새니타이저나 치명적 신호가 나타나지 않으며 하네스가 허용된 깨끗한 결과를 반환할 때만 케이스가 통과합니다. 이러한 규칙은 FIXED_REV가 실제 패치를 가리킬 때까지 잠정적이며, 해당 패치의 의도된 거부-또는-처리 동작에 비추어 검토되어야 합니다.

케이스

추가로 두 개의 하네스는 재현 케이스가 아니라 익스플로잇 가능성 연구이며, Linux x86-64에서 비새니타이저 프로파일로만 빌드됩니다:

보관된 증거

evidence/v3.2.6-macos-arm64-debug.md는 완료된 v3.2.6 디버그 매트릭스를 기록하며, 모든 대조군과 두 개의 경계가 정해진 Finding 3 전파 검사를 포함합니다.

evidence/v3.2.6-linux-x86_64-finding01-groom.md와 evidence/v3.2.6-linux-x86_64-finding03-leak.md는 아래의 두 익스플로잇 가능성 결과를 기록합니다. 현재 master, 전체 릴리스 프로파일 매트릭스, 그리고 f1-exploit 결과는 해당 트랜스크립트가 보관되기 전까지 주장되지 않습니다.

정리

정리는 패키지 마커 없이는 실행을 거부하며, 이 저장소 아래의 _work, _build, _generated, _runs, 그리고 Python 바이트코드 캐시만 제거합니다. evidence/ 아래의 보관된 증거는 제거되지 않습니다.

익스플로잇 프리미티브 (Finding 1)

f1-exploit은 Linux-x86_64 전용이며 수동으로 실행됩니다; manifest/expectations.json에 정확한 명령 시퀀스가 있습니다. 하네스의 결정적 할당 레이아웃에서 이는 세 가지 별개의 사실을 테스트하며, 각각에는 일치하는 부정 케이스가 있습니다:

• 오버플로가 대상 버퍼 이후에 할당자가 내준 메모리에 도달함;
• 그곳에 떨어지는 바이트가 조작된 DICOM이 요청한 정확한 바이트임. 다른 값을 심거나 일반 f1 픽스처를 사용하면 손상은 보고하지만 내용 제어는 명시적으로 아님을 보고하므로, 검사는 반증 가능함;
• 합성 희생자의 함수 포인터가 파일이 제공한 주소를 담게 되고, 이를 호출하면 하네스 내부의 함수로 제어가 전환됨.

12288바이트 오버플로 내의 8바이트 윈도우 중 약 절반이 임의 값을 받아들입니다. 나머지는 결합되어 있는데, DoYBRFull422가 하나의 소스 바이트를 두 개의 출력 위치로 복제하기 때문입니다; 오프셋 6144는 자유 윈도우 중 하나입니다. 프레임 1의 디코드가 마지막에 실행되므로, 할당 이후까지 지속되는 것은 프레임 1의 내용입니다.

하네스는 인접 객체가 수정되는 동안 ImageReader::Read()가 true를 반환하는지 기록합니다. 성공적인 Linux x86-64 트랜스크립트는 그 결과를 관찰된 증거로 설명하기 전에 보관되어야 합니다.

계측이 없을 때 일어나는 일

f1-exploit은 자체 희생자 레이아웃을 제공하므로, 수정되지 않은 프로세스가 그 레이아웃을 가지는지 답할 수 없습니다. finding01_groom은 재고 glibc, 기본 PIE, ASLR을 사용하며, 할당을 기록하지만 재배치하지는 않는 전역 할당 훅을 사용합니다. 보관된 테스트에서:

• 24576바이트 버퍼 다음의 할당은 기록된 20회 시행 모두에서 해제된 2049바이트 GDCM 스크래치 청크였습니다. 살아 있는 객체나 vtable은 관찰되지 않았습니다;
• 그 청크의 프리 리스트 메타데이터를 손상시키면 glibc 자체의 일관성 검사가 걸려 중단됩니다. 일반 finding01 하네스도 계측 없이 동일하게 죽습니다.

테스트된 glibc 빌드에서, Finding 1은 안정적으로 서비스 거부를 일으켰으며; 코드 실행 경로는 발견되지 않았습니다. 테스트된 기하는 고정되어 있었고, 다른 할당자나 플랫폼은 힙을 다르게 배치할 수 있습니다.

finding03_leak은 더 강한 결과입니다. 테스트된 빌드에서 범위를 벗어난 읽기는 131070바이트에 도달하고, gdcm::ByteValue vtable 포인터가 디코딩된 픽셀에 들어가며, 하네스는 그 빌드의 알려진 vtable 오프셋을 사용해 라이브러리 로드 베이스를 도출합니다. 이는 로컬 API 수준의 노출 결과입니다: LUT 적용과 디코딩된 픽셀 버퍼에 대한 접근이 필요합니다. 네트워크 서비스가 그 픽셀들을 반환한다는 것을 보여주지는 않습니다.

여기서 둘은 코드 실행으로 연쇄될 수 없으며, 단지 희생자가 발견되지 않았기 때문만은 아닙니다: 둘은 서로 다른 PhotometricInterpretation 값이 필요하므로 두 개의 파일이 필요하고, 유출된 베이스는 유출하는 프로세스가 아직 살아 있는 동안에만 유용합니다.

증거 경계

새니타이저 보고서는 테스트된 프로세스와 리비전에서 명시된 메모리 안전성 또는 정의되지 않은 동작 이벤트를 입증합니다. f1-exploit은 의도적으로 대상 레이아웃을 제공하는 계측된 할당자 아래에서 바이트 제어와 인접 함수 포인터 덮어쓰기를 테스트합니다. 수정되지 않은 소비자에서 그 레이아웃을 입증하지는 않습니다. 보관된 finding01_groom 시행은 테스트된 기하와 glibc 빌드에 대해 그 레이아웃을 관찰하지 못했습니다.

이 중 어느 것도 특정 제품에서의 원격 도달 가능성, 지속성, 또는 하위 적용 가능성을 입증하지 않습니다. 주어진 배포에 대한 도달 가능성 논증은 별개의 주장이며, 이 패키지가 아니라 공개 텍스트에서 이루어집니다.