[프로젝트]UEFI DXE 바이너리 취약점 분석기 3주차 - 방향성 탐구

[프로젝트 방향 탐구]

처음에 프로젝트를 시작할 때의 연구 주제는

"UEFI DXE 단계의 펌웨어를 넣으면, 자동으로 취약점을 찾아내는 '자동화 분석 도구(Framework)'를 개발하겠다."

였는데, 이를 위한 연구 전략은 아래와 같이 계획하였다.

1. 1단계 : PE/COFF 헤더를 뜯어서 섹션 정보와 메모리 주소를 파싱하고 "어디가 코드고 어디가 데이터인지"를 정의한 JSON 형태의 메모리 지도 만듦
2. 2단계 : 어렵고 복잡한 기계어(Assembly)를 분석하기 쉬운 중간 언어(P-code)로 변환 (Ghidra 툴 활용).
3. 3단계 : 번역된 코드를 보고 하이브리드 분석으로 취약점 잡기.

 

이와 관련되어 내가 흥미를 가지는 분야인 DXE Dispatcher/DEPEX 부분을 적용시키자면

• 파서(Parser) 구현:
  • PE/COFF 헤더를 파싱하여 분석 대상(DXE Driver) 식별.
  • 드라이버 내 EFI_SECTION_DXE_DEPEX 섹션을 추출하고, RPN(역폴란드 표기법)을 디코딩하는 엔진 구현.
• 탐지 알고리즘 (Detection Logic):
  • Graph Analysis: 드라이버 간의 의존성을 그래프(NetworkX 등 활용)로 모델링하여 순환 의존성(Circular Dependency) 및 데드락 구간 자동 탐지.
  • Stack Simulation: DEPEX 연산 과정을 시뮬레이션하여 스택 오버플로우/언더플로우를 유발하는 기형적인 수식 탐지.
  • Security Rule Check: SOR(Schedule On Request) 플래그나 BEFORE/AFTER 지시어가 보안 정책을 우회하는 패턴으로 사용되었는지 검사

이 정도가 되지 않을까 생각이 든다.

 

 

이 주제 외에 나온 의견이 '취약점을 찾는 것'이었는데,

DXE Dispatcher/DEPEX의 경우에 드라이버의 실행 순서를 결정해서 순차대로 실행시키는 것이므로 이 로직만 생각해도 취약점이 매우 많을 것으로 예상된다. 현재 DXE Dispatcher 관련하여 발견된 취약점이 많고, 이를 토대로 취약점을 찾는 시나리오를 생각해보자면

1. TOCTOU 검증: 드라이버 로드(Check)와 실행(Use) 사이의 시점에 인터럽트나 DMA를 통해 이미지를 변조할 수 있는지 시뮬레이션.
2. DoS 공격: 무한 대기 상태(Infinite Wait)를 유발하는 악의적인 DEPEX를 가진 드라이버를 제작하여, 실제 부팅 프로세스를 멈추게(Hang) 할 수 있는지 실험.
3. A Priori File 목록을 조작하거나 기형적인 DEPEX를 주입했을 때, Dispatcher가 예외 처리를 못 하고 뻗어버리거나(Crash) 서명 검증을 건너뛰는지 확인.

등이 있다.