House of Roman

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。

基本情報

これは fake fastbins、the unsorted_bin attack、および relative overwrites を介して leaks なしで RCE を可能にした非常に興味深い手法でした。しかしそれは patched。

2026年における適用性

glibc window: 2.23–2.27 で安定して動作します（the how2heap PoC は 2.23–2.25 をテストしました）。2.28 以降、“additional checks for unsorted bin integrity” パッチにより unsorted‑bin の書き込みが信頼できなくなり、成功率は大きく低下します。2.34 以降は __malloc_hook/__free_hook が削除され、元のターゲットは利用できなくなります。古い libc（またはフックを保持するカスタムビルド）や古い libc を同梱する CTF の場合のみ使用してください。
Tcache era (≥2.26): Tcache は 0x70 の割当を吸い取り、fastbin/unsorted のプリミティブを阻害します。割当の前に無効化する（setenv("GLIBC_TUNABLES","glibc.malloc.tcache_count=0",1);）か、各 0x70 tcache bin を 7 回の free で満たしてドレインしてください。
Safe-linking: ≥2.32 では tcache/fastbin に適用されますが、House of Roman は fd/bk に既に存在する libc アドレスの部分上書き（partial pointer overwrite） のみを必要とするため、safe-linking はここで防御側に有利にはなりません（攻撃者は新たなポインタを偽造しません）。真の阻害要因はフックの削除と unsorted‑bin のチェックです。

Code

例は以下で確認できます: https://github.com/shellphish/how2heap/blob/master/glibc_2.23/house_of_roman.c

前提条件

fastbin および unsorted bin のポインタを編集できること
12 ビットのランダム性を総当たりする必要がある（成功確率 0.02%）

攻撃手順

Part 1: Fastbin Chunk が __malloc_hook を指す

いくつかのチャンクを作成します:

fastbin_victim (0x60, offset 0): 後で UAF にして heap ポインタを編集し libc 値を指すようにするチャンク
chunk2 (0x80, offset 0x70): 良いアライメントのため
main_arena_use (0x80, offset 0x100)
relative_offset_heap (0x60, offset 0x190): ‘main_arena_use’ チャンク上の相対オフセット

次に free(main_arena_use) を実行すると、このチャンクは unsorted リストに入れられ、fd と bk の両方に main_arena + 0x68 へのポインタが入ります。

次に、fd と bk に main_arena + 0x68 へのポインタを含むために新しいチャンク fake_libc_chunk(0x60) を割り当てます。

その後、relative_offset_heap と fastbin_victim を free します。

/*
Current heap layout:
0x0:   fastbin_victim       - size 0x70
0x70:  alignment_filler     - size 0x90
0x100: fake_libc_chunk      - size 0x70 (contains a fd ptr to main_arena + 0x68)
0x170: leftover_main        - size 0x20
0x190: relative_offset_heap - size 0x70

bin layout:
fastbin:  fastbin_victim -> relative_offset_heap
unsorted: leftover_main
*/

fastbin_victim の fd は relative_offset_heap を指している
relative_offset_heap は fake_libc_chunk からのオフセットで、fake_libc_chunk は main_arena + 0x68 を指すポインタを含んでいる
fastbin_victim.fd の最後のバイトを変更すると fastbin_victim が main_arena + 0x68 を指すようになる。

For the previous actions, the attacker needs to be capable of modifying the fd pointer of fastbin_victim.

Then, main_arena + 0x68 is not that interesting, so let’s modify it so the pointer points to __malloc_hook.

Note that __memalign_hook usually starts with 0x7f and zeros before it, then it’s possible to fake it as a value in the 0x70 fast bin. Because the last 4 bits of the address are ランダム there are 2^4=16 possibilities for the value to end pointing where we are interested. So a BF attack is performed here so the chunk ends like: 0x70: fastbin_victim -> fake_libc_chunk -> (__malloc_hook - 0x23).

(For more info about the rest of the bytes check the explanation in the how2heap example). If the brute force fails the program just crashes (restart until it works).

Then, 2 mallocs are performed to remove the 2 initial fast bin chunks and a third one is allocated to get a chunk in __malloc_hook.

malloc(0x60);
malloc(0x60);
uint8_t* malloc_hook_chunk = malloc(0x60);

パート 2: Unsorted_bin attack

詳しくは次を参照してください:

Unsorted Bin Attack

しかし基本的には、main_arena + 0x68をchunk->bkで指定された任意の場所に書き込むことができます。攻撃では__malloc_hookを選びます。上書きした後、相対オーバーライトを使ってone_gadgetを指すようにします。

これを行うため、まずchunkを取得してunsorted binに入れます:

uint8_t* unsorted_bin_ptr = malloc(0x80);
malloc(0x30); // Don't want to consolidate

puts("Put chunk into unsorted_bin\n");
// Free the chunk to create the UAF
free(unsorted_bin_ptr);

Use an UAF in this chunk to point unsorted_bin_ptr->bk to the address of __malloc_hook (we brute forced this previously).

Caution

注意: この攻撃は unsorted bin を破壊します（したがって small や large も影響を受けます）。そのため今後は fast bin からの割当のみを使用できます（より複雑なプログラムでは他の割当が走ってクラッシュする可能性があります）、そしてこれを誘発するには 同じサイズで alloc しないとプログラムがクラッシュします。

So, to trigger the write of main_arena + 0x68 in __malloc_hook we perform after setting __malloc_hook in unsorted_bin_ptr->bk we just need to do: malloc(0x80)

ステップ3: __malloc_hook を system に設定

In step one we controlled a chunk containing __malloc_hook (in the variable malloc_hook_chunk) and in the second step we managed to write main_arena + 0x68 there.

Now, we abuse a partial overwrite in malloc_hook_chunk to use the libc address we wrote there (main_arena + 0x68) to point to a one_gadget address.

Here is where it’s needed to bruteforce 12 bits of randomness (more info in the how2heap example).

Finally, once the correct address is overwritten, call malloc and trigger the one_gadget.

Modern tips & variants

Unsorted-bin hardening (2.28+): unsorted チャンクに対する追加の整合性チェック（サイズの妥当性 + リスト連結）が従来の unsorted‑bin 書き換えを脆弱にします。_int_malloc を通過させるには fd/bk のリンクを一貫させ、サイズをもっともらしく保つ必要があり、通常は単純な部分上書き以上の強力なプリミティブが必要です。
Hook removal (2.34+): __malloc_hook が無くなった環境では、後で再利用できる任意の書き込み可能な GOT/グローバルに狙いを変える（例: non-PIE バイナリの exit@GOT を上書きする）か、hook の代わりに top を制御する House of Pie スタイルの top‑chunk ハイジャックにピボットするようプリミティブを適合させてください。
Any‑address fastbin alloc (romanking98 writeup): 後半では 0x71 フリーリストの修復を行い、unsorted‑bin 書き換えを使って fastbin 割当を __free_hook 上に降ろし、system("/bin/sh") を置いて libc‑2.24（hook 削除前）で free() によってトリガーする手法を示しています。

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

サブスクリプションプランを確認してください！

**💬 Discordグループまたはテレグラムグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローしてください。

HackTricksおよびHackTricks CloudのGitHubリポジトリにPRを提出してハッキングトリックを共有してください。