hacktricks/binary-exploitation/heap/large-bin-attack.md

5.7 KiB
Raw Permalink Blame History

ラージビン攻撃

htARTEHackTricks AWS Red Team Expert でAWSハッキングをゼロからヒーローまで学ぶ

HackTricks をサポートする他の方法:

基本情報

ラージビンとは何かについての詳細情報は、次のページを参照してください:

{% content-ref url="bins-and-memory-allocations.md" %} bins-and-memory-allocations.md {% endcontent-ref %}

how2heap - large bin attack に素晴らしい例が見つかります。

基本的に、最新の「現在の」glibc2.35)では、P->bk_nextsize がチェックされていないため、特定の条件が満たされると大きなビンチャンクの値で任意のアドレスを変更できます。

その例では、次の条件が見つかります:

  • 大きなチャンクが割り当てられている
  • 最初のチャンクよりも小さいが同じインデックスにある大きなチャンクが割り当てられている
  • ビン内で最初に行く必要があるため、それよりも小さくなければならない
  • (トップチャンクとのマージを防ぐチャンクが作成される)
  • 次に、最初の大きなチャンクが解放され、それよりも大きな新しいチャンクが割り当てられる -> チャンク1はラージビンに移動
  • 次に、2番目の大きなチャンクが解放される
  • そして、脆弱性: 攻撃者は chunk1->bk_nextsize[target-0x20] に変更できる
  • 次に、チャンク2よりも大きなチャンクが割り当てられると、チャンク2がラージビンに挿入され、アドレス chunk1->bk_nextsize->fd_nextsize がチャンク2のアドレスで上書きされます

{% hint style="success" %} 他の潜在的なシナリオがありますが、重要なのは、ビンに現在のXチャンクよりも小さいチャンクを追加することです。そのためには、ビン内でそれよりも前に挿入する必要があり、Xの bk_nextsize を変更できる必要があります。それが小さなチャンクのアドレスが書き込まれる場所です。 {% endhint %}

これはmallocからの関連するコードです。アドレスがどのように上書きされたかをよりよく理解するためにコメントが追加されています:

{% code overflow="wrap" %}

/* if smaller than smallest, bypass loop below */
assert (chunk_main_arena (bck->bk));
if ((unsigned long) (size) < (unsigned long) chunksize_nomask (bck->bk))
{
fwd = bck; // fwd = p1
bck = bck->bk; // bck = p1->bk

victim->fd_nextsize = fwd->fd; // p2->fd_nextsize = p1->fd (Note that p1->fd is p1 as it's the only chunk)
victim->bk_nextsize = fwd->fd->bk_nextsize; // p2->bk_nextsize = p1->fd->bk_nextsize
fwd->fd->bk_nextsize = victim->bk_nextsize->fd_nextsize = victim; // p1->fd->bk_nextsize->fd_nextsize = p2
}

{% endcode %}

これは、global_max_fastのグローバル変数を上書きして、より大きなチャンクで高速ビンアタックを利用するために使用できます。

この攻撃の別の素晴らしい説明は、guyinatuxedoで見つけることができます。

htARTEHackTricks AWS Red Team Expertを使用して、ゼロからヒーローまでAWSハッキングを学びましょう

HackTricksをサポートする他の方法