mysticprayer 님의 블로그

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 8주차

mysticprayer — Tue, 26 May 2026 18:16:15 +0900

[미래내일 일경험] 테크노트 - 8주차

FuzzGate v1.0 통합 검증 및 최종 산출물 정리 | 2026.05.18 ~ 05.24

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템 (FuzzGate)
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

FuzzGate v1.0 통합 테스트 수행 (3개 백엔드 × 3개 타깃 어댑터 매트릭스 검증)
High 심각도 4건의 책임 있는 공개 절차에 따른 1차 제출 진행
단일 ZIP 번들 일괄 출력 기능 통합 및 번들 무결성 해시 이중 기록 정착
CLI 사용자 매뉴얼 작성 및 컨테이너 안전 옵션 표준 프리셋 문서화
SafeTensors numpy 변환 경로의 dtype 매핑 이슈 추가 검증 및 리포트 작성
최종 결과보고서 작성 (정량 지표 정리, 산출물 목록, 향후 확장 항목 명시)

2. 학습 및 수행 내용

2-1. FuzzGate v1.0 통합 매트릭스 검증

이번 주의 가장 큰 작업은 3개 백엔드(local-harness, libFuzzer, AFL++) × 3개 타깃 어댑터(GGUF, ONNX, SafeTensors)의 총 9가지 조합을 모두 검증하여 v1.0 출시 기준에 부합하는지 확인하는 것이었다. 각 조합에 대해 1시간 시범 퍼징을 수행하면서 백엔드 교체가 후속 단계(재현 검증, Triage, 리포트 생성)에 영향을 주지 않는지를 정량적으로 측정하였다.

백엔드 × 타깃	GGUF	ONNX	SafeTensors
local-harness	✓ PASS	✓ PASS	✓ PASS
libFuzzer	✓ PASS	✓ PASS	✓ PASS
AFL++	✓ PASS	✓ PASS	△ 조건부 PASS

9가지 조합 중 8개는 완전히 통과하였으며, AFL++ × SafeTensors 조합만 조건부 PASS로 분류되었다. 이는 SafeTensors의 공식 파서가 Rust로 작성되어 있어 AFL++의 fork 모델로는 인스트루멘테이션이 비효율적인 측면 때문이며, cargo-fuzz가 더 적합한 백엔드라는 점을 문서화하여 운영자에게 안내하도록 하였다. 이는 본질적 결함이 아닌 백엔드-타깃 조합의 특성에 가까운 사안이다.

# scripts/integration_matrix.sh - 통합 매트릭스 검증 자동화
#!/usr/bin/env bash
set -euo pipefail

BACKENDS=("local-harness" "libfuzzer" "aflpp")
TARGETS=("gguf" "onnx" "safetensors")
RESULTS_DIR="./integration_results"

for backend in "${BACKENDS[@]}"; do
  for target in "${TARGETS[@]}"; do
    echo "[*] Testing: $backend x $target"
    
    fuzzgate run \
      --backend "$backend" \
      --target "$target" \
      --workers 2 \
      --timeout 1h \
      --seeds "./corpus/$target" \
      --output "$RESULTS_DIR/${backend}_${target}" \
    || {
        echo "[!] FAILED: $backend x $target"
        continue
    }
    
    # 후속 파이프라인 통과 확인 (triage + report)
    fuzzgate triage --input "$RESULTS_DIR/${backend}_${target}"
    fuzzgate report --input "$RESULTS_DIR/${backend}_${target}"
    
    echo "[+] PASSED: $backend x $target"
  done
done

✓ 통합 매트릭스의 의의

9가지 조합 모두에서 동일한 CLI 인터페이스로 실행되고, 동일한 형식의 표준 산출물이 생성된다는 것을 데이터로 확인한 것은 "느슨한 결합과 표준 인터페이스"라는 1주차 설계 원칙이 실제로 구현되었음을 증명하는 결과이다. 새로운 백엔드나 타깃을 추가할 때도 어댑터 구현만 추가하면 8개 후속 모듈이 그대로 동작한다는 확장성을 확보했다.

2-2. 단일 ZIP 번들 일괄 출력 및 이중 무결성 해시

6주차에 구현한 증거 번들은 케이스별로 개별 zip 파일을 생성하는 구조였으나, 다수 케이스를 한 번에 외부로 전달할 때는 단일 패키지가 더 편리하다는 운영 데이터가 누적되었다. 이번 주에는 모든 reproduced 케이스를 단일 ZIP 번들로 일괄 출력하는 기능을 통합하였다.

// crates/reporter/src/bundle.rs - 단일 ZIP 번들 생성 및 이중 해시
pub fn build_master_bundle(
    cases: &[ReproducedCrash],
    output_path: &Path,
) -> Result<BundleManifest> {
    let mut zip = ZipWriter::new(File::create(output_path)?);
    let mut manifest = BundleManifest::new();
    
    for case in cases {
        // 1) 케이스별 디렉터리 생성 (poc/, repro.sh, meta.json, ...)
        let case_dir = format!("cases/{}/", case.id);
        write_case_files(&mut zip, &case_dir, case)?;
        
        // 2) 케이스 단위 해시 (압축 직전 시점)
        let case_hash = sha256_of_case(case)?;
        manifest.add_case(&case.id, &case_hash);
    }
    
    // 3) manifest.json 자체도 번들에 포함
    zip.start_file("manifest.json", FileOptions::default())?;
    zip.write_all(&serde_json::to_vec_pretty(&manifest)?)?;
    zip.finish()?;
    
    // 4) 번들 자체의 해시 (압축 직후 시점) - 별도 파일로 보관
    let bundle_hash = sha256_file(output_path)?;
    let hash_file = output_path.with_extension("zip.sha256");
    fs::write(&hash_file, format!("{}  {}\n",
        bundle_hash, output_path.file_name().unwrap().to_string_lossy()))?;
    
    Ok(manifest)
}

이중 무결성 정책은 다음 두 가지 시점에 해시를 산출한다.

케이스 단위 해시 (압축 직전): 각 케이스의 meta.json에 기록되어, 케이스 내부의 파일 조합이 변경되지 않았음을 검증
번들 단위 해시 (압축 직후): 별도의 .zip.sha256 파일로 보관되어, 외부 전달 과정에서 zip 파일 자체가 변조되지 않았음을 검증

또한 번들 파일명에 해시 일부(앞 8자)를 포함하도록 명명 규칙을 정착시켰다. 예를 들어 fuzzgate-bundle-v1.0-20260520-a3f9c2b1.zip처럼 외부 분석자가 받은 파일이 어떤 버전의 번들인지 빠르게 식별할 수 있게 된다.

2-3. 1차 책임 있는 공개 절차 진행

7주차에 검토를 완료한 High 심각도 4건에 대해, 각 프로젝트의 보안 정책 절차에 따라 1차 제출을 진행하였다. 제출은 본인이 직접 수행하지 않고 신숙우 팀장이 팀 대표로 진행하였으며, 본인은 제출 리포트의 기술적 정확성을 최종 검토하는 역할을 담당하였다.

크래시 ID	대상 프로젝트	제출 채널	상태
GGUF-001	llama.cpp	SECURITY.md 권고 채널	접수 확인
GGUF-003	llama.cpp	SECURITY.md 권고 채널	접수 확인
ONNX-D-001	onnxruntime	Microsoft MSRC	접수 확인 (티켓 번호 부여)
ONNX-D-004	onnxruntime	Microsoft MSRC	접수 확인 (티켓 번호 부여)

⚠️ 책임 있는 공개 정책 준수

90일 비공개 기간: 제출일로부터 90일 동안 취약점 세부사항을 외부에 공개하지 않음
본 테크노트 처리: 크래시 ID 외 세부 코드 위치, 정확한 트리거 입력, ASan 로그 원본은 본 시리즈에 포함하지 않음
커뮤니케이션 단일 창구: 메인테이너와의 연락은 신숙우 팀장이 담당하여 정보 일관성 유지
패치 검증 협력: 메인테이너 측에서 패치 후보를 공유할 경우 본인이 동일 입력으로 재현 테스트를 수행하기로 협의

2-4. CLI 사용자 매뉴얼 및 안전 옵션 표준 프리셋 문서화

v1.0 출시 산출물로 외부 사용자가 도구를 운영할 수 있도록 CLI 매뉴얼과 컨테이너 안전 옵션 표준 프리셋 문서를 작성하였다. 매뉴얼은 다음 4개 핵심 명령을 중심으로 구성하였다.

# 1) run - 퍼징 실행 (백엔드/타깃/시드 지정)
fuzzgate run \
  --backend <local-harness|libfuzzer|aflpp> \
  --target  <gguf|onnx|safetensors> \
  --workers <N> \
  --timeout <duration> \
  --seeds   <corpus_dir> \
  --output  <result_dir> \
  [--safety-preset standard|strict|relaxed]

# 2) triage - 재현 검증 및 단계 라벨 산출
fuzzgate triage \
  --input  <result_dir> \
  --repeat 3 \
  [--label-strict]

# 3) report - reproduced 케이스에 대해 리포트 자동 생성
fuzzgate report \
  --input    <result_dir> \
  --template hackerone-5section \
  --bundle   <output.zip>

# 4) replay - 증거 번들 한 줄 재현
fuzzgate replay --bundle <bundle.zip> --case <case_id>

컨테이너 안전 옵션 표준 프리셋은 3단계로 정의하였다. 각 프리셋이 적용된 안전 옵션 목록은 케이스의 meta.json에 함께 기록되어, 외부 분석자가 재현할 때 동일한 환경을 구성할 수 있도록 한다.

프리셋	주요 옵션	사용 시나리오
standard	cap_drop=ALL, network=none, mem=2g	일반 운영 환경 (기본값)
strict	standard + read-only, pids_limit=256, seccomp 강화	신뢰도 높은 재현 검증 필요 시
relaxed	cap_drop 최소화, ptrace 허용	디버깅용 (외부 보고 비추천)

2-5. SafeTensors numpy 변환 경로 추가 검증

7주차에 발견한 SafeTensors Python 바인딩의 dtype 매핑 이슈를 24시간 장시간 퍼징으로 재검증하였다. 결과적으로 동일 패턴의 변환 경로 이슈가 추가로 2건 더 발견되어 총 4건으로 정리되었으며, 모두 Triage를 거쳐 고유 크래시로 정규화되었다.

발견된 4건 중 2건은 Rust 코어가 아닌 Python 바인딩 계층에서만 발생하는 케이스로, "안전한 코어를 감싸는 외피의 검증 누락"이라는 가설을 데이터로 다시 한 번 확인하였다. 이 케이스들은 메모리 안전성 위반이 아니라 변환 단계의 입력 검증 누락에 해당하므로, 별도 카테고리("Binding Validation")로 리포트되어 멘토님이 권고한 분류 방식을 적용하였다.

v1.0의 최종 누적 결과 (8주 종합)

총 누적 퍼징 시간	약 480시간 (3개 타깃 합산)
예비 크래시 수집	총 64건
고유 크래시 (Triage 후)	총 22건
reproduced 라벨 (리포트 생성)	총 16건
1차 책임 있는 공개 진행	High 심각도 4건

2-6. 최종 결과보고서 작성 및 향후 확장 항목 정리

8주간의 모든 활동을 정리한 최종 결과보고서를 팀 전체가 함께 작성하였다. 본인은 하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현 영역에 해당하는 기술 섹션과 정량 지표 항목을 담당하였다. 결과보고서에는 v1.0 산출물 목록과 함께 후속 단계에서 발전시킬 수 있는 향후 확장 항목을 명시하였다.

FuzzGate v1.0 최종 산출물 (본인 담당 영역)

다중 백엔드(local-harness / libFuzzer / AFL++) 통합 CLI
다중 타깃 어댑터(GGUF / ONNX / SafeTensors)
구조 인지 변이 전략 (단일 필드 + cross-field + 양자화 메타데이터)
하네스 빌드 자동화 (CMake + Cargo build.rs 통합)
하네스 내부 watchdog/timeout 로직
시드 코퍼스 미니마이제이션 워크플로우
HarnessFingerprint JSON 출력 (재현 가능성 보강)

향후 확장 항목 (본인 담당 영역)

exploitability signal 분류기 가중치 재조정 (정량 지표 누적 후)
cargo-fuzz 백엔드 정식 추가 (현재는 SafeTensors 전용 임시 구현)
타깃 어댑터 확장 (PyTorch pickle, TensorFlow SavedModel 등)
구조 인지 변이의 PoC 단계 전략을 정식 모듈로 승격
분산 퍼징 지원 (다중 호스트 작업 큐 도입)

️ 3. 수행 활동

3-1. 개인 수행 활동

FuzzGate v1.0 통합 매트릭스 검증 수행 (9개 조합 중 8개 PASS, 1개 조건부 PASS)
통합 매트릭스 자동화 스크립트(integration_matrix.sh) 작성 및 CI 통합
단일 ZIP 번들 일괄 출력 기능 통합 (Reporter 모듈과 협업)
이중 무결성 해시 정책 정착 (케이스 단위 + 번들 단위, 파일명 해시 prefix)
1차 책임 있는 공개 제출 4건의 기술적 정확성 최종 검토
CLI 매뉴얼 작성 (4개 핵심 명령 사용법 + 백엔드/타깃별 옵션 매트릭스)
컨테이너 안전 옵션 표준 프리셋 3단계(standard/strict/relaxed) 정의 및 문서화
SafeTensors 24시간 장시간 퍼징 결과 분석 (Binding Validation 카테고리 4건 확정)
최종 결과보고서 기술 섹션 및 정량 지표 항목 작성

3-2. 팀 활동

온라인 정기 미팅 (05.20, Discord): 통합 매트릭스 검증 결과와 1차 제출 진행 상황을 공유. AFL++ × SafeTensors 조건부 PASS 케이스에 대해 cargo-fuzz 백엔드 정식 추가를 향후 확장 항목으로 등재하기로 합의
최종 정리 회의 (05.22): 팀 전체가 모여 결과보고서 초안을 검토하고, 각자 담당 영역의 산출물 목록을 최종 확정. 본인은 다중 백엔드 통합 CLI와 다중 타깃 어댑터 영역의 기술 섹션 작성을 담당
신숙우 팀장과 1차 제출 공조 (05.18~05.19): 4건의 책임 있는 공개 제출 진행 중 기술적 질의가 발생할 경우 즉시 답변할 수 있도록 본인이 대기. 메인테이너와의 커뮤니케이션 단일 창구는 신숙우 팀장이 담당
전선정 팀원과 회고 (05.23): 8주간의 협업을 돌아보며 인터페이스 설계 과정에서 배운 점을 공유. 특히 단계 라벨 시스템 도입 시 코드와 문서 양쪽에 라벨 정의를 명시하는 정책이 정착된 것을 핵심 성과로 정리
황희주 팀원과 매뉴얼 검토 (05.24): CLI 매뉴얼이 외부 사용자 관점에서 충분히 친절한지 함께 검토. Report Generator 측의 템플릿 선택 옵션도 매뉴얼에 누락되지 않도록 보강
최종 멘토링 세션 (05.24): 멘토로부터 v1.0의 완성도와 통합 매트릭스 검증 절차에 대한 전반적 긍정 평가를 받음. 또한 결과보고서의 "향후 확장 항목"이 단순한 기술 목록이 아니라 실제 후속 단계로 이어질 수 있는 구체적인 경로로 작성되었다는 점이 인상적이라는 피드백 수령

4. 프로젝트 종료에 즈음하여

8주간의 활동을 마무리하며

1주차에 노션에 그렸던 5단계 파이프라인이 8주를 거쳐 FuzzGate v1.0이라는 실제 동작하는 시스템으로 완성되었다. 9가지 백엔드 × 타깃 조합 검증 통과, 16건의 reproduced 케이스 확보, 4건의 책임 있는 공개 제출까지 모두 일정 안에 완료되었다.

본 시리즈는 이번 8주차 테크노트로 종료되며, 결과보고서와 본인의 회고는 별도 문서로 공유한다. 책임 있는 공개 진행 상황(90일 비공개 기간)과 향후 확장 항목 진행 현황은 후속 단계에서 별도 채널을 통해 공유될 예정이다.

5. 느낀점 및 회고

8주차는 8주간 만들어 온 모든 것이 "FuzzGate v1.0"이라는 하나의 이름으로 정리되는 한 주였다. 1주차에 빈 디렉터리에서 출발했던 프로젝트가, 마지막 주에는 3개 백엔드 × 3개 타깃이 동일한 CLI로 동작하고 16건의 reproduced 케이스를 자동 리포트로 산출하며 책임 있는 공개 절차까지 진행되는 시스템이 되었다는 것이 아직도 실감이 잘 나지 않는다. 특히 통합 매트릭스 검증을 수행하면서 9개 조합이 모두 동일한 후속 파이프라인을 그대로 통과하는 것을 보았을 때, 1주차에 "느슨한 결합과 표준 인터페이스"를 설계 원칙으로 정한 결정이 8주 뒤에 어떤 결과를 만들어내는지를 직접 경험할 수 있었다.

단일 ZIP 번들과 이중 무결성 해시 작업은 보안 도구의 본질이 "신뢰의 전달 가능성"이라는 것을 다시 한 번 일깨워 주었다. 도구가 아무리 많은 크래시를 찾아도, 외부 분석자가 그 결과를 신뢰하고 재현할 수 없다면 의미가 없다. 케이스 단위 해시와 번들 단위 해시를 분리하여 압축 직전과 직후 시점을 각각 보장하는 정책은 처음에는 과한 것 같았지만, 외부에 결과물이 전달되는 순간을 상상해 보니 두 시점의 무결성을 모두 검증할 수 있어야 한다는 결론이 자연스러웠다. 보안 도구는 자기 자신의 출력 경로에서 새로운 위험을 만들지 않아야 한다는 결과보고서의 원칙이 작은 디테일 하나하나에 녹아드는 과정을 본 것 같다.

