아이폰 CFF 버그 학습 기록

CFF 폰트를 파고들다가 우연히 어떤 jailbreak에서 cff 파싱의 버퍼 오버플로우에 대해 알게 되었다. 그냥 재미로.

그래서... CFF가 뭔데? 내가 아는 한 파일 형식이지만, 위키피디아가 뭐라고 하는지 한번 보자: "CFF는 FontSet이라는 단일 단위로 여러 글꼴을 함께 저장하는 컨테이너 역할을 한다." (https://docs.fileformat.com/font/cff/) 즉 기본적으로 글꼴을 함께 저장할 수 있다. 좋아, 그럼 이제 뭐? 음, 파일 형식이니 스펙이 있어야 하고, 실제로 있긴 한데 좋지는 않다. 왜냐하면 60페이지나 되고 나는 그 형식을 배우고 싶지 않기 때문이다. 하지만 star-master github 저장소(아마 jailbreak 2.0의 소스 코드라고 생각한다)의 익스플로잇을 사용해서 그 형식에 대해 배울 수 있다.

그래서... 저자가 제공한 cff.py 스크립트를 사용하고 hxd 편집기에서 out.cff(표준 간단한 .cff 파일) 파일을 연다.

파일을 파서에 넣으면 다음과 같은 결과를 얻는다.

그래서 우리는 이미 어느 정도 진전을 이뤘다. CFF에 대한 정의를 내릴 수 있게 되었는데, 헤더에 대한 메타데이터가 있다는 결론을 내릴 수 있다. 내 추측으로는 tff 버전, headersize, 그리고 absoffsize(그게 무엇이든 간에)를 나타낸다.

지금까지는 |메이저 버전(1바이트)|마이너 버전(1바이트)|헤더 크기(1바이트) | 헤더 absoffsize(1바이트) |

그런 다음 더 나아가 이 .cff 파일에서 어떤 글꼴이 사용되는지 얻는 함수가 있다. 보이는 바와 같이

그럼 어디서 그 함수의 목적이 사용되는 글꼴을 읽는 것임을 알 수 있을까? 음, 도구를 실행했을 때 cmd에서 다음과 같은 결과를 얻었다.

이는 파일의 메타데이터 다음에 오는 바이트들임을 알 수 있다.

이 함수의 분석은 나중에 다시 하겠지만, 지금은 파일 형식이 다음과 같다고 추론할 수 있다. |메이저 버전(1바이트)|마이너 버전(1바이트)|헤더 크기(1바이트) | 헤더 absoffsize(1바이트) | ABCDEF+fonts in pack|

또한 스크립트에서 string이라고 불리는 것을 검색한다:

왜 그럴까? 내 생각에는 팩에 사용된 글꼴에 대한 정보를 모으기 위해서인 것 같다. 문서에 따르면: "Name INDEX에 나타나는 FontName 및 CIDFontName 문자열을 제외하고 FontSet 내의 서로 다른 글꼴이 사용하는 모든 문자열은 INDEX 구조로 함께 수집되며 문자열 식별자(string identifier) 또는 SID라고 하는 2바이트 부호 없는 숫자로 참조됩니다. 표준 문자열(standard strings)로 알려진 이러한 문자열은 ISOAdobe 및 Expert 문자 집합에서 사용되는 모든 이름을 설명합니다." 어쨌든 여기서 흥미로운 점은 문자열에 도달하기 위해 약 41바이트를 건너뛰었다는 것이다.

다음으로 .cff 파일에 있는 글꼴에 대한 정보를 얻는다.

도대체 어떻게 하냐? 음, top dict 데이터라고 불리는 것을 수집한다. 그게 뭔데? 음, 내가 문서에서 이해한 바로는 특정 정보가 들어 있는 파이썬 dict로, 특정 방식으로 인코딩되어 있다.

우연히도, 디코딩 알고리즘을 따라가 보면:

strings 데이터 타입을 역참조하여 글꼴에 대한 정보를 얻는다. 따라서 topdicts에는 단지 몇 가지 인덱스만 있고, 나중에 이 인덱스가 strings 데이터 타입에서 글꼴 정보를 얻는 데 사용된다는 결론을 내릴 수 있다.

그래서 지금까지 파일 정의는 여전히 유효하다. |메이저 버전(1바이트)|마이너 버전(1바이트)|헤더 크기(1바이트) | 헤더 absoffsize(1바이트) | ABCDEF+fonts in pack|알려진 41바이트|글꼴에 대한 25바이트 정보|

좋아, 그럼 다음은 뭐가 일어날까? 음, 파서 스크립트를 살펴보면 charstring_off,private_off를 가져와서 charstring_off 위치로 이동해 추가 데이터를 읽는 것을 볼 수 있다.

하지만 더 큰 그림을 이해하는 데 어떻게 도움이 될까? 그래서 이 부분은 갑자기 결론을 내리겠다. 기본적으로 나는 정상 cff 파일과 변조된 cff 파일, 두 파일 간의 diff를 수행했다.

왼쪽은 변조된 .cff 파일이고 오른쪽은 정상 .cff 파일이다. 런타임 결과를 살펴보면

파서를 처음 실행하면 count, offsize, offbase 같은 모든 것이 단순히 어떤 구분자까지의 오프셋임을 알 수 있다. 무슨 구분자? 정확히는 글꼴 이름이다. 보다시피 ('offbase', 8L)이 있는데, 파일 시작부터 cff 파일에 있는 글꼴의 문자열을 처음 만날 때까지의 오프셋이다.

이는 "두 번째 parse 실행"에서도 볼 수 있다.

hex 뷰어의 0x6c 오프셋에서 \x0e\0xe\0xe\x0e, 즉 우리의 악성 데이터의 시작 부분을 볼 수 있다.

그래서 결론적으로 .cff 파일 형식의 일반적인 형식은

|메이저 버전(1바이트)|마이너 버전(1바이트)|헤더 크기(1바이트) | 헤더 absoffsize(1바이트) | ABCDEF+fonts in pack|알려진 41바이트|글꼴에 대한 25바이트 정보|

그리고 사용자 콘텐츠가 있는 사용자 정의 파일 형식 |메이저 버전(1바이트)|마이너 버전(1바이트)|헤더 크기(1바이트) | 헤더 absoffsize(1바이트) | ABCDEF+fonts in pack|알 수 없는 41바이트|글꼴에 대한 25바이트 정보| 4바이트(count) | 4바이트(offsize) | 문서화할 9바이트 남음| 사용자 콘텐츠|