
ヒープオーバーフローにつながるAdobe Readerの型混乱の概念実証エクスプロイト。詳細な根本原因分析と検出ガイダンスが含まれます。
# 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もUTF-16BE文字列として扱われますが、実際にはANSI文字列です。
これは、一方では範囲外読み出し(Out-of-bounds read)を引き起こす可能性があります。もう一方では、宛先バッファを確保するためにメモリを割り当てる際、相対URLはANSI文字列として「測定」されます。もちろん、範囲外読み出しが発生した場合にはこれでは不十分です。(文字列とNULL終端文字がヒープチャンク全体を埋めている状態)。
これは何を意味するのでしょうか?
ほとんどの場合クラッシュを引き起こし、まれにArrayBufferのbyteLengthを0xFFに上書きします。
質問があれば、Twitterでお気軽にご連絡ください: https://twitter.com/Zeusb0x
PDF文書カタログには、辞書オブジェクトへの間接参照を保持するURIエントリがあります。この辞書にはBaseエントリがあり、これが実際のbaseURLです。これはほとんどの場合、16進表記で存在し、\xFE\xFFという文字で始まります。(PoCを参照)。幸いなことに、通常の非特権コンテキストで文書のbaseURLを変更する唯一の方法はこれです。JavaScriptから変更しようとすると、セキュリティ例外がスローされます。