1차 책임 있는 공개 제출은 이번 프로젝트에서 가장 긴장되면서도 의미 있는 순간이었다. 학교 과제나 내부 테스트가 아니라 실제 사용 중인 오픈소스 프로젝트에 우리가 발견한 결과를 공식적으로 보내는 행위는, 8주간 만든 도구가 보안 생태계의 작은 일부로 기여할 수 있다는 가능성을 보여 주었다. 메인테이너로부터 접수 확인을 받은 순간, "도구를 만든 것"과 "도구로 가치를 만든 것"이 다르다는 것을 체감했다. 도구의 마지막 가치는 결국 그것이 외부 세계와 만나는 지점에서 결정된다는 점에서, 8주차의 제출은 단순한 절차가 아니라 프로젝트 전체의 의미를 완성하는 순간이었다.

CLI 매뉴얼과 안전 옵션 프리셋을 정리하면서, "잘 만든 도구"와 "잘 전달된 도구"가 다르다는 것을 새삼 느꼈다. 기술적으로 완성도가 높아도 외부 사용자가 한 시간 안에 시작할 수 없다면 그 도구는 실질적으로 사용되지 않는다. standard / strict / relaxed 3단계 프리셋을 정의한 것도, 사용자가 보안 요구사항과 운영 편의성 사이에서 매번 선택을 고민하지 않도록 의사결정 비용을 줄여 주려는 의도였다. 인프라 작업, 매뉴얼 작성처럼 화려해 보이지 않는 일들이 결국 도구가 살아남느냐를 결정한다는 패턴은 4주차의 빌드 자동화부터 마지막 주의 매뉴얼 작성까지 일관되게 확인된 교훈이다.

8주를 돌아보면, 가장 크게 변한 것은 코드를 짜는 능력이 아니라 "시스템을 시스템으로 생각하는 방식"이었다. 1주차에는 하네스 하나를 어떻게 잘 만들지가 가장 큰 고민이었다면, 8주차에는 하나의 모듈을 추가할 때 후속 단계 전체에 미치는 영향을 자연스럽게 함께 떠올리게 되었다. 인터페이스를 정의하는 일이 코드를 짜는 일보다 더 큰 결정이라는 것, 표준화된 약속이 새로운 확장의 토대가 된다는 것, 그리고 일관된 결과를 보장하는 정책이 도구의 신뢰도를 만든다는 것을 8주간 반복해서 체감했다. 이 변화는 어떤 기술 스택보다도 오래 남을 자산이 될 것이라는 생각이 든다.

마지막으로, 이 프로젝트가 단순한 학기 활동이 아니라 진로의 방향을 가르쳐 준 경험이었다는 점을 기록해 두고 싶다. AI 모델 공급망 보안이라는 영역이 가진 사회적 의미, 자동화된 보안 도구가 만들어낼 수 있는 효율의 가치, 그리고 책임 있는 공개 절차를 통해 외부 생태계에 기여하는 행위의 무게를 직접 경험할 수 있었다. 8주 전에는 단지 "퍼징을 해 보자"였던 출발이, 8주 뒤에는 "보안 엔지니어로서 어떤 일을 하고 싶은가"라는 질문에 대한 구체적인 답을 갖게 해 주었다. 함께한 The First 팀원들과 멘토님께 감사드리며, FuzzGate v1.0이 후속 단계에서도 계속 발전하기를 바라며 본 프로젝트를 마친다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 7주차

mysticprayer — Mon, 18 May 2026 14:49:34 +0900

[미래내일 일경험] 테크노트 - 7주차

AFL++ 백엔드 통합 및 1차 제출 준비 | 2026.05.11 ~ 05.17

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템 (FuzzGate)
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

AFL++ 백엔드 통합을 위한 어댑터 구조 설계 및 구현 (libFuzzer와의 결과 데이터 형식 차이 흡수)
백엔드 공통 파라미터(워커 수, 타임아웃, 재시작 한계)를 단일 CLI 플래그로 노출
단계 라벨 시스템(reproduced / not_reproduced / partial / timeout / flaky) 정식 도입
High 심각도 4건에 대한 RCE 가능성 정밀 분석 및 1차 제출 후보 리포트 본문 검토
SafeTensors Python 바인딩 하네스 추가 구현 (numpy/torch 변환 경로)
GGUF 양자화 메타데이터 뮤테이션 전략 추가 (Q4_K, Q5_K 분기 도달)

2. 학습 및 수행 내용

2-1. AFL++ 백엔드 통합 및 어댑터 구조 설계

지금까지 FuzzGate는 libFuzzer 백엔드만 지원하여 인프로세스 퍼징에 특화된 결과만 다룰 수 있었다. 그러나 AFL++는 fork 기반 실행 모델과 더 강력한 변이 엔진을 제공하므로, 동일 타깃에서도 libFuzzer와 다른 종류의 크래시를 발견하는 경우가 많다. 운영자가 분석 목표에 따라 백엔드를 선택할 수 있도록 만드는 것이 v1.0의 핵심 요구사항이었다.

문제는 두 백엔드의 실행 모델과 결과 데이터 형식이 완전히 다르다는 점이다. libFuzzer는 자체 형식의 크래시 입력을 단일 파일로 출력하는 반면, AFL++는 crashes/, queue/, hangs/ 등 별도 디렉터리 구조에 결과를 저장한다. 후속 단계인 재현 검증과 Triage가 백엔드 차이를 신경 쓰지 않도록, 어댑터 계층에서 결과 파일을 표준화된 위치와 형식으로 정리해 전달하는 구조를 설계하였다.

// crates/fuzzer-bridge/src/backend.rs - 백엔드 공통 인터페이스
pub trait FuzzBackend: Send + Sync {
    /// 백엔드 식별자 (libfuzzer / aflpp / local-harness)
    fn name(&self) -> &'static str;

    /// 퍼징 실행 (공통 파라미터를 환경 변수 템플릿으로 변환)
    fn run(&self, cfg: &FuzzConfig) -> Result<BackendHandle>;

    /// 백엔드 고유 결과 디렉터리 → 표준 CrashArtifact 목록으로 변환
    fn normalize_results(&self, raw_dir: &Path)
        -> Result<Vec<CrashArtifact>>;

    /// 컨테이너 안전 옵션 프리셋 (read-only, network=none, cap_drop 등)
    fn safety_preset(&self) -> &SafetyPreset;
}

// AFL++ 어댑터 구현
impl FuzzBackend for AflPlusPlusBackend {
    fn normalize_results(&self, raw_dir: &Path)
        -> Result<Vec<CrashArtifact>> {
        let mut artifacts = Vec::new();
        let crashes_dir = raw_dir.join("default/crashes");

        for entry in fs::read_dir(&crashes_dir)? {
            let path = entry?.path();
            // AFL++ 파일명: id:000042,sig:06,src:000001,op:havoc,...
            // → 표준 CrashArtifact로 변환
            if let Some(meta) = parse_aflpp_filename(&path) {
                artifacts.push(CrashArtifact {
                    crash_id: format!("aflpp_{:06}", meta.id),
                    input_path: path.clone(),
                    input_sha256: sha256_file(&path)?,
                    backend: "aflpp".into(),
                    signal: meta.signal,
                    mutation_op: meta.op,
                    discovered_at: Utc::now(),
                });
            }
        }
        Ok(artifacts)
    }
}

공통 파라미터(워커 수, 타임아웃, 재시작 한계)는 단일 CLI 플래그로 노출하였다. 운영자는 --backend aflpp 또는 --backend libfuzzer만 바꿔도 동일한 워크플로우로 퍼징을 실행할 수 있다.

# 동일 타깃에 대해 백엔드만 교체 실행 (CLI 인터페이스 동일)
fuzzgate run \
  --target gguf \
  --backend aflpp \
  --workers 4 \
  --timeout 24h \
  --seeds ./corpus/gguf \
  --output ./results/gguf_aflpp

fuzzgate run \
  --target gguf \
  --backend libfuzzer \
  --workers 4 \
  --timeout 24h \
  --seeds ./corpus/gguf \
  --output ./results/gguf_libfuzzer

✓ 어댑터 구조의 검증

GGUF 타깃에 대해 AFL++ 백엔드로 8시간 시범 퍼징을 수행한 결과, libFuzzer에서는 발견하지 못했던 fork 모델 특유의 환경에서만 재현되는 크래시 3건이 추가로 발견되었다. 어댑터를 통해 이 3건은 자동으로 표준 CrashArtifact 형식으로 변환되어 기존 재현 검증 · Triage · Report Generator 파이프라인을 그대로 통과했다. 백엔드 교체가 후속 단계에 전혀 영향을 주지 않음을 데이터로 확인한 것이다.

2-2. 단계 라벨 시스템 정식 도입

6주차까지는 재현 검증 결과를 "안정 재현 / 부분 재현 / 재현 실패"의 3단계로 비공식 분류해 왔으나, AFL++ 통합으로 백엔드별 비결정성 패턴이 다양해지면서 보다 정밀한 라벨 체계가 필요해졌다. 결과보고서 설계 원칙에 따라 5단계 단계 라벨 시스템을 정식 도입하였다.

라벨	의미	후속 처리
reproduced	N회 시도 전체에서 동일 시그니처 일관 발생	리포트 생성 대상
not_reproduced	N회 모두 재현 불가	manual_review 큐
partial	결과 유형이 시도마다 다르나 일정한 경향성 존재	manual_review 큐
timeout	정해진 시간 내 결과 확정 불가	manual_review 큐
flaky	일부 시도에서만 크래시 발생 (비결정적)	manual_review 큐

하네스 측에서는 단계 라벨 산출에 필요한 정보를 정확히 전달하도록 출력 구조를 개선하였다. 특히 N회 반복 실행 시 각 시도의 종료 신호, 스택 상위 3프레임, 실행 시간을 모두 기록하여 Reproducer가 라벨을 결정론적으로 산출할 수 있도록 한다.

⚠️ 라벨 정의의 일관성 정책

초기에는 라벨 정의를 코드에만 두었더니, 운영 데이터가 누적되면서 분석자마다 라벨 의미를 다르게 해석하는 문제가 발생했다. 이번 주부터는 라벨 정의를 코드와 문서 양쪽에 명시하고, 라벨 산출에 사용된 입력 데이터를 디스크에 함께 보존하도록 정책을 정착시켰다. 동일 입력에 대해 라벨 결과가 시점에 따라 다르게 부여되지 않도록 하기 위한 조치다.

2-3. High 심각도 4건 RCE 가능성 정밀 분석

6주차에 우선 제출 후보로 분류한 High 심각도 4건(GGUF-001, GGUF-003, ONNX-D-001, ONNX-D-004)에 대해 RCE 가능성 정밀 분석을 수행하였다. 분석은 ASan 로그상의 메모리 오염 패턴, 종료 시점의 레지스터 상태, 그리고 크래시 위치의 코드 컨텍스트를 종합적으로 검토하는 방식으로 진행하였다.

크래시 ID	유형	RCE 가능성 평가	CVSS 추정
GGUF-001	Heap Buffer Overflow	쓰기 가능 영역, 입력 통제 가능 → RCE 가능성 높음	8.8 (High)
GGUF-003	Integer Overflow → OOB Write	정수 연산 결과로 인접 객체 손상 → 메모리 손상 후속 활용 가능	8.1 (High)
ONNX-D-001	Heap UAF (shape inference)	해제된 객체 재사용 시점 통제 가능 → RCE 가능성 있음	7.8 (High)
ONNX-D-004	Type Confusion	타입 혼동으로 인접 메모리 해석 변경 → 정보 유출 + RCE 가능성	8.3 (High)

각 케이스의 CVSS 추정치는 exploitability signal 분류기가 산출한 권고형 라벨로, 최종 심각도는 외부 보안팀의 평가에 따른다. 본 프로젝트의 분류기는 ASan/UBSan 로그 패턴, 종료 신호, 스택 깊이를 가중치 점수로 결합해 분류하며, 사용자가 분류 결과를 단정적으로 해석하지 않도록 표현 정책을 함께 적용한다.

2-4. 1차 제출 후보 리포트 본문 검토

자동 생성된 리포트 4건의 본문을 인간이 직접 검토하면서, 자동 생성 시스템이 놓친 표현상의 미흡한 부분을 보완하였다. 특히 "Suggested Fix" 섹션은 v1.0 단계에서는 수동 작성을 전제로 두고 있으므로, 자동 생성된 권고형 분류 결과를 참고하여 분석자가 직접 작성하였다.

검토 과정에서 다음과 같은 보완 작업을 진행하였다.

Title 표준화: 시그니처와 포맷 정보를 결합한 명명 규칙(예: [GGUF] Heap Buffer Overflow in gguf_init_from_file)으로 통일하여 외부 보고 시 식별성 확보
Impact 섹션 정제: 자동 생성된 CVSS 추정치는 권고형임을 명시하고, 실제 공격 시나리오를 분석자 관점에서 추가 서술
Steps to Reproduce 검증: 증거 번들의 reproduce.sh를 클린 환경에서 실제로 실행하여 리포트의 재현 절차가 동작함을 확인
책임 있는 공개 절차 명시: HackerOne 정책에 따라 90일 비공개 기간을 본문에 명시하고, 연락처 정보 보강

2-5. SafeTensors Python 바인딩 하네스 구현

6주차 멘토링에서 받은 조언에 따라, SafeTensors의 Python 바인딩 변환 경로를 별도 하네스로 구현하였다. Rust 코어 자체는 메모리 안전성이 보장되지만, Python 바인딩이 numpy/torch 배열로 변환하는 과정에서는 dtype 매핑, 버퍼 복사, 메모리 뷰 처리 등 새로운 공격 표면이 존재한다.

# fuzz/fuzz_safetensors_python.py - atheris 기반 Python 바인딩 하네스
import atheris
import sys

with atheris.instrument_imports():
    from safetensors import safe_open
    from safetensors.numpy import load as np_load
    from safetensors.torch import load as torch_load
    import io

def test_one_input(data: bytes):
    if len(data) < 8:
        return
    
    buf = io.BytesIO(data)
    
    # 1. numpy 변환 경로
    try:
        np_tensors = np_load(data)
        # 모든 텐서에 접근하여 lazy 변환 트리거
        for k, v in np_tensors.items():
            _ = v.shape, v.dtype
    except (ValueError, OSError, MemoryError):
        pass  # 정상 거부
    
    # 2. torch 변환 경로
    try:
        torch_tensors = torch_load(data)
        for k, v in torch_tensors.items():
            _ = v.shape, v.dtype
    except (ValueError, RuntimeError, OSError):
        pass

atheris.Setup(sys.argv, test_one_input)
atheris.Fuzz()

2시간 시범 퍼징 결과, numpy 변환 경로에서 흥미로운 신호 2건이 포착되었다. 하나는 특정 dtype 조합에서 numpy가 음수 크기를 가진 배열을 생성하려 시도하다 발생하는 OverflowError이고, 다른 하나는 헤더에 선언된 텐서 크기와 실제 데이터 크기가 일치하지 않을 때 발생하는 메모리 뷰 손상이었다. 두 케이스 모두 Rust 코어가 아닌 바인딩 계층의 검증 누락에서 비롯된 것으로, "안전한 코어를 감싸는 외피의 공격 표면"이라는 가설을 데이터로 확인하였다.

2-6. GGUF 양자화 메타데이터 뮤테이션 전략 추가

6주차의 llvm-cov 분석에서 식별된 정체 영역인 GGUF 양자화 메타데이터 처리 분기(Q4_K, Q5_K, Q8_0 등)에 도달하는 신규 뮤테이션 전략을 추가하였다. 기존 cross-field 뮤테이터에 양자화 타입을 명시적으로 변형하는 케이스를 추가하여, 파서가 양자화별 분기 처리 로직을 본격적으로 탐색하도록 유도하였다.

// 양자화 타입 명시 변형 (GGML_TYPE_Q4_K, Q5_K, Q8_0 등을 의도적으로 지정)
size_t mutate_quantization_type(uint8_t *data, size_t size,
                                size_t max_size, struct gguf_view *view) {
    if (view->tensor_count == 0) return size;
    
    // GGML 양자화 타입 enum (일부)
    static const uint32_t quant_types[] = {
        2,  // GGML_TYPE_Q4_0
        3,  // GGML_TYPE_Q4_1
        12, // GGML_TYPE_Q4_K
        13, // GGML_TYPE_Q5_K
        8,  // GGML_TYPE_Q8_0
        9,  // GGML_TYPE_Q8_1
        14, // GGML_TYPE_Q6_K
    };
    
    struct tensor_info *t = &view->tensors[0];
    uint32_t qtype = quant_types[rand() % (sizeof(quant_types)/sizeof(uint32_t))];
    memcpy(data + t->type_offset, &qtype, sizeof(uint32_t));
    
    // 양자화 블록 크기에 맞지 않는 데이터 크기를 함께 유도
    // → 양자화별 블록 정렬 검증 분기 도달
    return size;
}

신규 뮤테이션 전략을 적용한 4시간 비교 퍼징 결과, 양자화 메타데이터 처리 분기의 진입률이 8% 미만에서 34%까지 상승하였다. 또한 Q4_K 양자화 블록의 super-block 크기 계산 분기에서 새로운 예비 크래시 2건이 발견되어, 신규 분기 도달이 곧 신규 결함 발견으로 이어졌다.

️ 3. 수행 활동

3-1. 개인 수행 활동

AFL++ 백엔드 어댑터 구현 (FuzzBackend trait 기반, 결과 디렉터리 정규화 로직 포함)
백엔드 공통 파라미터를 단일 CLI 플래그로 노출 (--backend, --workers, --timeout)
단계 라벨 시스템(reproduced/not_reproduced/partial/timeout/flaky) 산출에 필요한 하네스 출력 보강
High 심각도 4건 RCE 가능성 정밀 분석 및 CVSS 추정치 산출
1차 제출 후보 리포트 4건의 본문 검토 및 표준 명명 규칙 적용
SafeTensors Python 바인딩 하네스 신규 구현 (atheris 기반, numpy/torch 변환 경로 커버)
GGUF 양자화 메타데이터 뮤테이션 전략 추가 및 비교 퍼징 수행 (정체 분기 진입률 8% → 34%)

