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

저번주에 언급했던 부분 중 취약점 개수를 줄이는 방향으로 가는 것이 좋을 것 같다는 의견을 주셔서 1개로 줄여보았다.

 

[선정된 취약점]

1. Missing Protocol Vulnerability
   • 취약점 정의
     • 핵심 원인 : DXE 드라이버의 DEPEX가 요구하는 특정 프로토콜의 GUID를 제공(Install)하는 드라이버가 펌웨어 내에 존재하지 않는 상태.
     • 상태 정의 : 해당 드라이버는 실행 준비 단계인 Scheduled로 전이되지 못하고, 무한히 Dependent(대기) 상태에 머물게 됨.
   • 일반 결함(Bug)과의 차별점
     • 일반 드라이버 : 주변 장치(마우스, 오디오 등) 작동 불능 → 가용성 저하(기능적 결함).
     • 보안 드라이버 : 인증 및 검증 로직 생략 → 기밀성 및 무결성 파괴(보안 취약점).
   • 취약점 성립 근거 (보안 드라이버 중심)
     • 보안 체인(Chain of Trust) 단절 : Secure Boot, TPM 초기화, 암호화 엔진 등 보안 필수 드라이버가 로드되지 않음으로써 전체 시스템 보호막이 형성되지 않음.
     • Fail-Open 구조 : 시스템이 보안 검사 실패 시 부팅을 중단(Fail-Safe)하는 것이 아니라, 검사 드라이버 자체의 누락을 무시하고 부팅을 강행(Fail-Open)하기 때문에 취약점이 됨.
     • 권한 상승(Privilege Escalation) : 보안 드라이버가 부재한 틈을 타 공격자가 커널 권한으로 악성 코드를 실행하거나 보안 설정을 임의로 조작할 수 있음.
   • 예시
     • 상황 : SecureBootVerify라는 드라이버가 실행되려면 HashProtocol 필요.
     • 문제 : 펌웨어 내에 HashProtocol을 설치해주는 드라이버 누락.
     • 결과 : SecureBootVerify는 영원히 실행되지 않고 대기(Dependent) 상태가 됨. DXE Dispatcher는 이 드라이버를 건너뛰고 다음 부팅 단계로 넘어가 버릴 수 있으며, 결국 서명되지 않은 악성 코드가 실행될 수 있는 환경이 조성됨.
2. Cycle Vulnerability
   • 취약점 정의
     • 핵심 원인 : 두 개 이상의 DXE 드라이버가 DEPEX(의존성 식별자)를 통해 서로를 참조하거나(A→B, B→A), 복잡한 경로를 거쳐 자기 자신에게 돌아오는 순환 구조를 형성하는 상태.
     • 상태 정의 : DXE Dispatcher가 의존성 그래프를 해석할 때 Deadlock에 빠져, 관련 드라이버들이 결코 Scheduled 상태로 전이되지 못함.

- Cycle 취약점의 경우 Deadlock이 발생하는 것이 아니라, Cycle을 생성하는 드라이버가 실행되지 않는 문제로, 결국 1번 Missing Protocol 취약점으로 귀결되기 때문에 삭제

 

[선정되지 않은 취약점]

1. bypass, dead, alwaystrue, alwaysfalse Vulnerability
   • 이 경우 단순한 정적 분석 수준으로, UEFITool 등을 사용하게 되면 쉽게 눈으로도 직접 찾아낼 수 있기 때문에 이번 우선순위에서는 밀리게 됨.
2. Before/After Vulnerability
   • Missing Protocol의 탐지 로직과 유사하여, 이를 구현하면서 부가적으로 처리될 수 있는 취약점이라고 생각함.
3. Malicious Vulnerability
   • 현재 수준은 단순한 '블랙리스트 매칭'이므로, 선정된 취약점을 처리하고 난 다음 단계에서 직접 드라이버를 분석하여 악성 드라이버인지 확인하는 로직을 추가하여 탐지할 예정.

 

[현재 진행 상태]

1. Missing Protocol 취약점을 탐지하기 위해 기존에 작성되어 있던 사용하지 않을 취약점 탐지 로직을 전부 삭제하고 두 취약점에 대한 로직은 기존대로 진행하려 하였으나, 기존 로직이 휴리스틱하게 탐지하는 것이 맘에 들지 않아 전부 수정에 들어감.
2. Missing protocol의 경우, 각 드라이버가 생성하는 Protocol을 pcode 분석을 통해 알아내고, 그 설치되는 Protocol목록과 DEPEX에 적혀 있는 Protocol을 매칭하며, 리스트에 없는 Protocol이 없을 경우 탐지하는 로직을 생성중.

 

 

현재 edk2를 빌드할 때 생성된 OVMF.fd 파일에서 HiiDatabaseDxe 드라이버를 삭제하고 스크립트를 돌려보았을 때, 위와 같이 HiiDatabaseDxe 드라이버가 생성하는 EfiHiiDatabaseProtocol, EfiHiiStringProtocol, EfiHiiConfigRoutingProtocol, EfiHiiImageExProtocol이 존재하지 않다고 잘 잡아냈고, 보안 관련 드라이버가 필요한 Protocol이 없을 경우 취약점이 아니라 버그로 잡기로 로직을 생성해놔서 위와 같은 결과물이 나와있다. 

 

맨 위의 EfiFirmwareVolumeBlock2Protocol은 FvbServicesRuntimeDxe 드라이버가 생성하는 프로토콜인 것 같은데, 잘못 탐지 된 것 같다. 왜 탐지 되었는지 좀 더 알아봐야 할 것 같다.

 

완성된 스크립트가 아니고, 로직 수정도 더 필요해서 코드 공유는 안할 예정이다.

 

다음주에도 로직 보강에 힘을 써볼 예정이다.