처음의 방향성

로고페일 관련한 보고서중 해당 보고서의 내용이 탐지해볼만 할것같아서 해당 드라이버의 취약점 부분을 탐지 가능한 기드라 스크립트를 작성하고자 하였다.

일단 해당 드라이버의 취약점을 잡고 -> 추가적이 보고서의 내용을 잡고… 이렇게 개선해나갈 예정이었다.

실제 드라이버에서는 어떤 어려움이 있었나?

1. 너무 커다란 구조, 관련없는 부분들과 복잡하게 얽힌 호출관계로 메인로직 찾기조차 힘듬

기드라 리스팅에는 따로 high pcode로 출력하는 기능이 없고, 스크립트를 만들어 따로 출력해도 파악이 힘드니, 기드라 자체의 그래프로 그려주는 기능을 애용하고있다. 근데 이 문제가 있는 함수를 직접 해보면..
이렇게 된다. (저 작은 붉은점 하나하나가 바노드와 opcode들이다..) 그래서 실제 문제와 관련된 p코드를 파악하는데되 굉장히 긴시간이 걸렸다.

2. 메인 로직을 잡아도 문제가 해결되지 않을 수 있음.

문제1번이다.

저기 보이는 구조체(혹은 배열인) local_560이 오염된 변수로서, 인수로 부터 nvram의 가로 세로 정보를 받았다.
Q.해당 변수는 위에서 명시적으로 초기화 되었을까?
=> X. 위를 살펴보면 선언된뒤 그대로 사용되었다.

Q. 그러면 어디서 초기화 되었을까?
사진에 보이는 함수의 인자는 차례대로 1번째 인수, 2번째 인수, local560이다. 포인터가 넘어가므로, 해당함수내에서 local 560이 오염될 수 있다! 하지만 함수간의 장벽으로 우리는 스크립트로 이를 파악하기 매우어렵다.

실제로 함수를 두번정도 더 타고들어가면 오염되는 부분을 찾아 볼 수 있다.
해당함수를 클로드는 copymem으로 추정했고, 1번은 dest = local560, 2번은 src = 파라미터1번 으로 확실히 오염이 된다.

문제2번이다.

지역 변수 선언부를 보자. local8?? 쪽이 심하게 파편화 되어있다.
RBP로 부터 매우 먼곳이므로 높은 확률로 이미지 관련 구조체 일것이고,
타입마저도 undefined에 뭐시기에 난리가났다. 타입을 모르는 만큼 탐지에 너무 큰 힘이 들었고, 그마저도 여러 타협을 하며 제너럴과는 갈수록 멀어졌다.

문제 3번이다.

취약점과 관련없는 함수들이 너무 많았다.
함수간 오염분석을 넣어야 하는데, 기존에 함수들 호출관계가 복잡해서, 디버깅이 너무 어려웠다.

그러면 실제 드라이버를 활용하는 것은 아예 쓸모 없는가?

그렇진 않았다. 실제 탐지 스크립트를 완성한다면, 실행해보며, 예상 못한 케이스 지만, 나의 탐지로직과 관련한 허점을 여럿 찾을 수 있었다.

여기보면 uVar9에 위험한 연산이 저장되었다.
uVar5와 uVar6는 크기검사가 되었을까?
단순히 if문으로 변수의 검사 여부만 살핀다면 검사되지 않았다.
하지만 if 문을 자세히 살펴보면 uVar5,6에 담긴 값을 그대로 비교해서 살피는 모습이다.
=> 검사가 된 오탐이다.
—