3-2. 팀 활동

온라인 정기 미팅 (05.17, Discord): AFL++ 백엔드 통합 결과와 High 4건 분석 결과를 공유, 1차 제출 일정을 다음 주 초로 확정. 단계 라벨 정식 도입에 대한 팀 합의
전선정 팀원과 페어 작업 (05.13~05.14): 단계 라벨 시스템 도입을 위해 Reproducer의 라벨 산출 로직을 함께 설계. N회 시도 결과 분포에 따른 분기 트리(reproduced → flaky → partial → not_reproduced)를 코드와 문서 양쪽에 명시
신숙우 팀장·황희주 팀원과 협업 (05.15): 1차 제출 후보 리포트의 본문을 함께 검토. 특히 Title 표준화와 Suggested Fix 작성 가이드라인을 합의하여, 향후 리포트 품질이 작성자에 따라 달라지지 않도록 정책화
멘토링 세션 (05.16): 멘토로부터 AFL++ 어댑터 구조가 "백엔드 교체가 후속 단계에 영향을 주지 않는 설계"라는 점에서 v1.0의 핵심 기여라는 평가를 받음. 또한 Python 바인딩 하네스에서 발견된 dtype 매핑 이슈는 numpy 생태계 전반에 영향을 줄 수 있어 별도 카테고리로 분류하라는 조언 수령
책임 있는 공개 절차 사전 협의: 1차 제출에 앞서 llama.cpp·onnxruntime 프로젝트 메인테이너에게 사전 연락 채널을 확보. 제출 후 90일 비공개 기간 동안의 커뮤니케이션 책임을 신숙우 팀장이 담당하기로 분담

4. 다음 주 계획 (8주차)

계획서상 8주차 키워드: "FuzzGate v1.0 통합 검증 및 최종 산출물 정리"

High 심각도 4건의 1차 제출 진행 (llama.cpp 2건, onnxruntime 2건)
FuzzGate v1.0 통합 테스트 수행 (3개 백엔드 × 3개 타깃 어댑터 매트릭스 검증)
단일 ZIP 번들 일괄 출력 기능 통합 및 번들 무결성 해시 이중 기록 정착
CLI 사용자 매뉴얼 작성 및 컨테이너 안전 옵션 표준 프리셋 문서화
SafeTensors numpy 변환 경로의 dtype 매핑 이슈 추가 검증 및 리포트 작성
최종 결과보고서 작성 (정량 지표 정리, 산출물 목록, 향후 확장 항목 명시)

5. 느낀점 및 회고

7주차는 "FuzzGate가 단일 백엔드 도구에서 진정한 의미의 플랫폼으로 확장된 한 주"였다. AFL++ 어댑터를 구현하면서 가장 크게 느낀 것은, 6주에 걸쳐 다듬어 온 표준 인터페이스(CrashArtifact, ReproducedCrash)의 가치였다. 만약 이 인터페이스가 없었다면 AFL++ 통합은 단순히 어댑터 하나 추가가 아니라 후속 단계 전체를 다시 작성해야 하는 작업이 되었을 것이다. "느슨한 결합과 표준 인터페이스"라는 1주차의 설계 원칙이, 7주차에 와서야 그 효과를 온전히 드러냈다는 점이 가장 인상적이었다.

단계 라벨 시스템을 정식 도입하면서, "분류는 단순한 라벨 붙이기가 아니라 후속 의사결정의 출발점"이라는 것을 다시 한 번 체감했다. 초기에는 라벨 정의를 코드에만 두었더니 분석자마다 해석이 달라지는 문제가 있었고, 이를 코드와 문서 양쪽에 명시하고 라벨 산출 입력 데이터를 함께 보존하는 정책으로 정착시켰다. 이는 단순한 엔지니어링 결정이 아니라 "도구가 일관된 결과를 산출하기 위한 거버넌스"에 가깝다는 생각이 들었다. 보안 도구는 사용자의 신뢰 위에서만 작동하므로, 같은 입력에 다른 결과가 나오지 않게 만드는 것이 가장 근본적인 요구사항이었다.

High 심각도 4건의 RCE 가능성 분석은 이번 프로젝트에서 가장 긴장된 작업이었다. 자동 분류기가 산출한 "High"라는 라벨을 그대로 받아들이지 않고, ASan 로그 한 줄씩 검토하면서 실제로 공격자가 통제 가능한 메모리 영역인지를 판단하는 과정은, 6주 동안 만들어 온 자동화 도구에 "분석자의 판단"이라는 마지막 검증 단계가 왜 필요한지를 깨닫게 해 주었다. 자동화는 반복 작업을 줄여 주지만, 최종 판단의 책임까지 도구에 넘길 수는 없다는 결과보고서의 권고형 라벨 정책이 실제 작업 현장에서 어떻게 적용되는지를 직접 경험한 셈이다.

SafeTensors Python 바인딩 하네스에서 변환 경로 이슈를 발견한 것은 흥미로운 경험이었다. 6주차에 "안전한 코어를 감싸는 외피에 또 다른 공격 표면이 있을 수 있다"고 가설로만 적었던 부분이, 7주차에 실제 데이터로 확인되었다. 같은 SafeTensors 라이브러리라도 Rust 코어에서는 1시간 동안 메모리 오류 0건이었던 반면, Python 바인딩에서는 2시간 만에 dtype 매핑 이슈와 메모리 뷰 손상이 발견되었다. "보안은 가장 약한 고리에서 결정된다"는 격언이 단순한 수사가 아니라는 것을 데이터로 본 순간이었다.

다음 주는 드디어 1차 제출과 v1.0 통합 검증이 있는 마지막 주다. 8주 전에 "퍼징 도구를 만들어 보자"로 시작한 프로젝트가, 실제로 외부 오픈소스 프로젝트에 책임 있는 공개 절차를 통해 취약점을 제출하는 단계까지 도달했다는 것이 아직도 실감이 잘 나지 않는다. 동시에 v1.0이라는 정식 버전이 붙은 산출물을 정리하면서, 이 도구가 8주의 일경험을 넘어 후속 단계에서도 계속 발전할 수 있는 토대가 되기를 바라는 마음이 크다. 마지막 주에 통합 매트릭스 검증을 무사히 완료하고, 1차 제출이 외부 프로젝트의 보안 강화에 작은 기여가 되기를 기대한다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 6주차

mysticprayer — Mon, 11 May 2026 13:05:53 +0900

[미래내일 일경험] 테크노트 - 6주차

리포트 자동 생성 및 증거 번들링 | 2026.05.04 ~ 05.10

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

안정 재현된 13건의 고유 크래시에 대해 Report Generator 모듈과 함께 HackerOne 표준 양식 리포트 자동 생성 파이프라인 검증
증거 번들 패키징 로직 구현 (입력 파일 + ASan 로그 + 재현 커맨드 + 환경 스냅샷)
부분 재현 3건·재현 실패 2건의 환경 의존성 추가 분석
SafeTensors 하네스 프로토타입 착수 (JSON 헤더 + 오프셋 검증 영역 우선)
누적 퍼징 시간 증가에 따른 시드 코퍼스 정리 및 커버리지 정체 영역 분석

2. 학습 및 수행 내용

2-1. Report Generator 모듈 연동 및 첫 자동 리포트 생성

이번 주의 가장 큰 성과는 하네스에서 시작된 신호가 Triage → Reproducer → Report Generator까지 완주하는 첫 종단 간(End-to-End) 사이클을 완성한 것이다. 신숙우 팀장과 황희주 팀원이 구현한 Report Generator 모듈에 5주차에 확정한 ReproducedCrash 구조체를 입력하면, HackerOne 표준 양식의 Markdown 리포트가 자동 생성된다.

하네스 측에서는 Report Generator가 요구하는 추가 메타데이터(컴파일러 버전, 빌드 플래그, 시드 해시 등)를 HarnessFingerprint JSON으로 함께 출력하도록 보강하였다. 이는 리포트의 "재현 가능성" 섹션에 직접 포함되며, 외부 검증자가 동일한 빌드 환경을 재구성할 수 있게 한다.

// harness/fingerprint_gguf.json (빌드 시 생성)
{
  "harness_name": "fuzz_gguf",
  "harness_version": "0.6.0",
  "target": {
    "name": "llama.cpp",
    "commit": "a7b3f29c...",
    "build_date": "2026-05-05T09:12:00Z"
  },
  "toolchain": {
    "compiler": "clang version 17.0.6",
    "flags": ["-O1", "-g", "-fsanitize=fuzzer,address"],
    "sanitizers": ["AddressSanitizer"]
  },
  "runtime_env": {
    "os": "Ubuntu 24.04.2 LTS",
    "kernel": "6.8.0-39-generic",
    "allocator": "jemalloc 5.3.0",
    "malloc_conf": "junk:true"
  }
}

첫 자동 리포트 생성 결과, 안정 재현된 13건 모두 사람이 읽을 수 있는 형태의 리포트로 출력되었다. 각 리포트는 다음 7개 섹션을 포함한다.

섹션	생성 소스	담당 모듈
Summary	크래시 유형 + 심각도 자동 요약	Triage
Steps to Reproduce	재현 커맨드 + 환경 변수	Reproducer
Crash Details	ASan 로그 + 정규화 스택 트레이스	Triage
Root Cause Analysis	크래시 위치 + 코드 스니펫 추출	Reporter
Impact	RCE 가능성 + CVSS 추정치	Triage + Reporter
Environment	`HarnessFingerprint` JSON	Harness
Attachments	증거 번들 zip 링크 + SHA256	Reporter

✓ 첫 완성 사이클의 의미

1주차에 설계도로만 존재했던 "하네스 → 크래시 산출 → Triage → Reproducer → Report Generator"의 5단계 파이프라인이, 6주 만에 실제로 동작하는 시스템으로 완성되었다. 13건의 자동 리포트가 출력되는 순간, 각자 만들던 모듈들이 진정한 의미의 "한 시스템"이 되었음을 확인했다.

2-2. 증거 번들 패키징 로직 구현

버그바운티 제출 시 가장 중요한 것은 "외부 검증자가 동일한 결과를 재현할 수 있는가"이다. 이를 위해 리포트와 함께 첨부될 증거 번들을 zip 아카이브로 자동 패키징하는 로직을 구현하였다. 번들 구조는 다음과 같다.

evidence_GGUF-001_20260507.zip
├── report.md                    # HackerOne 표준 양식 본 리포트
├── crash_input.bin              # 최소화된 PoC 입력 (108 B)
├── crash_input.sha256           # 입력 파일 해시
├── asan.log                     # ASan 크래시 로그 원본
├── stack_trace.normalized.txt   # Triage가 정규화한 스택 트레이스
├── reproduce.sh                 # 재현 셸 스크립트 (한 줄 실행)
├── env.snapshot.json            # 컨테이너 환경 스냅샷
├── harness_fingerprint.json     # 빌드 시 생성된 환경 지문
└── Dockerfile.repro             # 재현 환경 Dockerfile (자체 완결)

핵심은 reproduce.sh 한 줄로 누구나 동일한 크래시를 재현할 수 있도록 만든 것이다. 스크립트는 Dockerfile.repro로 이미지를 빌드하고, 컨테이너 내부에서 env.snapshot.json의 환경 변수를 그대로 적용한 뒤, 첨부된 PoC를 하네스에 입력하여 ASan 로그를 출력한다.

#!/usr/bin/env bash
# reproduce.sh - 외부 검증자용 한 줄 재현 스크립트
set -euo pipefail

BUNDLE_DIR="$(dirname "$(readlink -f "$0")")"
cd "$BUNDLE_DIR"

# 1. 무결성 검증
sha256sum -c crash_input.sha256

# 2. 재현 환경 이미지 빌드
docker build -t bb-repro:local -f Dockerfile.repro .

# 3. 환경 변수를 적용하여 하네스 실행
docker run --rm \
  --cap-drop=ALL --cap-add=SYS_PTRACE \
  --network=none --read-only \
  --env-file env.snapshot.env \
  -v "$BUNDLE_DIR/crash_input.bin:/work/input.bin:ro" \
  bb-repro:local /work/harness_repro /work/input.bin

echo "[+] 재현 완료. 위 ASan 출력을 첨부된 asan.log와 비교하세요."

⚠️ 번들 설계 시 신경 쓴 부분

자체 완결성: 외부 인터넷 의존 없이 번들 안의 파일만으로 재현 가능 (Dockerfile 베이스 이미지만 예외)
무결성 검증: PoC 입력 파일의 SHA256을 별도 기록하여 전송 중 변조 탐지
최소권한 컨테이너: 5주차에 합의한 cap_drop=ALL + cap_add=SYS_PTRACE 패턴을 재현 환경에도 그대로 적용
정보 분리: 민감할 수 있는 빌드 머신 식별자(호스트명, 사용자명)는 HarnessFingerprint에서 제외

2-3. 부분 재현·재현 실패 케이스 추가 분석

5주차에 별도 트랙으로 분리한 부분 재현 3건과 재현 실패 2건에 대해 GGUF-004 분석에서 사용한 환경 변수 통제 방법론을 동일하게 적용하였다. 결과를 정리하면 다음과 같다.

크래시 ID	최초 상태	발견된 의존 요소	최종 상태
GGUF-005	부분 재현 (2/3)	스택 크기 (`ulimit -s`) 의존	안정 재현 승격
ONNX-D-009	부분 재현 (1/3)	CPU 아키텍처 의존 (AVX2 명령어)	조건부 재현
ONNX-D-014	부분 재현 (2/3)	스레드 스케줄링 (race condition 의심)	분석 진행 중
GGUF-007	재현 실패	시드 코퍼스 의존 (특정 캐시 상태 필요)	아티팩트 추정
ONNX-D-016	재현 실패	미확정 (재시도 결과 일관성 없음)	보류

분석 결과, 부분 재현 3건 중 GGUF-005가 안정 재현으로 승격되어 리포트 가능 크래시는 13건에서 14건으로 증가하였다. ONNX-D-009는 AVX2 지원 CPU에서만 재현되는 "조건부 재현"으로 분류해 리포트에 환경 요구사항을 명시하기로 했다. ONNX-D-014의 race condition 의심 케이스는 별도 분석이 더 필요하며, GGUF-007은 시드 코퍼스 캐시 상태에 의존하는 비유효 아티팩트로 판단해 제외하였다.

2-4. SafeTensors 하네스 프로토타입 착수

5주차에 사전 조사한 SafeTensors 포맷에 대한 하네스 프로토타입 개발에 착수하였다. 공식 파서가 Rust로 작성되어 있어 GGUF·ONNX와 달리 Rust 네이티브 퍼징 도구인 cargo-fuzz를 활용하는 방향으로 설계하였다.

// fuzz_targets/fuzz_safetensors.rs - cargo-fuzz 기반 하네스
#![no_main]
use libfuzzer_sys::fuzz_target;
use safetensors::SafeTensors;

fuzz_target!(|data: &[u8]| {
    // 1. 헤더 파싱 단계 (JSON + 길이 prefix)
    if data.len() < 8 { return; }
    
    // 2. SafeTensors 역직렬화 시도
    //    내부적으로 JSON 헤더 파싱 + 텐서 오프셋 검증 수행
    match SafeTensors::deserialize(data) {
        Ok(st) => {
            // 3. 모든 텐서에 접근하여 lazy 로딩 경로까지 도달
            for name in st.names() {
                let _ = st.tensor(name);
            }
        }
        Err(_) => {
            // 정상적인 거부는 무시
        }
    }
});

멘토링에서 받은 조언대로, Rust 공식 파서뿐 아니라 Python 바인딩(safetensors 패키지)의 numpy/torch 변환 경로도 별도 하네스로 추가하기로 했다. Python 바인딩 하네스는 7주차에 본격 구현 예정이다.

첫 1시간 시범 퍼징 결과는 다음과 같다.

측정 항목	결과	비고
실행 속도	약 220회/초	Rust 인프로세스 퍼징의 효율
엣지 커버리지 (1h)	2,108	JSON 파싱 + 오프셋 검증 위주
예비 크래시 / 패닉	0건 (Panic 4건)	메모리 안전 위반 없음, panic은 별도 분석

Rust 파서 퍼징의 특이점

예상대로 C/C++ 파서에서 흔히 보이던 메모리 커럽션 류 크래시는 1시간 퍼징에서 0건이었다. 대신 Rust의 panic!으로 인한 의도적 중단이 4건 발견되었는데, 이는 보안 취약점이라기보다 DoS 가능성 정도로 평가된다. 다만 패닉이 외부 입력으로 트리거된다는 점에서, 라이브러리 사용자에게는 여전히 의미 있는 신호다. SafeTensors는 "메모리 안전성은 강력하지만 입력 검증은 별도로 다뤄야 한다"는 Rust 보안 모델의 전형을 보여 준다.

2-5. 시드 코퍼스 정리 및 커버리지 정체 영역 분석

누적 퍼징 시간이 GGUF는 약 120시간, ONNX는 약 96시간에 도달하면서 시드 코퍼스가 크게 비대해지고 커버리지 증가가 정체되는 현상이 두드러졌다. 코퍼스를 분석한 결과, 중복에 가까운 입력이 다수 누적되어 퍼저가 비슷한 경로만 반복해서 탐색하고 있음을 확인했다.

LibFuzzer의 -merge=1 모드를 활용해 코퍼스 미니마이제이션을 수행하였다. 이 모드는 동일한 커버리지를 유지하는 최소 입력 집합만 남기는 작업으로, 시간이 다소 걸리지만 효과는 즉각적이다.

포맷	정리 전 코퍼스	정리 후 코퍼스	감소율
GGUF	48,210 개 (총 2.4 GB)	3,847 개 (총 198 MB)	-92.0% (개수) / -91.7% (용량)
ONNX	31,406 개 (총 1.8 GB)	2,512 개 (총 142 MB)	-92.0% (개수) / -92.1% (용량)

