UEFI 스터디 6차 - 합의된 프로젝트 방향성, LOGOFAIL 취약점.

3 minute read

Published:

방향성 설정(팀원과 합의됨)

먼저, 팀 원과 별도 회의를 통해 할당받은 역할 -> 메모리 위주 취약점을 발견하는 스크립트 작성

  1. 너무 범위가 넓은 것 같은데?
    메모리라는 분류가 너무 추상적이어서 이전 조원들의 취약점 조사내용을 살펴봄
    -> 가장 많은 메모리 관련 취약점 유형은 오버플로우를 이용한 타 메모리 침법.
    -> 버퍼,힙 오버플로우를 이용해 메모리를 오염시키는 종류의 취약점 중심.

  2. 서웅조원의 SMM 관련 취약점과 너무 겹치는 내용이 많지 않을까?
    SMM 관련도 주로 SMRAM의 메모리 공간을 노린 취약점이 많았다.
    ->따라서 겹치지 않도록 SMM 쪽 외의 RING 0 권한 탈취를 노린 취약점들 위주 조사. ->SMI 핸들러등 SMM 전환에 대한 이해없이 순수 메모리 이슈에 집중.

RING -2 권한 탈취가 아닌 RING 0 권한 탈취도 충분히 위험하다.
ex)RING 0 권한 탈취해서 -> NVRAM 변수 바꾸기, 시큐어부트를 우회해서 런타임에도 살아남은 취약 드라이버…

현재 사용하려는 취약점 : LOGOFAIL.

참고한 사이트 : binarly의 research/logofail 탭의 많은 영상, 게시글들

기존은 RING 0 권한을 탈취하는 TOCTOU 취약점의 CVE를 찾으려 하였으나, 계속 언급되고 자료가 많은 취약점으로 해당 취약점으로 방향성을 바꿨다.

유형 : 할당받은 버퍼를 초과한 쓰기 (Out Of Boundary, OOB)

요약 : 해당 분류의 취약점은 이용해서 공격자들이 이상한 로고 이미지를 EFI 시스템 파티션이나 펌웨어 업데이트의 서명되지 않은 섹션에 집어넣을 수 있게 함.
부팅시에 해당 이미지가 파서에 의해 파싱 -> 각종 문제 발생

예시 CVE :  CVE-2023-40238   독립 UEFI 벤더인 insyde의 UEFI에서 발생한 이슈.
이미지 크기와 관련된 변수 imagewidth, imageheight를 인수로 이미지 파싱시 쓰일 버퍼를 할당한다는 점을 악용
-> 해당 값을 조정해서 zerosized buffer 할당. 로고 gif file 처리 중 부차적인 펌웨어 쓰기를 함.
또 이 CVE는 내부에서 사용된 AllocatePool 함수 EDK2 참조구현의 책임도 일부 존재.
“왜 곧이 곧대로 Zerosized buffer를 할당해줘?”

1

AllocatePool을 쓴 이미지 해당 함수의 힙 메모리 할당 루틴.
0사이즈의 버퍼를 받아도, null이 아니니 그대로 PASS.

발생 가능한 이슈 :

  • DXE 드라이버 임의 코드 실행으로 인한 ring 3 -> ring 0의 elevation
  • OS부팅 , 런타임까지 살아남는 해악한 코드의 설치 (심지어 NVRAM과 SPI 스토리지를 수정해버린다면, 얘는 영속함)
  • OS 시큐리티 메커니즘 오염 (권한 뒤틀어버림)

어째서 LOGOFAIL?

1.방대한 자료와 테스트 데이터.

모든 UEFI 벤더들은 부팅시에 벤더 로고를 띄운다. 이를 위한 여러 이미지 파서를 각자의 방식으로 구현하였기에, 어떤 상용 UEFI의 이미지 파서를 잡기만 하면 테스트 데이터가 확보된다.
binarly에서 해당 취약점에 대한 게시글과 영상에서 지속적으로 언급되는 표현이

단일한 취약점이 아님
-> jpeg, gif, png, 여러가지 파서가 있으므로, 여러 침범 경로

수많은 벤더와 OEM
-> UEFI 벤더마다 파서의 구현이 다양하고, OEM에서 벤더의 조치를 무시하고 그대로 취약점이 있는 UEFI를 배포하는 경우가 매우 많음.

이렇게 규모가 큰 이슈다 보니 취약점 찾으러 주로 방문하던 사이트 에서 아예 해당 취약점 관련 섹션이 있었다. 이 덕에 취약점 파악과 이해에 매우 도움이 되었다.

2.완전히 겹치는 방향성
잘못된 버퍼 사이즈를 입력해 할당 받은 버퍼 사이즈보다 더 큰 데이터를 write 해서 메모리를 오염시키는 전형적인 메모리 문제이다

3.적절한 시기
2023년에 보고, 이후로 주목 받기 시작함. 우리가 사용할 EDK2버전에도 적용가능하다.


지금 하고 있는 것

  • 해당 취약점에 속하는 CVE들을 이해 중… -> 공통으로 탐지 가능한 부분이 있는지 파악(원인이 되는 함수가 EDK2에 구현된 ~~다, 특정 조건을 빼먹었다..)
  • 잘 알려진 CVE의 드라이버를 구해서 기드라에 넣어서 문제가 있는 부분의 p코드 수준의 문제 부분 찾아보기 (현재 기드라와 열심히 씨름 중)

이외에 할 것

  • fuzzing이란?
  • 기드라 공부
  • Q.그냥 메모리 접근할때마다 유효한 버퍼 공간인지 확인하면 되는 거 아냐?
  • 도움될 만한 자료 찾아보기