
# IA32 plugin, ver. 2020.013.20074.
char * __cdecl FUN_2581894c(char *base_url,LPCSTR rel_url)
{
............................................................
............................................................
if ((base_url != (char *)0x0) && (rel_url != (LPCSTR)0x0)) {
if ((*base_url == -2) && (base_url[1] == -1)) {
iVar6 = bytes_len(base_url);
pcVar7 = base_url + iVar6;
pcVar8 = rel_url + 2;
do {
do {
cVar3 = *pcVar8;
pcVar1 = pcVar8 + 2;
*pcVar7 = cVar3;
pcVar2 = pcVar7 + 2;
cVar4 = pcVar8[1];
pcVar7[1] = cVar4;
pcVar7 = pcVar2;
pcVar8 = pcVar1;
} while (cVar3 != '\0');
} while (cVar4 != '\0');
}
else {
lstrcatA(base_url,rel_url);
}
return base_url;
}
.............................................................
.............................................................
}
PDF 문서의 baseURL에 상대적인 URL을 app.launchURL, document.submitForm 또는 app.media.createPlayer 같은 API에서 사용할 절대 URL로 만들 때,
baseURL이 UTF-16BE 문자열처럼 보이면, 상대 URL도 실제로는 ANSI 문자열임에도 불구하고 연결 시 UTF-16BE 문자열로 처리됩니다.
이로 인해 한편으로는 범위를 벗어난 읽기(Out-of-bounds read) 접근이 발생할 수 있습니다. 다른 한편으로는 대상 버퍼를 할당할 때 상대 URL이 ANSI 문자열로 "측정"됩니다. 물론 OOB 읽기가 발생하면 이는 충분하지 않습니다. (문자열 + 힙 청크 전체를 채우는 NULL 종결자).
이것이 의미하는 바는?
대부분 크래시가 발생하며, 드물게 ArrayBuffer의 byteLength가 0xFF로 덮어쓰여집니다.
질문이 있으시면 트위터로 연락주세요: https://twitter.com/Zeusb0x
PDF 문서 카탈로그에는 사전 객체에 대한 간접 참조를 보유하는 URI 항목이 있습니다. 이 항목에는 실제 baseURL인 Base 항목이 있습니다. 대부분 16진수 표기법으로 표시되며 \xFE\xFF 문자로 시작합니다. (PoC 참조). 운 좋게도 일반적인 비권한 컨텍스트에서 문서의 baseURL을 변경할 수 있는 유일한 방법입니다. JavaScript에서 시도하면 보안 예외가 발생합니다.