정리된 코퍼스로 1시간 추가 퍼징을 수행한 결과, 엣지 커버리지가 GGUF 5,341 → 5,612 (+271), ONNX 12,420 → 12,798 (+378)로 다시 증가하기 시작했다. 코퍼스 정리 자체가 새로운 경로 탐색을 촉진한다는 것을 확인하였다.

추가로, llvm-cov를 활용해 커버되지 않은 코드 영역을 시각화한 결과 다음 두 영역이 정체 구간으로 식별되었다.

GGUF 양자화 메타데이터 처리 분기: Q4_K, Q5_K 등 양자화 타입별 메타데이터 처리 로직 진입률이 8% 미만 → 양자화 타입을 명시적으로 변형하는 뮤테이션 전략 추가 필요
ONNX Custom Operator 등록 경로: 사용자 정의 연산자 처리 경로 진입률이 3% 미만 → 시드 코퍼스에 custom op를 포함한 모델 추가 필요

️ 3. 수행 활동

3-1. 개인 수행 활동

하네스 측 HarnessFingerprint JSON 출력 기능 신규 구현 (빌드 시 자동 생성)
Report Generator 모듈과의 인터페이스 디버깅 및 자동 리포트 생성 검증 (14건 최종 출력)
증거 번들 zip 패키징 로직 구현 (reproduce.sh + Dockerfile.repro 자동 생성)
부분 재현 3건·재현 실패 2건의 환경 의존성 분석 (스택 크기, AVX2, race condition 등)
SafeTensors 하네스 프로토타입 작성 (cargo-fuzz 기반) 및 1시간 시범 퍼징
GGUF·ONNX 시드 코퍼스 미니마이제이션 작업 수행 (-merge=1)
llvm-cov를 활용한 미커버 영역 시각화 및 다음 단계 뮤테이션 전략 도출

3-2. 팀 활동

온라인 정기 미팅 (05.10, Discord): 14건의 자동 리포트 생성 결과를 공유하고, HackerOne 제출 후보 선별 기준에 대해 논의. 심각도 High 이상의 4건(GGUF-001, 003, ONNX-D-001, 004)을 우선 제출 후보로 분류
신숙우 팀장·황희주 팀원과 페어 작업 (05.06~05.07): Report Generator의 Markdown 출력 형식을 HackerOne 공식 템플릿과 비교하며 누락된 필드(reporter contact, disclosure timeline 등) 보강. 7개 섹션 구조를 최종 확정
전선정 팀원과 협업 (05.08): 부분 재현 케이스의 환경 의존성 분석을 함께 수행. 특히 ONNX-D-014의 race condition 의심 케이스는 ThreadSanitizer(TSan)로 추가 분석하는 방향을 합의
멘토링 세션 (05.09): 멘토로부터 증거 번들의 reproduce.sh 한 줄 재현 설계가 실제 버그바운티 보고에서 큰 강점이라는 피드백을 받음. 또한 SafeTensors의 panic 케이스도 라이브러리 의존 서비스에서는 의미 있는 DoS 신호라는 점에서 별도 카테고리로 리포트하라는 조언 수령
HackerOne 정책 검토: 팀 전체가 HackerOne의 책임 있는 공개(Coordinated Disclosure) 정책과 llama.cpp·onnxruntime 프로젝트의 보안 정책(SECURITY.md)을 함께 검토. 제출 전 최소 90일 비공개 기간 준수 등 절차를 확인

4. 다음 주 계획 (7주차)

계획서상 7주차 키워드: "취약점 우선순위 선정 및 1차 제출 준비"

High 심각도 4건(GGUF-001, 003, ONNX-D-001, 004)에 대한 RCE 가능성 정밀 분석 (레지스터 상태 검토)
우선 제출 후보 리포트의 본문 인간 검토 및 보안적 표현 다듬기
llama.cpp·onnxruntime 프로젝트의 보안 정책 절차에 따른 1차 제출 진행
SafeTensors Python 바인딩 하네스 추가 구현 (numpy/torch 변환 경로)
GGUF 양자화 메타데이터 뮤테이션 전략 추가 (Q4_K, Q5_K 분기 도달)
ONNX-D-014 race condition 의심 케이스 ThreadSanitizer 분석 (전선정 팀원과 협업)

5. 느낀점 및 회고

6주차는 "파이프라인이 마침내 한 바퀴 완주한 한 주"였다. 1주차에 노션에 그렸던 5단계 모듈 흐름도가, 6주가 지나 실제로 동작하는 시스템이 되어 14건의 사람이 읽을 수 있는 리포트로 출력되는 것을 보았을 때, 그동안의 모든 디버깅과 인터페이스 협의가 한 점에 모이는 듯한 느낌이었다. 특히 내가 만든 하네스에서 시작된 신호가 Triage → Reproducer → Report Generator를 거쳐 최종 리포트가 되어 나오는 순간은, 이번 프로젝트에서 가장 강렬한 성취감을 느낀 장면이었다.

증거 번들 설계 작업을 하면서 "재현 가능성"이 보안 보고의 본질이라는 것을 새삼 깨달았다. 처음에는 단순히 입력 파일과 ASan 로그만 첨부하면 된다고 생각했지만, 외부 검증자의 입장에서 생각해 보면 환경 변수 하나, 컴파일러 플래그 하나가 결과를 바꿀 수 있다. 그래서 Dockerfile.repro까지 번들에 포함하여 "이 zip 하나만 받으면 누구나 동일한 결과를 재현할 수 있다"는 자체 완결성을 만든 것이 가장 만족스러운 설계였다. 멘토님이 reproduce.sh 한 줄 재현이 실무에서 큰 강점이라고 평가해 주신 점도 인상적이었다.

부분 재현 케이스를 다시 분석하면서, 5주차의 GGUF-004 분석 방법론이 일종의 재사용 가능한 도구가 되었다는 것을 느꼈다. 처음 GGUF-004를 분석할 때는 시행착오가 많았지만, 그때 정리한 "할당기 → 스레드 → ASLR → 기타 환경 변수" 통제 순서를 GGUF-005, ONNX-D-009에 똑같이 적용하니 훨씬 빠르게 결론에 도달했다. 한 번 어렵게 길을 낸 분석 방법이, 다음 케이스에서는 정해진 절차가 된다는 점에서 "프로세스를 만드는 일"의 가치를 다시 한 번 체감했다.

SafeTensors 하네스를 작성하면서 "파서 언어가 보안 모델 자체를 바꾼다"는 것을 직접 체감했다. C/C++ 파서에서는 가장 흔하게 보던 메모리 커럽션이 Rust 파서에서는 1시간 동안 0건이었고, 대신 panic이라는 다른 형태의 신호가 나왔다. 같은 "퍼징"이라는 행위가 타깃에 따라 전혀 다른 종류의 발견을 만들어낸다는 것이 흥미로웠다. 동시에 Rust라고 해서 입력 검증 문제가 사라지는 것은 아니라는 점, 그리고 Python 바인딩처럼 안전한 코어를 감싸는 외피에 또 다른 공격 표면이 존재할 수 있다는 점은 다음 주의 중요한 탐구 과제가 될 것이다.

시드 코퍼스 정리 작업은 이번 주의 "작지만 큰 변화"였다. 92%나 되는 코퍼스를 삭제했음에도 커버리지가 다시 증가하기 시작한 것은, "더 많은 데이터가 더 좋은 결과를 만든다"는 직관이 항상 옳지 않다는 것을 보여 줬다. 좋은 시드는 다양성 있는 소수의 입력이지, 비슷한 입력 수만 개가 아니라는 것을 데이터로 확인했다. 4주차의 빌드 자동화, 5주차의 watchdog 보강에 이어 이번 주의 코퍼스 정리까지, "보이지 않는 곳을 다듬는 작업"이 결국 시스템 전체의 효율을 만든다는 패턴이 점점 더 분명해진다.

다음 주는 드디어 실제 외부 프로젝트에 취약점을 제출하는 단계다. 학교 과제나 내부 테스트가 아닌, 실제 사용 중인 오픈소스 프로젝트의 보안 정책 절차를 따라 우리가 발견한 결과를 공식적으로 제출하게 된다. 이 과정에서 우리의 리포트가 외부의 객관적인 평가를 받게 될 것이고, 그 피드백은 앞으로의 분석 방향에도 큰 영향을 줄 것이다. 6주 전에는 단지 "퍼징을 해 보자"였던 프로젝트가, 7주차에는 실제 보안 생태계에 기여하는 결과물로 이어진다는 사실이 가장 의미 있게 다가오는 한 주가 될 것 같다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 5주차

mysticprayer — Sun, 3 May 2026 22:32:19 +0900

[미래내일 일경험] 테크노트 - 5주차

재현 및 중복 제거 구현 | 2026.04.27 ~ 05.03

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

ONNX 크래시 26건(경량 9 + 심층 17)에 대한 PoC 최소화 및 Triage 입력 작업 완료
Crash Reproducer 모듈(전선정 팀원)과 함께 격리 컨테이너 3회 반복 재현 시스템 검증
GGUF-004(플레이키 UAF) 케이스의 재현 환경 변수 분석 및 안정 재현 조건 도출
하네스 측 watchdog/timeout 로직 보강으로 무한 루프·교착 상태 자동 차단
SafeTensors 포맷 사전 조사 (다음 단계 확장 대비)

2. 학습 및 수행 내용

2-1. ONNX 크래시 PoC 최소화 작업

4주차에 24시간 ONNX 퍼징을 통해 수집한 예비 크래시는 경량 하네스 9건, 심층 하네스 17건으로 총 26건이었다. 이번 주에는 이 26건 각각에 대해 GGUF에서와 동일한 방식으로 LibFuzzer의 -minimize_crash=1 옵션을 활용한 PoC 최소화 작업을 수행하였다.

ONNX 파일은 GGUF와 달리 Protocol Buffers 기반 직렬화 포맷이므로, 단순히 바이트를 잘라내는 것만으로는 유효한 protobuf 메시지를 유지하기 어려운 케이스가 다수 발생하였다. 이를 해결하기 위해 두 단계 최소화 전략을 적용하였다.

# 1단계: LibFuzzer 기본 최소화 (바이트 단위 축소)
./fuzz_onnx_session -minimize_crash=1 \
    -runs=100000 \
    -exact_artifact_path=minimized_stage1.onnx \
    crash_input.onnx

# 2단계: protobuf 구조 인식 최소화 (필드 단위 제거)
python3 scripts/onnx_field_minimizer.py \
    --input minimized_stage1.onnx \
    --output minimized_final.onnx \
    --asan-log original.asan.log

2단계의 필드 단위 최소화 스크립트는 onnx 파이썬 라이브러리로 모델을 파싱한 뒤, 그래프의 각 노드·이니셜라이저를 하나씩 제거해 보면서 동일한 ASan 크래시가 재현되는 최소 부분 그래프를 찾는 방식으로 동작한다.

크래시 ID	유형	원본 크기	최소화 후
ONNX-L-001~009	Protobuf 파싱 (경량)	평균 6.8 KB	평균 184 B
ONNX-D-001~006	Shape Inference	평균 12.4 KB	평균 412 B
ONNX-D-007~012	Type Mismatch	평균 9.1 KB	평균 268 B
ONNX-D-013~017	Memory Corruption	평균 14.7 KB	평균 524 B

2-2. Triage 입력 및 고유 크래시 분류 결과

최소화된 26건의 ONNX 크래시를 Triage 모듈에 입력하여 분류한 결과, 고유 크래시 11건으로 정규화되었다. GGUF의 7건과 합산하면 현재까지 누적 고유 크래시는 총 18건이다.

Triage 결과의 흥미로운 패턴

심층 하네스에서 발견된 17건 중 Shape Inference 관련 6건이 모두 단 2개의 고유 크래시로 정규화되었다는 점이 인상적이었다. 이는 동일한 근본 원인(root cause)이 다양한 입력 변형을 통해 표면적으로 다르게 보였을 뿐이라는 것을 시사한다. 반면 Memory Corruption 5건은 모두 서로 다른 5개의 고유 크래시로 분류되어, 각각 독립적인 취약점일 가능성이 높다.

2-3. 격리 컨테이너 3회 반복 재현 시스템 검증

전선정 팀원이 구현한 Crash Reproducer 모듈과 함께 첫 종단 간 재현 검증을 수행하였다. 이 모듈은 Triage가 분류한 고유 크래시를 입력받아, 격리된 Docker 컨테이너에서 3회 반복 실행하여 모든 회차에서 동일한 ASan 크래시 시그니처가 재현되는지를 확인한다.

# reproducer/docker-compose.yml - 격리 재현 환경 정의
version: '3.8'
services:
  reproducer:
    image: bugbounty-reproducer:0.5.0
    cap_drop: [ALL]
    cap_add: [SYS_PTRACE]  # ASan 동작에 필요
    security_opt:
      - seccomp:unconfined  # ASan의 시그널 핸들러용
    network_mode: none      # 외부 네트워크 차단
    mem_limit: 2g
    pids_limit: 256
    read_only: true
    tmpfs:
      - /tmp:size=512M
    volumes:
      - ./crashes:/work/crashes:ro
      - ./results:/work/results:rw

하네스 측에서는 재현 검증용 진입점을 별도로 노출시켰다. 기존 LLVMFuzzerTestOneInput과 동일한 로직을 호출하되, 입력은 파일 경로로 받고 종료 코드로 크래시 발생 여부를 반환하는 단순한 래퍼다.

// harness_repro.c - 재현 검증 전용 진입점
int main(int argc, char **argv) {
    if (argc != 2) return 2;
    
    FILE *f = fopen(argv[1], "rb");
    if (!f) return 3;
    
    fseek(f, 0, SEEK_END);
    size_t size = ftell(f);
    fseek(f, 0, SEEK_SET);
    
    uint8_t *buf = malloc(size);
    fread(buf, 1, size, f);
    fclose(f);
    
    // 동일 로직 호출 — ASan이 크래시를 잡으면 SIGABRT
    LLVMFuzzerTestOneInput(buf, size);
    
    free(buf);
    return 0;  // 정상 종료
}

분류	고유 크래시 수	3회 모두 재현	부분 재현 (1~2회)	재현 실패
GGUF	7	5	1	1
ONNX	11	8	2	1
합계	18	13 (72%)	3 (17%)	2 (11%)

3회 모두 안정 재현된 13건은 다음 단계인 Report Generator로 즉시 흘러갈 수 있는 상태가 되었으며, 부분 재현 3건과 실패 2건은 환경 의존성을 분석할 별도 트랙으로 분리하였다.

2-4. GGUF-004 플레이키 UAF 케이스 분석

4주차에 발견된 GGUF-004(Use-After-Free 의심) 케이스는 동일 입력에 대해 일부 환경에서만 재현되는 플레이키 특성을 보였다. 3회 반복 재현 검증에서도 컨테이너 인스턴스에 따라 재현 여부가 달랐으며, 이를 정밀하게 분석할 필요가 있었다.

⚠️ GGUF-004 분석 단계

환경 변수 통제: MALLOC_CONF, ASAN_OPTIONS, LD_PRELOAD 등을 모두 고정하여 메모리 할당기 동작을 일관되게 만듦
할당기 변경 실험: glibc malloc, jemalloc, tcmalloc 각각에서 재현률 측정
스레드 수 통제: OpenMP/pthread 스레드 수를 1로 고정하여 스케줄링 변동 제거
ASLR 비활성화: setarch -R로 주소 공간 무작위화를 끄고 재시도

환경 조건	30회 시도 중 재현 횟수	비고
기본 환경	14회 (47%)	플레이키
ASLR 비활성화만	17회 (57%)	미미한 영향
스레드 1개 + ASLR 비활성화	22회 (73%)	개선
jemalloc + 스레드 1개 + ASLR 비활성화	29회 (97%)	안정 재현
`MALLOC_CONF=junk:true` 추가	30회 (100%)	완전 안정

핵심 발견은 glibc malloc의 fastbin 재사용 패턴이 비결정적 동작을 유발했다는 점이었다. jemalloc으로 교체하고 junk:true 옵션을 적용하면 해제된 메모리 영역이 즉시 마커 패턴으로 채워져, UAF가 결정론적으로 ASan에 검출된다. 이 조건을 표준 재현 환경으로 컨테이너 이미지에 고정하여, GGUF-004는 "안정 재현 가능한 UAF"로 승격되었다.

✓ 플레이키 케이스 처리의 의의

기존 퍼징 도구들이 단순 크래시 탐지에 머무르고 검증 단계에서 "재현 안 됨"으로 누락하는 케이스가 많은데, 본 프로젝트에서는 환경 변수까지 통제 변수로 다뤄 안정 재현 조건을 능동적으로 도출하였다. 이는 1주차 조사에서 정의한 "검증 가능한 취약점만 유효 결과로 확정한다"는 원칙을 실제로 구현한 사례다.

2-5. 하네스 watchdog 및 timeout 로직 보강

장시간 퍼징을 운용하면서 일부 입력이 무한 루프나 교착 상태를 유발하여 워커 하나가 멈추는 현상이 간헐적으로 발생하였다. LibFuzzer 자체의 -timeout 옵션이 있긴 하지만, 일부 시그널 처리 상황에서 동작하지 않는 경우가 있어 하네스 레벨에서 보강이 필요했다.

// harness_watchdog.c - 하네스 내부 watchdog
#include <signal.h>
#include <sys/time.h>

#define HARNESS_TIMEOUT_SEC 10

static void timeout_handler(int sig) {
    (void)sig;
    // 비정상 종료로 LibFuzzer가 timeout으로 인식하도록
    _exit(99);
}

static void arm_watchdog(void) {
    struct sigaction sa = { .sa_handler = timeout_handler };
    sigaction(SIGALRM, &sa, NULL);
    
    struct itimerval timer = {
        .it_value = { .tv_sec = HARNESS_TIMEOUT_SEC, .tv_usec = 0 },
        .it_interval = { 0 }
    };
    setitimer(ITIMER_REAL, &timer, NULL);
}

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    arm_watchdog();
    
    // ... 기존 파싱 로직 ...
    
    // 정상 종료 시 타이머 해제
    struct itimerval disable = {0};
    setitimer(ITIMER_REAL, &disable, NULL);
    return 0;
}

