[프로젝트]UEFI DXE 바이너리 취약점 분석기 10주차 - Ghidra Script 수정

지난주에 Missing Protocol만 가지고 취약점 탐지를 하기로 정했다.

기존에 진행하던 방식인 "기드라 Pcode 분석을 통한" 프로토콜 설치 탐지를 진행했었는데, 정보과학회 논문 작성까지 오탐률 적은 스크립트가 나올 것 같지 않아 급하게 방향을 틀게 되었다.

 

주말동안 팀원분들께 미리 말씀은 드려 놓았지만, 교수님의 의견이 중요할 것 같아서 상의가 필요하다고 생각했다.

 

[현재 상황 및 교수님, 팀원분들과 상의하고 싶은 것]

1. 현재 DXE 드라이버가 설치하는 Protocol 탐지가 제대로 되지 않는 상황
   • UEFI 특유의 간접 호출 (ex. gBS->InstallProtocolInterface(...))
   • GUID 추적이 데이터플로우인 문제 (프로토콜을 찾으려면 InstallProtocolInterface(&Handle, &GUID, ...) 이런걸 해야 하는데 실제로는 GUID가 전역에 있고, 중간에 레지스터를 여러번 거치는 등)
   • Protocol Install 자체가 Runtime event이므로 정적 분석만으로는 100% 탐지가 어려움
     • Protocol Install은 “코드 구조”가 아니라 “실행 시점의 상태 변화(Runtime behavior)”이기 때문에, 바이너리만 보고는 확정할 수 없는 경우가 많다.
     • UEFI에서 프로토콜 설치는 보통:
       gBS->InstallProtocolInterface(...)
       gBS->InstallMultipleProtocolInterfaces(...)
       를 통해 이루어짐. 이 호출 자체는 단순 API 호출일 뿐. 실제 의미는 'Handle Database 상태 변경'. 즉,
       Handle X
        └── Protocol GUID 추가됨 (runtime에)
       이건 전역 런타임 객체 변화
       
       정적 분석은 코드 구조만 볼 뿐 실행 후 Handle DB 상태는 못 본다.
   • 등등의 여러 이유 때문에 어렵다고 합니다.
2. 그래서 논문에서는 지난번에 했던 것처럼 휴리스틱하게 하더라도, EDK2를 타겟으로 잡고 EDK2에 들어있는 모든 DXE 드라이버가 설치하는 프로토콜을 수기로 정리해서 집어 넣는 방식으로 해서 오탐을 줄이는 것에 대해 어떻게 생각하는지 물어보고 싶습니다.
3. 일광이가 현재 제 스크립트 때문에 헤드리스 스크립트를 갈아 엎은 상태인데, 지금 하던 일이 의미가 없어지는 것이 아니냐 -> 아닙니다. 어차피 확장해야 하고, EDK2 뿐만 아니라 좀 더 general 하게 하려면 이번학기 안에 시도 했어야 할 문제이기 때문에, 의미가 없어지는 것은 아닙니다. 하지만 서두르게 한 점 죄송합니다.
4. general 하게 하고싶지만 이건 제가 좀 더 깊게 공부를 해야 하는 상황인 것 같고 현재 논문 마감이 약 3주가량 남았기 때문에 3월 안에는 모든 스크립트에 대한 결과가 나와야 한다고 생각해서 내린 결정입니다. 또한 박사님께서 'general은 좀 위험한 발언인 것 같다' 라고 하셔서 EDK2를 타겟으로 하는 게 어떠신지 묻고싶습니다.

그렇다면 현재 저의 스크립트의 방향성에 대한 두가지 방법이 존재하는데,

1. 스크립트 갈아 엎기 전에 사용했던 방식을 EDK2의 모든 드라이버에 대해 적용(휴리스틱)
2. 현재 로직을 EDK2로 한정해서 사용

-> 2번의 방법으로 논문 쓰기 전에 완성할 수 있을지는 미지수임

-> 그래서 일단 1번 스크립트를 완성시키고 2번을 빠르게 진행해보면서, 3월 안(혹은 4월 첫째주까지)에 완성이 되면 논문으로 작성하는 방식으로 진행해야 할 것 같음.

 

현재 1번 스크립트는 완성 되어 있는 상황.

 

[로직]

0. edk2 github에서 소스코드 다운 & UEFIExtract 툴로 덤프 폴더 추출

1. 파이썬 스크립트(generate_protocol_switch.py) 맨 아래 부분에 위 두 폴더 경로 설정 후 실행 -> JAVA switch-case문 생성

2. 생성된 switch-case문을 가지고 자바 스크립트(DepexHunter_v3_0_0)에 넣기

3. Headless.py 스크립트로 실행

generate_protocol_switch.py

0.01MB

DepexHunter_v3_0_0.java

0.04MB

Headless.py

0.07MB

 

 

Python 파서(generate_protocol_switch.py)

• SOMETIME_PRODUCES (오타 포함), SOMETIMES_PRODUCES, PRODUCED 계열 전부 provider로 인정
• # 단일 주석 스타일도 파싱 (# PROTOCOL ALWAYS_PRODUCED)
• Guid 접미사 제거로 GUID DB 이름과 매칭
• dump 폴더 교차검증으로 여러 후보 중 실제 펌웨어에 있는 드라이버 우선 선택
• MODULE_TYPE 필터로 라이브러리 .inf 제외

.inf 파일의 [Protocols] 섹션 파싱
↓
PRODUCES tag만 선택
↓
실제 firmware dump driver와 교차검증
↓
provider 결정

heuristic보단 'knowledge-assisted dependency inference'라고 사용하는 것이 어떨지...

 

 

Java 스크립트(DepexHunter_v3_0_0.java)

• allDiscoveredSmmDrivers 분리로 SMM 드라이버(Subtype: SMM module) 별도 수집
• inferAllProviders()에서 DXE + SMM 둘 다 교차검증
• knownProtocolProvider()에 Guid 없는 버전과 있는 버전 둘 다 등록
• systemProtocols 이름을 GUID DB 형식에 맞게 수정
• findDriverNameFromParents()에 Subtype: SMM module 추가
• Vulnerability와 Bug 구분 (보안 드라이버 vs 일반 드라이버)
• Headless 환경 맞춤으로 수정

Headless 스크립트 (Headless.py)

• depex 스크립트 실행 시 필요한 cmd 인자 변경
• normalize_depex_report_records함수에 취약점/버그 구분 로직 추가
• DepexHunter 스크립트 3_0_0으로 버전 수정