이 watchdog을 적용한 후 1시간 단위 안정성 테스트를 수행한 결과, 워커 멈춤(stall) 발생률이 적용 전 4.2%에서 적용 후 0.1% 미만으로 떨어졌다. 또한 timeout으로 종료된 입력 자체도 별도 디렉토리에 수집되어, 추후 "비크래시지만 비정상 동작"을 유발하는 입력으로 분석할 수 있게 되었다.

2-6. SafeTensors 포맷 사전 조사

다음 단계 확장을 대비하여 SafeTensors 포맷에 대한 사전 조사를 진행하였다. SafeTensors는 Hugging Face가 주도하여 만든 AI 모델 저장 포맷으로, "이름 그대로 안전성"을 핵심 가치로 내세운다. pickle 기반 포맷의 임의 코드 실행 위험을 제거하기 위해 설계되었으며, 점차 사실상 표준으로 자리 잡고 있다.

항목	SafeTensors	GGUF	ONNX
포맷 베이스	JSON 헤더 + 바이너리	커스텀 바이너리	Protocol Buffers
헤더 위치	파일 선두 (길이 prefix)	파일 선두	파일 전체
파서 언어	Rust (safetensors 크레이트)	C/C++ (llama.cpp)	C++ (onnxruntime)
주요 공격 표면	JSON 파싱 + 오프셋 검증	텐서 메타데이터 검증	그래프 검증 + shape inference

흥미로운 점은 SafeTensors의 공식 파서가 Rust로 구현되어 있어 메모리 안전성 측면에서 GGUF나 ONNX보다 견고하다는 것이다. 그러나 JSON 헤더 파싱 단계, 오프셋·길이 검증 로직, 그리고 다양한 언어 바인딩(Python, JS, Go 등)에서는 여전히 취약점 가능성이 존재한다. 6주차 이후 이 포맷에 대한 하네스를 추가하면, 본 프로젝트가 "주요 AI 모델 포맷 3종을 모두 커버"하는 의미 있는 마일스톤이 될 것이다.

️ 3. 수행 활동

3-1. 개인 수행 활동

ONNX 크래시 26건 PoC 최소화 작업 완료 (LibFuzzer 1단계 + protobuf 구조 인식 2단계)
protobuf 필드 단위 최소화 스크립트(onnx_field_minimizer.py) 신규 작성
재현 검증용 하네스 진입점(harness_repro.c) 구현 및 컨테이너 이미지 통합
GGUF-004 플레이키 UAF 환경 변수 분석 (할당기·스레드·ASLR 통제 실험)
jemalloc + junk:true 기반 안정 재현 환경 표준화 및 컨테이너 이미지 반영
하네스 내부 watchdog/timeout 로직 구현 (SIGALRM + setitimer 기반)
SafeTensors 포맷 명세 학습 및 비교 분석 자료 작성

3-2. 팀 활동

온라인 정기 미팅 (05.03, Discord): 18건의 누적 고유 크래시 현황과 재현 검증 결과를 공유, 다음 단계인 Report Generator 연동 일정 확정
전선정 팀원과 페어 작업 (04.30~05.01): Crash Reproducer 모듈과의 인터페이스 정합성 검증을 위해 격리 컨테이너 환경에서 직접 함께 디버깅. 특히 ASan 시그널 처리에 필요한 cap_add: SYS_PTRACE 설정을 두고 보안 최소권한 원칙과의 균형점을 논의
신숙우 팀장·황희주 팀원과 인터페이스 협의 (05.02): Report Generator 모듈이 받을 입력 포맷(검증 완료된 ReproducedCrash 구조체) 명세를 확정. 재현 커맨드, 환경 변수 스냅샷, ASan 로그, 최소화된 입력 파일 경로 등이 표준 필드로 포함됨
멘토링 세션 (05.02): 멘토로부터 GGUF-004의 환경 변수 통제 분석이 실무에서 종종 누락되는 중요한 절차라는 피드백을 받음. 또한 SafeTensors 확장 시 공식 Rust 파서뿐 아니라 Python 바인딩(safetensors 패키지의 numpy/torch 변환 경로)도 함께 퍼징 대상에 포함하라는 조언 수령
재현 검증 결과 문서화: Notion에 18건 고유 크래시별 재현 조건, 환경 변수, 최소화된 입력 해시를 정리한 표를 작성하여 팀 전체가 진행 상황을 추적할 수 있도록 공유

4. 다음 주 계획 (6주차)

계획서상 6주차 키워드: "리포트 자동 생성 및 증거 번들링"

안정 재현된 13건의 고유 크래시에 대해 Report Generator 모듈(신숙우·황희주)과 함께 HackerOne 표준 양식 리포트 자동 생성 파이프라인 검증
리포트에 포함될 증거 번들 패키징 로직 구현 (입력 파일 + ASan 로그 + 재현 커맨드 + 환경 스냅샷)
부분 재현 3건·재현 실패 2건의 환경 의존성 추가 분석
SafeTensors 하네스 프로토타입 착수 (JSON 헤더 + 오프셋 검증 영역 우선)
누적 퍼징 시간이 길어짐에 따른 시드 코퍼스 정리 및 커버리지 정체 영역 분석

5. 느낀점 및 회고

5주차는 "발견된 크래시"와 "검증된 취약점" 사이의 거리를 직접 좁혀본 한 주였다. 4주차까지는 하네스가 크래시를 얼마나 많이 만들어낼 수 있는가에 집중했다면, 이번 주는 그 크래시 중 무엇이 진짜 의미 있는 결과인지를 가려내는 단계였다. 26건의 ONNX 크래시가 11건의 고유 크래시로, 다시 8건의 안정 재현 결과로 줄어드는 과정을 보면서, 퍼징의 진짜 가치는 "양"이 아니라 "검증된 양"에 있다는 것을 체감하였다.

GGUF-004의 플레이키 UAF 케이스를 분석한 경험이 가장 인상 깊었다. 처음에는 "재현이 안 되는 크래시는 어차피 못 쓰는 것 아닌가"라는 생각도 들었지만, 환경 변수를 하나씩 통제 변수로 두고 실험을 반복하면서 메모리 할당기의 동작이 결과를 좌우한다는 사실을 발견했다. 결국 jemalloc + junk:true 조합으로 100% 재현 환경을 구축한 순간, "재현되지 않는 것"과 "재현 조건을 아직 모르는 것"이 다르다는 것을 깨달았다. 멘토님이 이 절차를 실무에서도 자주 누락된다고 말씀해 주신 것을 듣고, 이런 작은 디테일들이 결국 결과의 질을 결정한다는 것을 다시 한 번 느꼈다.

전선정 팀원과의 페어 작업도 이번 주의 중요한 경험이었다. Crash Reproducer 모듈의 컨테이너 보안 설정을 두고 "최소권한 원칙"과 "ASan 동작 요건"이 충돌하는 상황을, 둘이 함께 옵션을 하나씩 켜고 끄면서 합의점을 찾아갔다. 코드를 함께 보면서 토론하면 혼자 읽을 때보다 훨씬 빠르게 합리적 결론에 도달한다는 것을 다시 확인했다. 특히 인터페이스가 맞물리는 모듈을 담당하는 팀원과의 페어 세션은, 문서로 주고받는 것보다 훨씬 효율적이라는 것을 체감했다.

watchdog 보강 작업은 사소해 보였지만 효과가 즉각적이었다. 24시간 퍼징 중 워커가 멈추던 4.2%의 손실이 0.1% 미만으로 줄어들면서, 같은 시간을 돌려도 더 많은 신호를 얻을 수 있게 되었다. 4주차의 빌드 자동화에 이어, "기반을 단단히 다지는 작업"이 결국 가장 큰 효율을 만들어낸다는 패턴을 다시 한 번 확인했다. 결국 좋은 시스템은 화려한 기능 하나보다, 안 보이는 곳에서 흔들리지 않는 토대 위에 만들어진다는 점을 이번 주에 새삼 느꼈다.

다음 주는 그동안 검증된 13건의 고유 크래시가 실제 리포트로 자동 생성되는 단계다. 내가 만든 하네스에서 시작된 신호가 Triage를 거쳐 Reproducer로, 다시 Report Generator로 흘러가 최종적으로 사람이 읽을 수 있는 리포트가 되어 나오는 순간을, 4주 전부터 기다려 왔다. 6주차에는 그 첫 완성된 사이클을 직접 보게 될 것 같아, 이번 프로젝트에서 가장 기대되는 한 주가 될 것이다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 4주차

mysticprayer — Sun, 26 Apr 2026 21:44:43 +0900

[미래내일 일경험] 테크노트 - 4주차

뮤테이터 고도화 및 ONNX 퍼징 본격 가동 | 2026.04.20 ~ 04.26

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

GGUF 뮤테이터에 필드 간 상호 의존성(cross-field) 변형 전략 추가 구현
ONNX 심층 하네스의 세션 로딩 속도 최적화 (세션 풀링, 초기화 비용 절감)
ONNX 대상 24시간 장시간 퍼징 1차 실행 및 결과 분석
Triage 모듈(전선정 팀원)과 첫 E2E 인터페이스 연동 테스트 수행
하네스 빌드 프로세스 자동화 (CMake + Cargo build.rs 통합)
3주차에 수집한 GGUF 크래시 6~8건의 PoC 최소화 작업 완료

2. 학습 및 수행 내용

2-1. Cross-Field 뮤테이션 전략의 필요성

3주차에 구현한 단일 필드 변형 뮤테이터는 엣지 커버리지를 크게 끌어올렸지만, 24시간 퍼징 후반부에 들어서면서 커버리지 증가가 정체되는 현상이 관찰되었다. 12시간 시점 4,780이었던 엣지 커버리지가 24시간 시점에는 5,103에서 멈추었으며, 이는 단일 필드만 변형해서는 더 깊은 검증 로직에 도달하기 어렵다는 것을 의미한다.

실제 GGUF 파서의 코드를 분석해 보면, 헤더 필드들은 서로 강한 의존 관계를 가진다. 예컨대 tensor_count와 텐서 정보 영역의 실제 엔트리 수가 일치해야 하며, 텐서의 n_dims와 차원 배열의 길이가 맞물려야 한다. 단일 필드만 변형하면 대부분 초기 sanity check 단계에서 걸러지지만, 두 필드를 동시에 조작하여 의도적으로 모순을 유지하면 검증 로직의 더 깊은 분기까지 도달할 수 있다.

Cross-Field 변형의 4가지 핵심 패턴

일관성 위반(Consistency Break): tensor_count = 100이지만 실제 텐서 엔트리는 3개만 존재 → 파서가 100개를 읽으려다 OOB Read 유발
크기-오프셋 모순(Size-Offset Mismatch): 텐서의 offset은 파일 끝 너머를 가리키지만 size는 정상값 → 매핑된 메모리 외부 접근 유도
차원-데이터 불일치(Dim-Data Mismatch): n_dims = 4이지만 차원 배열에는 2개 값만 존재 → 차원 곱셈 시 미초기화 메모리 참조
타입-크기 모순(Type-Size Mismatch): 텐서 타입은 F32(4바이트/원소)인데 데이터 크기는 홀수 → 정렬 가정 위반에 따른 정수 오버플로우

2-2. Cross-Field 뮤테이터 구현

3주차에 구현한 단일 필드 뮤테이터에 cross-field 전략을 추가 구현하였다. 핵심은 두 필드를 함께 조작하되, 그 모순이 의미 있는 방향이 되도록 설계한 것이다.

// 텐서 개수와 실제 엔트리 수 사이의 모순을 유도
size_t mutate_count_entry_mismatch(uint8_t *data, size_t size,
                                   size_t max_size, struct gguf_view *view) {
    // 1) tensor_count는 의도적으로 부풀려 기록
    uint64_t declared_count = view->tensor_count + (rand() % 100 + 50);
    memcpy(data + view->tensor_count_offset, &declared_count, sizeof(uint64_t));

    // 2) 실제 텐서 엔트리는 그대로 두어 모순 발생
    // 파서는 declared_count만큼 루프 돌다가 파일 끝을 넘어감
    return size;
}

// 텐서 차원 수와 차원 배열 길이의 불일치 유도
size_t mutate_dim_array_mismatch(uint8_t *data, size_t size,
                                 size_t max_size, struct gguf_view *view) {
    if (view->tensor_count == 0) return size;
    
    struct tensor_info *t = &view->tensors[0];
    // n_dims를 4로 선언하지만 실제 차원 배열에는 1개만 기록되도록
    uint32_t fake_ndims = 4;
    memcpy(data + t->ndims_offset, &fake_ndims, sizeof(uint32_t));
    // dim 배열 영역을 늘리지 않고 그대로 둠 → 파서는 미초기화 메모리 참조
    return size;
}

// 메인 뮤테이터에 cross-field 전략 추가 (기존 4종 + 신규 4종)
size_t LLVMFuzzerCustomMutator(uint8_t *data, size_t size,
                                size_t max_size, unsigned int seed) {
    struct gguf_view view;
    if (!parse_gguf_layout(data, size, &view))
        return LLVMFuzzerMutate(data, size, max_size);

    int strategy = seed % 10;
    switch (strategy) {
        // 단일 필드 (3주차 구현, 0~3)
        case 0: return mutate_tensor_count(data, size, max_size, &view);
        case 1: return mutate_kv_string_length(data, size, max_size, &view);
        case 2: return mutate_tensor_offset(data, size, max_size, &view);
        case 3: return mutate_tensor_dimensions(data, size, max_size, &view);
        // Cross-field (4주차 신규, 4~7)
        case 4: return mutate_count_entry_mismatch(data, size, max_size, &view);
        case 5: return mutate_offset_size_mismatch(data, size, max_size, &view);
        case 6: return mutate_dim_array_mismatch(data, size, max_size, &view);
        case 7: return mutate_type_size_mismatch(data, size, max_size, &view);
        default: return LLVMFuzzerMutate(data, size, max_size);
    }
}

Cross-field 뮤테이터를 적용한 1시간 단위 비교 퍼징을 수행한 결과는 다음과 같다.

지표	3주차 (단일 필드)	4주차 (단일 + Cross-field)	증감
엣지 커버리지 (1h)	3,412	4,287	+25.6%
신규 코드 분기 도달	메타데이터 파싱 위주	텐서 검증, 정렬 계산 분기 도달	심층 도달
예비 크래시 (1h)	7건	12건	+71.4%

2-3. ONNX 심층 하네스 세션 로딩 최적화

3주차에 측정한 ONNX 심층 하네스의 실행 속도는 초당 약 35회에 불과했다. 이는 GGUF 하네스(140회/초)에 비해 4배 가까이 느리며, 24시간 퍼징을 돌려도 GGUF 6시간 분량밖에 되지 않는다. 병목 분석 결과, 한 회당 실행 시간의 약 78%가 Ort::Session 생성 자체에 소비되고 있었다.

⚠️ 세션 로딩 병목의 정체

Ort::Env 초기화: 로깅 시스템, 스레드 풀, 메모리 아레나 등을 매번 초기화 (약 80ms/회)
SessionOptions 구성: 디폴트 값 채우기, allocator 등록 (약 15ms/회)
Graph 검증: 입력 모델별로 매번 수행 — 이 단계는 퍼징 타깃이므로 그대로 유지

해결 전략은 변하지 않는 부분은 한 번만 초기화하여 재사용하는 것이다. Ort::Env와 SessionOptions는 정적 변수로 한 번만 생성하고, Ort::Session만 매 반복마다 새로 만들도록 변경하였다.

// fuzz_onnx_session.cc - 최적화 버전
static Ort::Env& get_env() {
    static Ort::Env env(ORT_LOGGING_LEVEL_FATAL, "fuzz");
    return env;
}

static Ort::SessionOptions& get_session_opts() {
    static Ort::SessionOptions opts = []() {
        Ort::SessionOptions o;
        o.SetIntraOpNumThreads(1);
        o.SetInterOpNumThreads(1);
        o.SetGraphOptimizationLevel(ORT_DISABLE_ALL);
        o.DisableMemPattern();
        o.DisableCpuMemArena();
        return o;
    }();
    return opts;
}

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    if (size > 1024 * 512) return 0;
    try {
        // Env, SessionOptions는 재사용 — Session만 새로 생성
        Ort::Session session(get_env(), data, size, get_session_opts());
    } catch (const Ort::Exception&) {
    } catch (const std::exception&) {}
    return 0;
}

측정 항목	최적화 전	최적화 후	비고
실행 속도	약 35회/초	약 142회/초	약 4배 향상
평균 1회 시간	약 28.5ms	약 7.0ms	Env/Opts 초기화 비용 제거
메모리 누적	선형 증가 (의심)	안정 (250MB ±10MB)	MemArena 비활성화 효과

2-4. ONNX 24시간 장시간 퍼징 1차 실행

최적화된 심층 하네스와 경량 하네스(LPM 기반)를 모두 24시간 가동하였다. 각 하네스는 별도 Docker 컨테이너에서 4 워커 병렬로 실행되었으며, 시드 코퍼스는 ONNX 공식 모델 동물원(Model Zoo)에서 추출한 최소 모델 8종으로 구성하였다.

하네스	총 실행	엣지 커버리지	예비 크래시
경량 (LPM)	약 2.1억 회	7,840 (protobuf 파싱 영역)	9건
심층 (Session)	약 4,900만 회	12,420 (그래프 검증 영역)	17건

ONNX 퍼징에서 발견한 흥미로운 패턴

심층 하네스에서 발견된 17건의 예비 크래시 중 절반 이상이 그래프 노드 간 텐서 shape이 일치하지 않을 때 발생하는 차원 추론(shape inference) 단계에서 나왔다. 특히 동적 차원(dynamic dimension)을 가진 입력 텐서가 후속 노드의 정적 가정과 충돌하는 케이스가 빈번했다. 이는 ONNX 런타임의 shape inference 로직이 사용자 입력 모델에 대해 충분히 방어적이지 않을 수 있음을 시사한다.

2-5. Triage 모듈과의 첫 E2E 인터페이스 연동

이번 주의 가장 큰 성과는 하네스에서 발견된 크래시가 Triage 모듈로 전달되어 분류·정규화되는 첫 종단 간(End-to-End) 플로우를 완성한 것이다. 이는 전선정 팀원과의 협업으로 이루어졌다.

3주차에 정의한 공통 산출물 구조체 CrashArtifact를 실제로 직렬화/역직렬화하는 코드를 작성하고, 하네스 측에서는 크래시 발생 시 다음 정보를 JSON 형태로 디스크에 기록하도록 변경하였다.

// crashes/crash_20260427_001.json (하네스가 생성)
{
  "crash_id": "crash_20260427_001",
  "format": "gguf",
  "harness_version": "0.4.0",
  "input_path": "crashes/inputs/crash_20260427_001.bin",
  "input_sha256": "3f9a...",
  "input_size": 2412,
  "asan_log": "crashes/logs/crash_20260427_001.asan.log",
  "crash_type": "heap-buffer-overflow",
  "discovered_at": "2026-04-27T03:14:22Z",
  "mutation_strategy": "count_entry_mismatch"
}

Triage 모듈은 이 JSON과 ASan 로그를 읽어 스택 트레이스를 정규화하고 중복 제거를 수행한다. 첫 E2E 테스트에서 GGUF 하네스의 23건 예비 크래시를 Triage에 흘려보낸 결과, 고유 크래시 7건으로 정규화되어 출력되었다. 이는 3주차 종료 시 추정했던 6~8건과 일치하여, 인터페이스가 의도대로 동작함을 확인하였다.

✓ E2E 연동 성공의 의미

"하네스 → 크래시 산출 → Triage → 고유 크래시 분류"라는 파이프라인의 절반이 동작하기 시작했다. 다음 주부터 Triage 결과가 다시 Crash Reproducer(전선정), Report Generator(신숙우·황희주)로 흘러가면서 전체 파이프라인이 완성될 예정이다.

2-6. 빌드 프로세스 자동화

지금까지 GGUF 하네스, ONNX 하네스 2종, Rust 코어를 각각 수동으로 빌드하고 있었으나, 팀 규모가 커지고 모듈이 늘어남에 따라 자동화가 필수가 되었다. CMake와 Cargo의 build.rs를 통합하여 단일 명령으로 전체 시스템이 빌드되도록 구성하였다.

// fuzzer-bridge/build.rs - 하네스 빌드를 Cargo가 자동 트리거
use std::process::Command;

fn main() {
    // 1. CMake로 C/C++ 하네스 빌드 디렉토리 구성
    Command::new("cmake")
        .args(&["-S", "../../harnesses",
               "-B", "../../build/harnesses",
               "-DCMAKE_C_COMPILER=clang",
               "-DCMAKE_CXX_COMPILER=clang++",
               "-DENABLE_FUZZING=ON",
               "-DENABLE_ASAN=ON"])
        .status().expect("cmake configure failed");

    // 2. 하네스 컴파일
    Command::new("cmake")
        .args(&["--build", "../../build/harnesses", "--parallel"])
        .status().expect("harness build failed");

    // 3. 빌드 산출물을 Rust 코어가 찾을 수 있도록 link 경로 출력
    println!("cargo:rustc-link-search=native=../../build/harnesses");
    println!("cargo:rerun-if-changed=../../harnesses");

    // 4. bindgen으로 C 헤더 → Rust 바인딩 생성
    let bindings = bindgen::Builder::default()
        .header("../../harnesses/include/harness_interface.h")
        .generate()
        .expect("bindgen failed");
    bindings.write_to_file("src/bindings.rs").unwrap();
}

이제 팀원 누구나 cargo build --workspace 한 번으로 전체 시스템을 빌드할 수 있다. CI(GitHub Actions)에서도 이 명령 하나로 통합 검증이 이루어진다.

2-7. GGUF 크래시 PoC 최소화 작업

3주차 마지막에 수집한 GGUF 크래시 23건은 Triage를 거쳐 고유 7건으로 정리되었다. 이 7건 각각에 대해 LibFuzzer의 -minimize_crash=1 옵션을 사용하여 PoC를 최소화하는 작업을 수행하였다. 최소화는 ASan 로그의 동일성을 유지하면서 입력 크기를 줄이는 과정으로, 리포트의 가독성과 분석 효율을 크게 향상시킨다.

크래시 ID	유형	원본 크기	최소화 후
GGUF-001	Heap Buffer Overflow	2,412 B	108 B
GGUF-002	OOB Read (메타데이터)	3,856 B	142 B
GGUF-003	Integer Overflow	1,920 B	96 B
GGUF-004	Use-After-Free (의심)	5,312 B	218 B
GGUF-005~007	Stack Overflow (재귀 의존)	평균 4.2 KB	평균 312 B

특히 GGUF-004(Use-After-Free 의심) 케이스는 매우 흥미로운데, ASan 로그상으로는 UAF로 보이지만 동일 입력을 재실행했을 때 일부 환경에서는 재현되지 않는 플레이키(flaky) 특성을 보였다. 메모리 할당기의 동작이 환경 의존적인 결과를 낳는 것으로 보이며, 이는 다음 주 Crash Reproducer 모듈(전선정 팀원)에서 정밀히 검증할 예정이다.

️ 3. 수행 활동

3-1. 개인 수행 활동

GGUF cross-field 뮤테이터 4종(count-entry, offset-size, dim-array, type-size 모순) 신규 구현 및 통합
ONNX 심층 하네스 프로파일링 및 세션 로딩 병목 분석 (perf record 활용)
Ort::Env·SessionOptions 정적화 적용으로 ONNX 심층 하네스 속도 4배 향상
ONNX 경량/심층 하네스 24시간 장시간 퍼징 1차 실행 및 결과 수집
CrashArtifact JSON 직렬화 포맷 확정 및 하네스 측 출력 코드 구현
CMake + Cargo build.rs 통합 빌드 시스템 구축, GitHub Actions CI 워크플로 작성
GGUF 고유 크래시 7건의 PoC 최소화 작업 수행 (평균 95% 이상 크기 감소)

3-2. 팀 활동

온라인 정기 미팅 (04.26, Discord): cross-field 뮤테이션 적용 결과와 ONNX 24시간 퍼징 결과를 공유, 발견된 크래시 패턴에 대한 토론 진행
전선정 팀원과 페어 작업 (04.24~04.25): Triage 모듈과의 인터페이스 연동을 직접 함께 디버깅하며 CrashArtifact 필드를 최종 확정. 특히 ASan 로그 경로 표현 방식(절대 경로 vs 상대 경로)을 두고 논의 후 컨테이너 내부 기준 상대 경로로 통일
멘토링 세션 (04.27): 멘토로부터 cross-field 모순 패턴이 실무 CVE에서도 자주 발견되는 패턴이라는 피드백을 받음. 또한 ONNX shape inference 단계에서 발견된 크래시들이 RCE 가능성이 있을 수 있어 레지스터 분석을 우선적으로 진행하라는 조언 수령
GitHub Actions CI 도입: 빌드 자동화에 이어 PR마다 자동 빌드 + 단위 테스트 실행되도록 구성. 팀 전체의 코드 품질 유지에 기여
중간점검 자료 준비 회의: 5주차에 예정된 중간점검 발표회를 위해 팀원별 진행 상황을 정리하고, 본인은 하네스 및 퍼징 엔진 부분의 슬라이드를 담당하기로 분담

4. 다음 주 계획 (5주차)

계획서상 5주차 키워드: "재현 및 중복 제거 구현"

ONNX 크래시 26건(경량 9 + 심층 17)에 대한 PoC 최소화 및 Triage 입력 작업
Crash Reproducer 모듈(전선정 팀원)과 함께 격리 컨테이너 3회 반복 재현 시스템 검증
GGUF-004(플레이키 UAF) 케이스의 재현 환경 변수 분석 및 안정 재현 조건 도출
하네스 측에서 재현 검증 자동 트리거를 위한 watchdog/timeout 로직 보강
중간점검 발표회 자료 준비 (하네스 및 퍼징 엔진 섹션 담당)
SafeTensors 포맷 사전 조사 (다음 단계 확장 대비)

5. 느낀점 및 회고

4주차는 "퍼징 엔진의 절반"을 완성한 한 주였다. 3주차까지가 단일 하네스의 동작을 검증하는 단계였다면, 4주차는 그 결과물이 다른 모듈로 넘어가 의미 있게 소비되는 첫 순간을 만들어낸 주였다. 내가 만든 하네스에서 나온 23건의 크래시가 Triage 모듈을 거쳐 고유 7건으로 정리되어 출력되는 것을 처음 봤을 때, 그동안 따로따로 개발하던 모듈들이 비로소 하나의 시스템으로 작동하기 시작했다는 실감이 들었다.

Cross-field 뮤테이션을 구현하면서 가장 흥미로웠던 점은, 결국 퍼징의 깊이는 "타깃을 얼마나 잘 이해하느냐"에 비례한다는 것이었다. 단순 바이트 → 단일 필드 → cross-field로 발전할수록 변형의 의미가 풍부해지고, 그만큼 깊은 코드 영역에 도달했다. 이건 단순히 더 많은 코드를 쓴 결과가 아니라, GGUF 포맷의 의존 관계를 더 깊이 이해한 결과였다. 멘토님 말씀처럼 실무 CVE에서 cross-field 모순 패턴이 자주 발견된다는 것이 우연이 아니라는 생각이 들었다.

ONNX 심층 하네스 최적화는 성능 엔지니어링의 즐거움을 다시 느낀 작업이었다. perf record로 병목을 찾아내고, 정확히 그 부분만 정적화하니 성능이 4배 뛰었다. 처음에는 "ONNX는 무거우니 어쩔 수 없다"고 생각했는데, 정량적으로 측정해 보니 변하지 않는 부분(Ort::Env)이 매번 다시 만들어지고 있었던 것이 진짜 원인이었다. "느린 것 같다"는 직관 대신 측정 데이터로 결정하는 습관의 중요성을 다시 한 번 체감했다.

빌드 자동화는 사실 가장 "재미없어 보이는" 작업이었지만, 그 효과는 즉각적으로 체감되었다. 팀원들이 "어떻게 빌드하는지 모르겠다"는 질문을 하던 것이 사라지고, GitHub Actions가 PR마다 자동으로 검증해 주니 코드 리뷰의 부담도 줄었다. 인프라 작업이 결국 팀의 속도를 좌우하는 곱셈 인자라는 것을 느꼈다.

다음 주는 중간점검이 있다. 그동안 만든 하네스와 뮤테이터, 그리고 처음으로 동작한 E2E 플로우를 발표 자료로 정리하면서, 4주간의 진행을 객관화해 볼 수 있을 것 같다. 동시에 5주차는 "재현 및 중복 제거 구현" 단계이므로, 내가 만든 크래시들이 실제로 안정 재현되는지를 전선정 팀원과 함께 확정하는 것이 핵심 과제가 될 것이다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 3주차

mysticprayer — Mon, 20 Apr 2026 13:16:35 +0900

[미래내일 일경험] 테크노트 - 3주차

구조 인식 뮤테이터 구현 및 ONNX 하네스 확장 | 2026.04.13 ~ 04.19

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

GGUF 구조 인식 커스텀 뮤테이터 설계 및 구현 착수
ONNX 포맷 내부 구조 분석 및 onnxruntime 대상 하네스 프로토타입 작성
퍼징 실행 시간 24시간 확장을 통한 깊은 커버리지 확보
2주차 예비 크래시 2건에 대한 재현 검증 지원 (전선정 팀원 협업)
포맷 연동 인터페이스 표준화를 통한 다중 타깃 확장성 확보

2. 학습 및 수행 내용

2-1. 구조 인식 뮤테이터(Structure-Aware Mutator)의 필요성 재확인

2주차 말미에 수행한 GGUF 하네스 퍼징 결과에서 가장 핵심적으로 드러난 문제는, 단순 바이트 뮤테이션 방식으로는 대부분의 입력이 매직 넘버 검증 단계에서 즉시 기각된다는 점이었다. 24시간으로 확장한 퍼징을 돌리더라도 이 구조적 한계를 넘지 않는 한, 파서의 깊은 로직에 도달하는 입력의 비율은 극히 낮게 유지된다.

이번 주에는 이 문제를 해결하기 위해 LibFuzzer가 제공하는 LLVMFuzzerCustomMutator 인터페이스를 활용한 구조 인식 뮤테이터를 설계하였다. 이 뮤테이터는 GGUF 파일의 구조를 이해하고, 파서가 거부하지 않는 수준의 형식적 유효성을 유지하면서 내부 필드만 변형하는 것을 목표로 한다.

구조 인식 뮤테이터의 설계 원칙

불변 필드 보존: 매직 넘버(GGUF), 지원되는 버전 번호(v3)는 뮤테이션 대상에서 제외하여 파서 진입을 보장
경계값 집중 공략: 텐서 개수, 메타데이터 KV 개수, 문자열 길이 필드 등 정수형 필드는 경계값(0, UINT64_MAX, INT_MAX+1 등)으로 집중 변형
오프셋/크기 불일치 유도: 텐서 오프셋과 실제 데이터 크기 간의 모순을 의도적으로 생성하여 OOB Read/Write 유도
LibFuzzer 기존 엔진과 병행: 구조 인식 뮤테이션과 일반 바이트 뮤테이션을 확률적으로 섞어 적용(80:20 비율)하여 예상치 못한 입력 조합도 탐색

2-2. GGUF 구조 인식 뮤테이터 구현

LibFuzzer의 커스텀 뮤테이터 인터페이스는 퍼저가 새 입력을 생성할 때마다 사용자가 정의한 함수를 호출하도록 한다. 구현한 뮤테이터의 핵심 구조는 다음과 같다.

// 커스텀 뮤테이터 엔트리 포인트
size_t LLVMFuzzerCustomMutator(uint8_t *data, size_t size,
                                size_t max_size, unsigned int seed) {
    struct gguf_view view;
    if (!parse_gguf_layout(data, size, &view)) {
        // 구조 해석 실패 시 LibFuzzer 기본 뮤테이터로 폴백
        return LLVMFuzzerMutate(data, size, max_size);
    }

    // 확률적으로 타깃 필드 선택
    int strategy = seed % 5;
    switch (strategy) {
        case 0: return mutate_tensor_count(data, size, max_size, &view);
        case 1: return mutate_kv_string_length(data, size, max_size, &view);
        case 2: return mutate_tensor_offset(data, size, max_size, &view);
        case 3: return mutate_tensor_dimensions(data, size, max_size, &view);
        default: return LLVMFuzzerMutate(data, size, max_size);
    }
}

// 텐서 개수 필드를 경계값으로 변형
size_t mutate_tensor_count(uint8_t *data, size_t size,
                           size_t max_size, struct gguf_view *view) {
    static const uint64_t boundary_values[] = {
        0, 1, 0xFFFFFFFF, 0xFFFFFFFFFFFFFFFF,
        0x80000000, view->tensor_count + 1, view->tensor_count - 1
    };
    uint64_t new_count = boundary_values[rand() % 7];
    memcpy(data + view->tensor_count_offset, &new_count, sizeof(uint64_t));
    return size;
}

위 뮤테이터를 기존 하네스에 연결하여 1시간 단위의 짧은 퍼징 세션을 수행한 결과, 2주차 대비 다음과 같은 개선을 확인하였다.

지표	2주차 (바이트 뮤테이션)	3주차 (구조 인식)	증감
엣지 커버리지	1,847	3,412	+84.7%
유효 입력 비율	약 3%	약 72%	+69%p
예비 크래시 수	2건 (10분)	7건 (1시간)	시간당 발견율 상승

2-3. ONNX 포맷 구조 분석

다음 타깃인 ONNX(Open Neural Network Exchange) 포맷은 GGUF와 달리 Protocol Buffers(이하 protobuf) 기반으로 직렬화된다. 이는 퍼징 관점에서 GGUF와 완전히 다른 접근을 요구한다.

비교 항목	GGUF	ONNX
직렬화 방식	커스텀 바이너리 포맷 (고정 헤더 + TLV 구조)	Protocol Buffers (가변 길이 태그/필드)
매직 넘버	있음 (`GGUF`)	없음 (protobuf 필드 태그로 판별)
핵심 취약 지점	텐서 오프셋, 문자열 길이 필드	Shape 불일치, 그래프 노드 간 타입 불일치, 외부 데이터 참조
파싱 엔트리	`gguf_init_from_file()`	`Ort::Session::Session()`, `onnx::ModelProto::ParseFromArray()`

⚠️ ONNX 퍼징의 기술적 도전 과제

두 단계 파싱: onnxruntime은 먼저 protobuf 역직렬화를 수행하고, 이후 그래프 검증 단계에서 shape inference와 타입 체크를 수행한다. 각 단계에 서로 다른 취약점 패턴이 존재한다.
순수 바이트 뮤테이션의 한계: 바이트 변형을 가하면 대부분 protobuf 역직렬화 단계에서 실패하여 그래프 검증 로직까지 도달하지 못한다. libprotobuf-mutator(LPM)를 사용한 프로토콜 인식 뮤테이션이 필수적이다.
세션 초기화 오버헤드: Ort::Session 생성 자체가 무거운 연산이므로, 순수 ModelProto::ParseFromArray()를 먼저 타깃으로 삼아 파싱 단계의 버그부터 집중 탐색하는 이중 하네스 전략을 채택.

2-4. ONNX 퍼징 하네스 프로토타입 구현

ONNX 대상 하네스는 두 가지 레벨로 분리하여 작성하였다. 하나는 protobuf 파싱 단계만 타깃하는 경량 하네스, 다른 하나는 세션 로딩까지 수행하는 심층 하네스이다.

// fuzz_onnx_parse.cc - 경량 하네스 (ModelProto 파싱만 수행)
#include "onnx/onnx.pb.h"
#include <src/libfuzzer/libfuzzer_macro.h>

// libprotobuf-mutator를 활용한 구조 인식 퍼징
DEFINE_PROTO_FUZZER(const onnx::ModelProto& model) {
    // 그래프 기본 검증 로직 호출
    if (!model.has_graph()) return;
    const auto& graph = model.graph();
    
    // 노드 타입 검증을 유도하는 로직
    for (const auto& node : graph.node()) {
        (void)node.op_type();
        for (const auto& attr : node.attribute()) {
            (void)attr.name();
        }
    }
}

// fuzz_onnx_session.cc - 심층 하네스 (Ort::Session 로딩까지 수행)
#include "onnxruntime_cxx_api.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    // 과도하게 큰 모델은 스킵 (퍼징 속도 유지)
    if (size > 1024 * 512) return 0;

    try {
        Ort::Env env(ORT_LOGGING_LEVEL_FATAL, "fuzz");
        Ort::SessionOptions opts;
        opts.SetIntraOpNumThreads(1);
        opts.SetGraphOptimizationLevel(ORT_DISABLE_ALL);
        Ort::Session session(env, data, size, opts);  // 퍼징 타깃
    } catch (const Ort::Exception&) {
        // 정상적인 예외는 무시 (크래시만 탐지 대상)
    } catch (const std::exception&) {}
    return 0;
}

두 하네스의 역할 분담은 다음과 같다.

경량 하네스(fuzz_onnx_parse): libprotobuf-mutator(LPM)의 DEFINE_PROTO_FUZZER 매크로를 사용하여 구조적으로 유효한 ModelProto를 직접 생성한다. 이로써 바이트 레벨 무작위 변형에 쓰이던 시간을 절약하고 의미 있는 입력을 집중 생성한다.

심층 하네스(fuzz_onnx_session): 경량 하네스에서 발견한 흥미로운 시드를 입력으로 삼아, 실제 세션 생성 단계까지 실행한다. shape inference, 타입 체크, 메모리 할당 로직까지 도달하여 RCE 가능성이 있는 심층 취약점을 노린다.

초기 빌드 및 5분간 스모크 테스트 결과, 경량 하네스는 초당 약 1,200회 실행되었고 심층 하네스는 초당 약 35회 실행 속도를 보였다. 심층 하네스의 속도 차이는 크지만, 도달 가능한 코드 영역이 훨씬 넓어 상호 보완적으로 운영할 예정이다.

2-5. 포맷 연동 인터페이스 표준화

GGUF와 ONNX 외에도 향후 SafeTensors, PyTorch(.pt) 등 다양한 포맷을 추가해야 하므로, 각 포맷별 하네스가 공통 인터페이스를 따르도록 표준화 작업을 진행하였다. Rust 코어와 C/C++ 하네스 간의 연동 지점을 단일화하여, 새 포맷 추가 시 코어 수정 없이 하네스만 플러그인 형태로 연결할 수 있는 구조를 설계하였다.

// harness_interface.h - 모든 하네스가 따를 공통 인터페이스
typedef struct {
    const char* format_name;       // "gguf", "onnx" 등
    const char* harness_version;
    int (*init)(void);
    int (*run_one)(const uint8_t* data, size_t size);
    void (*cleanup)(void);
} harness_plugin_t;

// Rust 측 호출 (fuzzer-bridge 크레이트)

// fuzzer-bridge/src/harness.rs
pub trait HarnessPlugin {
    fn format_name(&self) -> &str;
    fn spawn_fuzzer(&self, config: &FuzzConfig) -> Result<FuzzJobHandle>;
    fn collect_artifacts(&self, job: &FuzzJobHandle) -> Result<Vec<CrashArtifact>>;
}

pub struct GgufHarness { /* ... */ }
pub struct OnnxHarness { /* ... */ }

impl HarnessPlugin for GgufHarness { /* ... */ }
impl HarnessPlugin for OnnxHarness { /* ... */ }

인터페이스 표준화의 이점

이 구조 덕분에 Triage 모듈(전선정 팀원)이나 Report Generator 모듈(신숙우·황희주 팀원)은 하네스의 포맷별 세부사항을 알 필요 없이 CrashArtifact라는 공통 산출물만 소비하면 된다. 팀원 간의 개발 의존성이 줄어들어 병렬 작업이 가능해졌다.

2-6. 24시간 확장 퍼징 실행 및 시드 코퍼스 강화

구조 인식 뮤테이터를 적용한 GGUF 하네스로 24시간 장시간 퍼징을 수행하였다. 퍼징 안정성을 위해 Docker 컨테이너 내부에서 실행하고, -rss_limit_mb=2048, -timeout=60, -fork=4 옵션으로 4개 워커를 병렬 구동하였다.

구간	실행 횟수	엣지 커버리지	크래시 누적
0~6시간	약 1,850만 회	4,120	14건
6~12시간	약 3,400만 회	4,780	19건
12~24시간	약 6,800만 회	5,103	23건 (중복 포함)

수집된 23건의 크래시는 스택 트레이스 기반으로 1차 중복 제거 시 약 6~8건의 고유 크래시로 추정된다. 정확한 중복 제거는 Triage 모듈(전선정 팀원 담당)에 넘겨 다음 주에 함께 확정할 예정이다. 또한 커버리지를 확장한 입력들은 다음 차수 퍼징을 위한 시드 코퍼스로 자동 편입되었다.

2-7. 2주차 예비 크래시 재현 검증 지원

2주차에 발견한 예비 크래시 2건에 대해 전선정 팀원과 협업하여 재현 검증을 지원하였다. 재현 검증 결과는 다음과 같다.

크래시 ID	오류 유형	발생 위치	재현 결과
CRASH-W2-001	Heap Buffer Overflow	GGUF 메타데이터 문자열 파싱	✓ 3/3 재현 성공
CRASH-W2-002	Assertion Failure	텐서 타입 검증	✗ 재현 실패 (환경 의존성 의심)

CRASH-W2-001은 안정적으로 재현되어 심층 분석 후보로 확정되었다. 하네스 담당자로서 해당 입력을 최소화(minimize)하는 작업을 수행하여 원본 2.4KB에서 108바이트까지 축소된 PoC를 생성하였다. 이는 이후 리포트에 포함될 재현 증거로 활용된다.

️ 3. 수행 활동

3-1. 개인 수행 활동

GGUF 구조 인식 커스텀 뮤테이터 설계 및 4종 변형 전략(텐서 개수, KV 문자열 길이, 텐서 오프셋, 텐서 차원) 구현
ONNX 포맷 명세(onnx.proto) 정독 및 GGUF와의 구조적 차이점 분석
libprotobuf-mutator(LPM) 빌드 및 통합, 경량/심층 ONNX 하네스 2종 프로토타입 작성
하네스 공통 인터페이스(harness_plugin_t) 설계 및 Rust HarnessPlugin trait 정의
Docker 컨테이너에서 24시간 장시간 퍼징 실행 및 결과 수집
CRASH-W2-001 PoC 최소화(2.4KB → 108바이트) 수행
퍼징 결과 로그 자동 집계를 위한 Python 스크립트 작성

3-2. 팀 활동

온라인 정기 미팅 (04.19, Discord): 구조 인식 뮤테이터 적용 전후의 커버리지 비교 결과를 공유하고, ONNX 하네스 이중 구조 전략에 대한 팀원 피드백 수렴
오프라인 미팅 (04.20): 청주에서 팀원 전원이 모여 모듈 간 인터페이스(CrashArtifact 구조체)를 확정하고, 각자 맡은 모듈의 진행 상황을 공유
전선정 팀원과 협업: 2주차 예비 크래시 2건의 재현 검증을 함께 진행하고, 재현 실패 원인(CRASH-W2-002)의 환경 변수 차이를 분석
멘토링 세션 참여: 멘토로부터 구조 인식 뮤테이션 전략에 대한 자문을 받아, 단일 필드 변형뿐 아니라 필드 간 상호 의존성(cross-field)을 깨는 변형도 추후 추가하기로 결정
GitHub PR 리뷰: 뮤테이터와 ONNX 하네스 PR에 대해 팀장(신숙우) 및 다른 팀원들의 코드 리뷰를 받고 머지 완료

4. 다음 주 계획 (4주차)

GGUF 뮤테이터에 필드 간 상호 의존성(cross-field) 변형 전략 추가 구현
ONNX 심층 하네스의 세션 로딩 속도 최적화(세션 풀링, 초기화 비용 감소)
ONNX 대상 24시간 장시간 퍼징 1차 실행 및 결과 분석
Triage 모듈(전선정 팀원)과의 인터페이스 연동 테스트 — CrashArtifact 산출 검증
하네스 빌드 프로세스 자동화 (CMake + build.rs 통합 빌드 스크립트)
3주차에 수집한 GGUF 크래시 6~8건에 대한 PoC 최소화 및 재현 검증 지원

5. 느낀점 및 회고

3주차는 이론과 설계가 실제 성능 향상으로 이어지는 것을 체감한 한 주였다. 2주차에 확인한 "매직 넘버에서 막히는 문제"를 구조 인식 뮤테이터로 해결하자 엣지 커버리지가 84% 상승하고 유효 입력 비율이 3%에서 72%로 치솟았다. 숫자가 극적으로 변하는 것을 직접 눈으로 보니, 퍼징이 단순히 "많이 돌리는 것"이 아니라 "얼마나 의미 있는 입력을 많이 돌리느냐"의 싸움이라는 것이 확실하게 와닿았다.

ONNX 퍼징을 설계하면서 가장 크게 느낀 점은, 포맷이 달라지면 퍼징 전략도 완전히 달라져야 한다는 것이었다. GGUF는 커스텀 바이너리 포맷이라 수동 구조 파싱이 필수였지만, ONNX는 protobuf 기반이라 libprotobuf-mutator라는 기성 도구를 활용할 수 있었다. "포맷의 특성을 읽고 그에 맞는 도구를 선택하는" 감각이 중요하다는 것을 배웠다.

하네스 공통 인터페이스를 설계하면서는 소프트웨어 아키텍처의 힘을 느꼈다. 처음에는 GGUF 하네스 하나만 만들면 될 것 같아 인터페이스를 나중으로 미뤘었는데, ONNX 하네스를 추가하면서 기존 코드와 중복되는 부분이 너무 많아져 결국 인터페이스부터 정의해야 했다. 팀원들과의 모듈 간 결합을 느슨하게 만드는 것은 단순히 코드 품질 문제가 아니라 팀의 개발 속도와 직결된 문제였다.

오프라인 미팅에서 팀원들과 직접 모여 논의하면서, 그동안 비동기 Discord로 주고받던 내용들이 얼마나 많은 오해를 내포하고 있었는지도 깨달았다. 특히 CrashArtifact 구조체의 필드 하나를 두고 40분 넘게 토론한 끝에, 각자가 다른 의미로 사용하고 있었다는 것을 확인하게 되었다. 정기적인 오프라인 미팅의 중요성을 다시 느꼈다.

다음 주에는 ONNX 대상 장시간 퍼징과 Triage 모듈 연동 테스트가 핵심이다. 내가 만든 하네스에서 나오는 크래시들이 실제로 Triage 파이프라인을 타고 검증·분류·리포트까지 이어지는 첫 E2E 플로우를 완성하는 주가 될 것이다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 2주차

mysticprayer — Sun, 12 Apr 2026 20:21:39 +0900

[미래내일 일경험] 테크노트 - 2주차

시스템 아키텍처 설계 및 하네스 프로토타입 개발 | 2026.04.06 ~ 04.12

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

전체 시스템 아키텍처 설계 및 모듈 구조도 작성
GGUF 포맷 대상 퍼징 하네스 프로토타입 구현
LibFuzzer 기반 퍼징 실행 환경 구축 및 첫 퍼징 수행
Rust 프로젝트 스캐폴딩 및 Cargo workspace 초기 구성
Rust-C FFI 연동 검증

2. 학습 및 수행 내용

2-1. 시스템 아키텍처 설계

1주차에 조사한 기술 스택과 파이프라인 구조를 바탕으로, 전체 시스템의 아키텍처를 구체적으로 설계하였다. 시스템은 크게 4개의 핵심 모듈로 구성된다.

① Fuzzing Engine 모듈
LibFuzzer 기반의 퍼징 실행 엔진으로, 구조 인식 뮤테이터와 커버리지 수집기를 포함한다. 타깃별 하네스를 로드하여 퍼징을 수행하며, 크래시 발생 시 해당 입력을 자동으로 저장한다. C/C++로 구현한다.

② Crash Reproducer 모듈
발견된 크래시를 격리된 Docker 컨테이너에서 3회 반복 재현하여 유효성을 검증하는 모듈이다. 재현 실패 시 환경 차이 로그를 기록하고, 재현 성공 시 ASan 로그와 함께 다음 단계로 전달한다. 전선정 팀원이 주로 담당한다.

③ Triage & Analysis 모듈
재현된 크래시의 스택 트레이스를 정규화하여 중복을 제거하고, 메모리 오염 유형(힙 오버플로우, UAF, 스택 오버플로우 등)과 레지스터 상태를 분석하여 RCE 가능성 등 심각도를 자동 분류한다. 전선정 팀원이 담당한다.

④ Report Generator 모듈
검증이 완료된 취약점에 대해 HackerOne 표준 양식의 버그바운티 리포트를 자동 생성한다. 재현 커맨드, 입력 파일 해시, ASan 로그, 스택 트레이스 등을 하나의 증거 번들로 패키징한다. 신숙우 팀장과 황희주 팀원이 담당한다.

이 네 모듈을 연결하는 중앙 제어 역할은 Rust 기반 Job Queue가 담당한다. tokio 비동기 런타임 위에서 퍼징 작업을 스케줄링하고, 각 모듈 간 데이터 흐름을 관리한다.

설계 시 고려한 핵심 원칙

모듈 간 느슨한 결합: 각 모듈은 파일 시스템(크래시 디렉토리, 리포트 디렉토리) 기반으로 데이터를 주고받아 독립적으로 개발 및 테스트 가능
장애 격리: 퍼징 중 타깃 바이너리의 무한 루프나 메모리 초과가 발생해도 Watchdog이 프로세스를 강제 종료하여 플랫폼 전체의 안정성 유지
확장성: 새로운 타깃 포맷(SafeTensors 등)을 추가할 때 하네스와 뮤테이터만 추가하면 나머지 파이프라인은 재사용 가능하도록 설계

2-2. GGUF 포맷 구조 분석 및 하네스 설계

하네스 프로토타입 작성에 앞서 GGUF 파일 포맷의 내부 구조를 상세히 분석하였다. GGUF는 llama.cpp 프로젝트에서 사용하는 AI 모델 저장 포맷으로, 다음과 같은 계층 구조를 갖는다.

영역	주요 필드	퍼징 관점의 의미
매직 넘버	`GGUF` (4바이트)	파일 유효성 검증의 첫 관문. 뮤테이션 시 보존해야 파서 깊은 로직까지 도달 가능
헤더	버전, 텐서 개수, 메타데이터 KV 개수	텐서 개수와 실제 데이터 간 불일치를 유도하면 경계 조건 버그 탐지 가능
메타데이터 KV	모델명, 아키텍처, 양자화 정보 등	문자열 길이 필드 조작으로 버퍼 오버리드/오버플로우 유발 가능성
텐서 정보	이름, 차원, 타입, 오프셋	오프셋 값 조작으로 범위 밖 읽기(OOB Read) 유도 가능
정렬 패딩	32바이트 경계 정렬	정렬 오프셋 계산 오류 시 잘못된 메모리 접근 발생 가능
텐서 데이터	실제 가중치 바이너리	크기가 매우 크므로 최소 시드에서는 축소하여 퍼징 효율 확보

이 분석을 바탕으로 하네스의 퍼징 진입점을 gguf_init_from_file() 함수로 선정하였다. 이 함수는 GGUF 파일을 메모리에 로드하고 파싱하는 핵심 함수로, 헤더 파싱부터 텐서 메타데이터 읽기까지 전체 파싱 로직을 포함한다.

2-3. GGUF 퍼징 하네스 프로토타입 구현

LibFuzzer 기반의 GGUF 퍼징 하네스 프로토타입을 C로 작성하였다. 핵심 구조는 다음과 같다.

int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // 1. 퍼저가 생성한 데이터를 임시 파일로 저장
    char tmpfile[] = "/tmp/fuzz_gguf_XXXXXX";
    int fd = mkstemp(tmpfile);
    write(fd, data, size);
    close(fd);

    // 2. GGUF 파싱 함수 호출 (퍼징 대상)
    struct gguf_init_params params = { .no_alloc = true, .ctx = NULL };
    struct gguf_context *ctx = gguf_init_from_file(tmpfile, params);

    // 3. 리소스 정리
    if (ctx) gguf_free(ctx);
    unlink(tmpfile);
    return 0;
}

⚠️ 하네스 작성 시 주의사항

메모리 누수 방지: 매 퍼징 반복마다 gguf_free()로 할당된 메모리를 해제해야 한다. 누수가 누적되면 ASan이 OOM으로 오탐할 수 있다.
임시 파일 관리: gguf_init_from_file()은 파일 경로를 인자로 받으므로 퍼저 데이터를 임시 파일로 기록 후 전달한다. 매 반복 후 unlink()로 삭제하여 디스크 공간 고갈을 방지한다.
no_alloc 옵션: 텐서 데이터 전체를 메모리에 로드하면 퍼징 속도가 현저히 저하되므로, no_alloc = true로 설정하여 메타데이터 파싱만 수행하도록 한다.

2-4. LibFuzzer 빌드 및 첫 퍼징 실행

작성한 하네스를 LibFuzzer + ASan으로 빌드하고, 첫 퍼징을 수행하였다. 빌드 명령은 다음과 같다.

# llama.cpp 소스와 함께 하네스 빌드
clang++ -g -O1 -fsanitize=fuzzer,address \
    -I./include -I./ggml/include \
    fuzz_gguf.c ./src/ggml.c ./src/gguf.c \
    -o fuzz_gguf

# 시드 코퍼스 디렉토리 구성
mkdir -p corpus/gguf
# 최소 유효 GGUF 파일을 시드로 배치
cp minimal_test.gguf corpus/gguf/

# 퍼징 실행 (최대 메모리 2GB, 입력 크기 제한 100KB)
./fuzz_gguf corpus/gguf/ -max_len=102400 -rss_limit_mb=2048

약 10분간의 초기 퍼징 결과를 요약하면 다음과 같다.

항목	결과	비고
총 실행 횟수	약 85,000회	인프로세스 퍼징으로 초당 약 140회 실행
커버리지 증가	엣지 커버리지 312 → 1,847	시드 코퍼스 투입 후 빠르게 증가
크래시 발견	2건 (예비)	헤더 파싱 단계에서 발생, 추후 재현 검증 필요
주요 발견	매직 넘버 보존 필요 확인	매직 넘버가 깨진 입력은 파서가 즉시 거부하여 깊은 로직 도달 불가

초기 퍼징에서 얻은 인사이트

단순 바이트 뮤테이션만으로는 대부분의 입력이 매직 넘버 검증 단계에서 걸러진다. 이는 1주차에 조사한 구조 인식 뮤테이터의 필요성을 실제 데이터로 확인한 것이다. 3주차부터는 GGUF 헤더의 매직 넘버와 버전 필드를 보존하면서 나머지 영역만 변형하는 커스텀 뮤테이터를 구현할 계획이다.

2-5. Rust 프로젝트 초기 구성 및 FFI 연동 검증

플랫폼 코어가 될 Rust 프로젝트의 초기 구조를 Cargo workspace로 구성하였다.

bugbounty-platform/
├── Cargo.toml              # workspace 루트
├── crates/
│   ├── core/               # Job Queue, 스케줄러, Watchdog
│   │   ├── Cargo.toml
│   │   └── src/lib.rs
│   ├── fuzzer-bridge/      # C 하네스 FFI 바인딩
│   │   ├── Cargo.toml
│   │   ├── build.rs        # bindgen으로 C 헤더 바인딩 자동 생성
│   │   └── src/lib.rs
│   ├── triage/             # 크래시 분석, 스택 정규화
│   │   ├── Cargo.toml
│   │   └── src/lib.rs
│   └── reporter/           # 리포트 생성
│       ├── Cargo.toml
│       └── src/lib.rs
├── harnesses/              # C/C++ 하네스 소스
│   ├── gguf/
│   │   └── fuzz_gguf.c
│   └── onnx/               # (추후 구현)
└── scripts/                # Python 보조 스크립트

FFI 연동 검증을 위해 fuzzer-bridge 크레이트에서 간단한 C 함수를 호출하는 테스트를 수행하였다.

// build.rs - bindgen으로 C 헤더 바인딩 생성
fn main() {
    let bindings = bindgen::Builder::default()
        .header("wrapper.h")
        .generate()
        .expect("Unable to generate bindings");
    
    let out_path = PathBuf::from(env::var("OUT_DIR").unwrap());
    bindings.write_to_file(out_path.join("bindings.rs"))
        .expect("Couldn't write bindings");
}

// src/lib.rs - FFI 호출 테스트
mod ffi {
    include!(concat!(env!("OUT_DIR"), "/bindings.rs"));
}

pub fn validate_gguf_magic(data: &[u8]) -> bool {
    data.len() >= 4 && &data[..4] == b"GGUF"
}

cargo test를 실행하여 Rust에서 C 함수 호출이 정상적으로 이루어지는 것을 확인하였다. 이로써 Rust 코어 ↔ C 하네스 간의 기본적인 통신 경로가 검증되었다.

️ 3. 수행 활동

3-1. 개인 수행 활동

llama.cpp 소스코드 중 GGUF 파싱 관련 코드(gguf.c, ggml.c) 정독 및 분석
GGUF 최소 유효 시드 파일 직접 제작 (매직 넘버 + 버전 + 빈 메타데이터 + 빈 텐서)
LibFuzzer + ASan 빌드 환경 구축 (Clang 17, LLVM 17 설치 및 설정)
GGUF 퍼징 하네스 프로토타입 작성 및 첫 퍼징 실행
Cargo workspace 초기 프로젝트 구조 설계 및 생성
bindgen 크레이트를 활용한 FFI 바인딩 생성 테스트 수행

3-2. 팀 활동

온라인 정기 미팅 (04.12, Discord): 시스템 아키텍처 설계안을 공유하고 팀원들의 피드백을 반영하여 모듈 간 인터페이스를 확정
아키텍처 설계 문서 작성: Notion에 전체 시스템 구조도, 모듈별 책임 범위, 데이터 흐름도를 정리하여 공유
GitHub 프로젝트 보드 구성: 이슈 템플릿, PR 규칙, 브랜치 전략(Git Flow)을 설정하고 각 팀원의 담당 이슈를 등록
초기 퍼징 결과 공유: 첫 퍼징에서 발견된 2건의 예비 크래시를 팀에 공유하고, 재현 검증 계획을 논의

4. 다음 주 계획 (3주차)

GGUF 구조 인식 커스텀 뮤테이터 설계 및 구현 착수 (매직 넘버/버전 보존, 메타데이터 영역 집중 변형)
ONNX 포맷 분석 및 onnxruntime 대상 하네스 프로토타입 작성
Rust Job Queue 코어 로직 구현 시작 (tokio 기반 비동기 작업 스케줄러)
예비 크래시 2건에 대한 재현 테스트 수행 (전선정 팀원과 협업)
퍼징 실행 시간을 24시간으로 확장하여 더 깊은 커버리지 확보

5. 느낀점 및 회고

2주차는 1주차의 이론 조사를 바탕으로 실제 코드를 작성하고 퍼징을 실행해 본 첫 주였다. 가장 의미 있었던 경험은 GGUF 하네스를 직접 작성하고 LibFuzzer로 첫 퍼징을 돌려본 것이다. 수십 초 만에 커버리지가 빠르게 올라가는 것을 보면서 커버리지 유도 퍼징의 효과를 체감할 수 있었다.

동시에 한계도 명확히 드러났다. 대부분의 입력이 매직 넘버 검증에서 즉시 거부되어 파서의 깊은 로직까지 도달하지 못하는 문제가 있었다. 이 문제는 구조 인식 뮤테이터를 통해 해결해야 하며, 3주차의 핵심 과제가 될 것이다.

Rust 프로젝트 구조를 설계하면서 Cargo workspace의 편리함을 느꼈다. 여러 크레이트를 하나의 워크스페이스에서 관리하면서도 각 모듈을 독립적으로 빌드하고 테스트할 수 있어, 팀원들이 병렬로 개발을 진행하기에 적합한 구조라고 생각한다. FFI 연동도 bindgen 덕분에 예상보다 수월하게 진행되었다.

이번 주를 통해 "설계 → 구현 → 실행 → 피드백"의 한 사이클을 빠르게 돌려본 것이 큰 수확이다. 다음 주부터는 이 피드백을 바탕으로 뮤테이터를 고도화하고 ONNX 포맷으로 퍼징 대상을 확장할 예정이다.

6. 참고 자료

[2026 ABC 프로젝트 멘토링 3기] 프로젝트 1주차

mysticprayer — Mon, 6 Apr 2026 13:21:06 +0900

[미래내일 일경험] 테크노트 - 1주차

사전 조사 및 기술 스택 선정 | 2026.04.01 ~ 04.05

프로젝트명	AI 기반 퍼징을 활용한 취약점 탐지 및 검증 자동화 시스템
팀명	The First	작성자	이우곤
담당 역할	하네스 개발, 퍼징 파이프라인 구축, 포맷 연동 구현

1. 금주 학습 목표

퍼징(Fuzzing)의 개념과 원리 이해
AI 모델 파일(GGUF, ONNX) 대상 퍼징의 필요성 조사
하네스 개발 및 퍼징 파이프라인 구축을 위한 기술 스택 조사 및 선정
프로젝트 개발 환경 구성 및 팀 협업 체계 수립

2. 학습 및 조사 내용

2-1. 퍼징(Fuzzing)이란?

퍼징(Fuzzing)이란 소프트웨어의 입력값에 무작위 또는 변형된 데이터를 대량으로 주입하여 프로그램의 예기치 않은 동작(크래시, 메모리 오류 등)을 유발하는 자동화된 보안 테스팅 기법이다. 1988년 위스콘신대학교 Barton Miller 교수의 연구에서 유래하였으며, 현재는 구글, 마이크로소프트 등 주요 기업에서 소프트웨어 품질 보증의 핵심 도구로 활용되고 있다.

퍼징은 크게 세 가지 유형으로 분류된다.

① 블랙박스 퍼징 (Black-box Fuzzing)
프로그램의 내부 구조를 모른 채 무작위 입력을 생성하는 방식. 구현이 간단하지만 코드 커버리지가 낮다.

② 화이트박스 퍼징 (White-box Fuzzing)
소스코드 분석 및 심볼릭 실행을 통해 입력을 생성. 정밀하지만 비용이 높다.

③ 그레이박스 퍼징 (Grey-box Fuzzing)
코드 커버리지 피드백을 활용해 입력을 진화시키는 방식. 효율성과 정밀성의 균형을 갖추며,

본 프로젝트에서 채택하는 방식이다.

퍼징의 핵심 구성요소는 다음과 같다.

시드 코퍼스(Seed Corpus) — 초기 입력 데이터 집합
뮤테이터(Mutator) — 입력을 변형하는 엔진
하네스(Harness) — 타깃 프로그램을 퍼저에 연결하는 래퍼 코드
크래시 트리아지(Crash Triage) — 발견된 크래시를 분류하고 중복을 제거하는 과정

2-2. AI 모델 대상 퍼징의 필요성

최근 대규모 언어 모델(LLM)의 확산으로 GGUF, ONNX, SafeTensors 등 AI 모델 파일 포맷의 사용이 급증하고 있다. 이러한 파일들은 복잡한 바이너리 구조를 가지며, 파서(Parser) 단계에서의 메모리 안전성 문제가 심각한 보안 위협으로 대두되고 있다.

⚠️ AI 모델 파일 퍼징이 필요한 이유

파서 취약점의 위험성: llama.cpp, onnxruntime 등 주요 추론 엔진이 C/C++로 작성되어 있어 버퍼 오버플로우, Use-After-Free 등 메모리 커럽션 취약점에 노출됨
공급망 공격 가능성: 악의적으로 조작된 모델 파일이 Hugging Face 등 모델 허브를 통해 유포될 경우, 이를 로드하는 시스템에서 원격 코드 실행(RCE)이 발생할 수 있음
기존 도구의 한계: 현재 공개된 퍼저들은 단순 크래시 탐지에 그치며, 실제 악용 가능한 취약점인지 검증하는 기능이 부재
구조 인식의 필요: AI 모델 파일은 텐서 데이터, 메타데이터, 정렬 패딩 등 복잡한 구조를 가지므로 단순 바이트 뮤테이션으로는 파서 깊숙한 로직까지 도달하기 어려움

2-3. 하네스 개발 기술 조사

하네스(Harness)는 퍼징 대상 프로그램의 특정 함수를 직접 호출하여 퍼저와 연결하는 역할을 한다. 본 프로젝트에서는 llama.cpp와 onnxruntime의 모델 로딩 함수를 대상으로 하네스를 작성할 계획이다.

LibFuzzer 하네스 구조: LLVMFuzzerTestOneInput 함수를 진입점으로 사용하며, 퍼저가 생성한 데이터를 타깃 함수에 전달한다.
ASan(AddressSanitizer) 연동: 컴파일 시 -fsanitize=address 플래그를 적용하여 힙 버퍼 오버플로우, 스택 버퍼 오버플로우, Use-After-Free, 이중 해제 등 메모리 오류를 정밀하게 탐지한다.
FFI(Foreign Function Interface) 연동: Rust에서 C/C++ 함수를 호출하기 위해 extern "C" 블록과 bindgen 크레이트를 활용하며, Rust 기반 플랫폼 코어에서 C/C++ 하네스를 제어한다.

2-4. 퍼징 파이프라인 아키텍처 조사

퍼징 파이프라인은 시드 입력 생성부터 크래시 분석까지의 전체 워크플로우를 의미한다. 본 프로젝트에서 구축할 파이프라인의 주요 단계는 다음과 같다.

1️⃣ 시드 수집 → 공개 GGUF/ONNX 모델에서 최소 유효 시드를 추출하고 포맷별 시드 코퍼스 구성

2️⃣ 뮤테이션 → 구조 인식 뮤테이터가 헤더, 텐서 메타데이터, 정렬 패딩 등을 인식하여 유효한 변형 생성

3️⃣ 실행 및 모니터링 → LibFuzzer 기반 커버리지 피드백 수집 + ASan을 통한 메모리 오류 실시간 감지

4️⃣ 크래시 수집 → 스택 트레이스 기반 자동 분류(디듀플리케이션), 고유 크래시만 저장

5️⃣ 검증 → 격리된 Docker 컨테이너에서 3회 반복 재현 수행, 안정 재현 크래시만 유효 취약점으로 확정

2-5. 기술 스택 선정 결과

1주차 조사를 바탕으로 다음과 같이 기술 스택을 선정하였다.

분류	기술	선정 사유
코어 언어	Rust	메모리 안전성 보장으로 플랫폼 자체의 안정성 확보, 고성능 비동기 처리(tokio)로 다수의 퍼징 Job 효율적 스케줄링
하네스 언어	C/C++	llama.cpp, onnxruntime 등 타깃 바이너리가 C/C++로 작성되어 네이티브 호출 필수, LibFuzzer와 직접 연동 용이
퍼징 엔진	LibFuzzer	LLVM 기반 커버리지 유도 퍼저, 인프로세스 실행으로 속도가 빠르고 ASan과 통합이 매끄러움
메모리 탐지	ASan	컴파일 타임 계측으로 힙/스택 오버플로우, UAF 등 메모리 커럽션 정밀 탐지
스크립팅	Python	리포트 생성, 크래시 로그 파싱, 시드 관리 등 보조 스크립트 작성
컨테이너	Docker	격리 환경에서 크래시 재현의 일관성 보장, 호스트 시스템 보호 및 이식성 확보
형상 관리	Git / GitHub	팀 협업, 코드 리뷰, 이슈 트래킹 및 CI/CD 파이프라인 기반
빌드 도구	Cargo / CMake	Rust는 Cargo, C/C++ 하네스는 CMake로 관리, FFI 연동 시 build.rs로 통합 빌드

️ 3. 수행 활동

3-1. 개인 학습 및 조사 활동

퍼징 관련 자료 학습: 구글 OSS-Fuzz 프로젝트 문서, LLVM LibFuzzer 공식 문서, 「The Fuzzing Book」 온라인 교재를 통해 퍼징의 이론적 기반을 학습
AI 모델 파일 포맷 분석: GGUF 포맷 명세(llama.cpp 공식 문서)와 ONNX 공식 스펙을 읽고, 각 포맷의 헤더 구조, 텐서 배치 방식, 메타데이터 영역을 파악
기존 퍼징 사례 조사: llama.cpp에 대한 기존 퍼징 하네스(fuzzer 디렉토리)를 분석하여 하네스 구조와 퍼징 진입점 설계 방식을 파악
Rust-C FFI 연동 방식 조사: bindgen 크레이트를 활용한 C 헤더 자동 바인딩 생성 방법과, Rust에서 unsafe 블록을 통해 C 함수를 호출하는 패턴을 학습

3-2. 팀 활동

킥오프 미팅 참석 (04.02): 프로젝트 목표, 일정, 역할 분담을 확정하고 팀 규칙(코드 컨벤션, 커밋 메시지 규칙 등)을 수립
온라인 정기 미팅 참석 (04.05, Discord): 각자 1주차 조사 내용을 공유하고, 기술 스택 선정에 대한 논의를 진행
협업 환경 구축: GitHub 레포지토리 생성, Notion 프로젝트 페이지 구성, Discord 채널 설정 완료
개발 환경 통일: 팀원 전원 Ubuntu 24.04 LTS, Rust 1.77+, Clang 17+ 기반으로 통일 합의

4. 다음 주 계획 (2주차)

시스템 아키텍처 설계서 작성 (전체 모듈 구조도, 데이터 흐름도)
GGUF 포맷 대상 최초 퍼징 하네스 프로토타입 작성 (C/C++)
LibFuzzer 기반 퍼징 실행 환경 구축 및 시드 코퍼스 수집
Rust 프로젝트 스캐폴딩 및 Cargo workspace 구성
FFI 연동 테스트 (Rust에서 C 하네스 호출 검증)

5. 느낀점 및 회고

프로젝트 1주차에는 퍼징의 기본 개념부터 AI 모델 파일 포맷의 구조, 그리고 실제 개발에 사용할 기술 스택까지 폭넓게 조사를 진행하였다. 퍼징이라는 기법 자체는 이전에 개념적으로만 알고 있었으나, 실제로 LibFuzzer의 동작 방식과 하네스 구조를 상세히 살펴보니 단순히 랜덤 데이터를 넣는 것이 아니라 커버리지 피드백 기반의 정교한 메커니즘이라는 점을 새롭게 이해하게 되었다.

특히 AI 모델 파일을 퍼징 대상으로 삼는다는 점이 흥미로웠다. GGUF나 ONNX 파일의 구조를 분석하면서, 복잡한 바이너리 포맷의 파서가 얼마나 많은 잠재적 취약점을 가질 수 있는지 실감하게 되었다. 단순 바이트 뮤테이션으로는 파서의 깊은 로직에 도달하기 어렵다는 점에서 구조 인식 뮤테이터의 필요성을 체감하였다.

Rust와 C/C++를 함께 사용하는 기술 스택 구성이 다소 복잡할 수 있지만, 플랫폼의 안정성(Rust)과 타깃 호환성(C/C++)을 모두 확보할 수 있다는 점에서 합리적인 선택이라고 판단하였다. 다음 주부터 본격적인 하네스 개발에 착수할 예정이며, 실제 코드를 작성하면서 이론과 실무 사이의 간극을 좁혀 나가고자 한다.