Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-29 08:01:00 +00:00

Translator 9a053f9ff3 Translated ['binary-exploitation/heap/bins-and-memory-allocations.md', '

2024-06-13 00:49:14 +00:00

40 KiB

Raw Blame History

ビンとメモリ割り当て

htARTE（HackTricks AWS Red Team Expert）を使って、ゼロからヒーローまでAWSハッキングを学びましょう！

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

HackTricks で企業を宣伝したい場合や、HackTricks をPDFでダウンロードしたい場合は、SUBSCRIPTION PLANS をチェックしてください！
公式PEASS＆HackTricksスウォッグを入手する
The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける
💬 Discordグループ に参加するか、telegramグループに参加するか、Twitter 🐦 @hacktricks_live をフォローする
ハッキングトリックを共有するために、PRを HackTricks と HackTricks Cloud のGitHubリポジトリに提出してください

基本情報

チャンクの格納効率を向上させるために、各チャンクは1つのリンクリストにだけではなく、複数のタイプに分かれて格納されます。これらはビンであり、5種類のビンがあります：62 small bins、63 large bins、1 unsorted bin、10 fast bins、およびスレッドごとに64のtcache binsがあります。

各未整列、small、largeビンへの初期アドレスは同じ配列内にあります。インデックス0は未使用で、1は未整列ビン、ビン2-64はsmallビン、ビン65-127はlargeビンです。

Tcache（スレッドごとのキャッシュ）ビン

スレッドは独自のヒープを持とうとしますが（Arenas および Subheapsを参照）、多くのスレッドを持つプロセス（Webサーバーなど）は、別のスレッドとヒープを共有する可能性があります。この場合、主な解決策はロッカーの使用であり、これはスレッドを著しく遅くする可能性があります。

したがって、tcacheは、チャンクをマージしない単方向リンクリストであり、各スレッドには64個の単方向リンクtcacheビンがあります。各ビンには、64ビットシステムでは24〜1032B、32ビットシステムでは12〜516Bの同じサイズのチャンクを最大7つ持つことができます。

スレッドがチャンクを解放するとき、それがtcacheに割り当てられるには大きすぎないことと、対応するtcacheビンが満杯でないこと（すでに7つのチャンクがある）が必要です。tcacheに移動できない場合は、ヒープロックを待ってグローバルビンで解放操作を実行できるようにする必要があります。

チャンクが割り当てられるとき、Tcacheに必要なサイズの空きチャンクがあれば使用し、そうでない場合は、グローバルビンで見つけるか新しいチャンクを作成するためにヒープロックを待つ必要があります。
また、この場合の最適化があり、ヒープロックを取得する間に、スレッドは要求されたサイズのヒープチャンク（7つ）でTcacheを埋めるため、必要があればそれらをTcacheで見つけることができます。

tcacheチャンクの例を追加

```c #include #include

int main(void) { char *chunk; chunk = malloc(24); printf("Address of the chunk: %p\n", (void *)chunk); gets(chunk); free(chunk); return 0; }

コンパイルして、main 関数の ret オペコードにブレークポイントを設定してデバッグします。その後、gef を使用して tcache bin が使用されているのを確認できます:
```bash
gef➤  heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=0, size=0x20, count=1] ←  Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)

Tcacheの構造体と関数

以下のコードでは、max binsとchunks per index、**tcache_entry構造体が二重解放を回避するために作成されており、tcache_perthread_struct**は各スレッドがビンの各インデックスのアドレスを格納するために使用する構造体です。

tcache_entryとtcache_perthread_struct

```c // From f942a732d3/malloc/malloc.c

/* We want 64 entries. This is an arbitrary limit, which tunables can reduce. */

define TCACHE_MAX_BINS 64

define MAX_TCACHE_SIZE tidx2usize (TCACHE_MAX_BINS-1)

/* Only used to pre-fill the tunables. */

define tidx2usize(idx) (((size_t) idx) * MALLOC_ALIGNMENT + MINSIZE - SIZE_SZ)

/* When "x" is from chunksize(). */

define csize2tidx(x) (((x) - MINSIZE + MALLOC_ALIGNMENT - 1) / MALLOC_ALIGNMENT)

/* When "x" is a user-provided size. */

define usize2tidx(x) csize2tidx (request2size (x))

/* With rounding and alignment, the bins are... idx 0 bytes 0..24 (64-bit) or 0..12 (32-bit) idx 1 bytes 25..40 or 13..20 idx 2 bytes 41..56 or 21..28 etc. */

/* This is another arbitrary limit, which tunables can change. Each tcache bin will hold at most this number of chunks. */

define TCACHE_FILL_COUNT 7

/* Maximum chunks in tcache bins for tunables. This value must fit the range of tcache->counts[] entries, else they may overflow. */

define MAX_TCACHE_COUNT UINT16_MAX

[...]

typedef struct tcache_entry { struct tcache_entry next; / This field exists to detect double frees. */ uintptr_t key; } tcache_entry;

/* There is one of these for each thread, which contains the per-thread cache (hence "tcache_perthread_struct"). Keeping overall size low is mildly important. Note that COUNTS and ENTRIES are redundant (we could have just counted the linked list each time), this is for performance reasons. */ typedef struct tcache_perthread_struct { uint16_t counts[TCACHE_MAX_BINS]; tcache_entry *entries[TCACHE_MAX_BINS]; } tcache_perthread_struct;

</details>

`__tcache_init` 関数は、`tcache_perthread_struct` オブジェクトのスペースを作成および割り当てる関数です。

<details>

<summary>tcache_init コード</summary>
```c
// From https://github.com/bminor/glibc/blob/f942a732d37a96217ef828116ebe64a644db18d7/malloc/malloc.c#L3241C1-L3274C2

static void
tcache_init(void)
{
mstate ar_ptr;
void *victim = 0;
const size_t bytes = sizeof (tcache_perthread_struct);

if (tcache_shutting_down)
return;

arena_get (ar_ptr, bytes);
victim = _int_malloc (ar_ptr, bytes);
if (!victim && ar_ptr != NULL)
{
ar_ptr = arena_get_retry (ar_ptr, bytes);
victim = _int_malloc (ar_ptr, bytes);
}


if (ar_ptr != NULL)
__libc_lock_unlock (ar_ptr->mutex);

/* In a low memory situation, we may not be able to allocate memory
- in which case, we just keep trying later.  However, we
typically do this very early, so either there is sufficient
memory, or there isn't enough memory to do non-trivial
allocations anyway.  */
if (victim)
{
tcache = (tcache_perthread_struct *) victim;
memset (tcache, 0, sizeof (tcache_perthread_struct));
}

}

Tcache インデックス

Tcache には、サイズに応じて複数のビンがあり、各インデックスの最初のチャンクへのポインタと、各インデックスごとのチャンクの数がチャンク内に配置されています。このことは、この情報を持つチャンク（通常は最初のチャンク）を見つけることで、すべての tcache の初期ポイントと Tcache チャンクの数を見つけることができるということを意味します。

ファストビン

ファストビンは、小さなチャンクのメモリ割り当てを高速化するために、最近解放されたチャンクをクイックアクセス構造に保持することで設計されています。これらのビンは、最後に解放されたチャンクが再利用されるため、最新の解放されたチャンクが最初になるという Last-In, First-Out (LIFO) アプローチを使用しています。この動作は、スピード向上に有利であり、スタック（LIFO）の先頭に挿入および削除する速度が、キュー（FIFO）と比較して速いためです。

さらに、ファストビンは単方向リンクリストを使用しており、ダブルリンクリストではないため、さらなる速度向上が図られています。ファストビンのチャンクは隣接するチャンクとマージされないため、中間からの削除を許可する複雑な構造は不要です。単方向リンクリストは、これらの操作に対してよりシンプルで迅速です。

基本的に、ここで起こることは、ヘッダー（チェックする最初のチャンクへのポインタ）が常にそのサイズの最新の解放されたチャンクを指しているということです。したがって：

そのサイズの新しいチャンクが割り当てられると、ヘッダーは使用する空きチャンクを指しています。この空きチャンクが次に使用するチャンクを指しているため、このアドレスはヘッダーに保存され、次の割り当てがどこから利用可能なチャンクを取得するかを知ることができます。
チャンクが解放されると、空きチャンクは現在の利用可能なチャンクへのアドレスを保存し、この新しく解放されたチャンクへのアドレスがヘッダーに配置されます。

リンクリストの最大サイズは 0x80 であり、サイズ 0x20-0x2f のチャンクはインデックス 0 に、サイズ 0x30-0x3f のチャンクは idx 1 になります...

{% hint style="danger" %} ファストビンのチャンクは利用可能として設定されていないため、周囲の他の空きチャンクとマージできる代わりに、一定の時間ファストビンのチャンクとして保持されます。 {% endhint %}

// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711

/*
Fastbins

An array of lists holding recently freed small chunks.  Fastbins
are not doubly linked.  It is faster to single-link them, and
since chunks are never removed from the middles of these lists,
double linking is not necessary. Also, unlike regular bins, they
are not even processed in FIFO order (they use faster LIFO) since
ordering doesn't much matter in the transient contexts in which
fastbins are normally used.

Chunks in fastbins keep their inuse bit set, so they cannot
be consolidated with other free chunks. malloc_consolidate
releases all chunks in fastbins and consolidates them with
other free chunks.
*/

typedef struct malloc_chunk *mfastbinptr;
#define fastbin(ar_ptr, idx) ((ar_ptr)->fastbinsY[idx])

/* offset 2 to use otherwise unindexable first 2 bins */
#define fastbin_index(sz) \
((((unsigned int) (sz)) >> (SIZE_SZ == 8 ? 4 : 3)) - 2)


/* The maximum fastbin request size we support */
#define MAX_FAST_SIZE     (80 * SIZE_SZ / 4)

#define NFASTBINS  (fastbin_index (request2size (MAX_FAST_SIZE)) + 1)

高速ビンチャンクの例を追加

```c #include #include

int main(void) { char *chunks[8]; int i;

// Loop to allocate memory 8 times for (i = 0; i < 8; i++) { chunks[i] = malloc(24); if (chunks[i] == NULL) { // Check if malloc failed fprintf(stderr, "Memory allocation failed at iteration %d\n", i); return 1; } printf("Address of chunk %d: %p\n", i, (void *)chunks[i]); }

// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }

return 0; }

注意してください。同じサイズの8つのチャンクを割り当てて解放する方法に注目してください。これにより、tcacheが埋まり、8番目のチャンクがfastチャンクに格納されます。

それをコンパイルし、main関数のretオペコードにブレークポイントを設定してデバッグします。その後、gefを使用して、tcache binが埋まり、1つのチャンクがfast binに格納されているのが見えます。
```bash
gef➤  heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=0, size=0x20, count=7] ←  Chunk(addr=0xaaaaaaac1770, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1750, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1730, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1710, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac16f0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac16d0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20]  ←  Chunk(addr=0xaaaaaaac1790, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
Fastbins[idx=1, size=0x30] 0x00

Unsorted bin

未整列のビンは、ヒープマネージャーがメモリ割り当てを迅速に行うために使用するキャッシュです。動作は次のとおりです。プログラムがチャンクを解放すると、このチャンクがtcacheやfast binに割り当てられず、かつトップチャンクと衝突していない場合、ヒープマネージャーはそれをすぐに特定の小さなビンや大きなビンに配置しません。代わりに、隣接する空きチャンクとマージしてより大きな空きメモリブロックを作成しようとします。その後、この新しいチャンクを「未整列のビン」と呼ばれる一般的なビンに配置します。

プログラムがメモリを要求すると、ヒープマネージャーは未整列のビンをチェックして十分なサイズのチャンクがあるかどうかを確認します。見つかれば、すぐに使用します。未整列のビンに適したチャンクが見つからない場合、このリスト内のすべてのチャンクを、サイズに応じて小さなビンまたは大きなビンに移動します。

大きなチャンクが2つに分割され、残りがMINSIZEより大きい場合、それは未整列のビンに戻されます。

したがって、未整列のビンは、最近解放されたメモリを迅速に再利用し、時間のかかる検索とマージの必要性を減らすことでメモリ割り当てを高速化する方法です。

{% hint style="danger" %} 異なるカテゴリのチャンクであっても、利用可能なチャンクが他の利用可能なチャンクと衝突している場合（元々異なるビンに属していても）、それらはマージされます。 {% endhint %}

未整列のチャンクの例を追加

```c #include #include

int main(void) { char *chunks[9]; int i;

// Loop to allocate memory 8 times for (i = 0; i < 9; i++) { chunks[i] = malloc(0x100); if (chunks[i] == NULL) { // Check if malloc failed fprintf(stderr, "Memory allocation failed at iteration %d\n", i); return 1; } printf("Address of chunk %d: %p\n", i, (void *)chunks[i]); }

// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }

return 0; }

注意してください。同じサイズの9つのチャンクを割り当てて解放する方法について。これにより、**tcacheが埋まり**、8番目のチャンクは**fastbinには大きすぎるため、unsorted binに格納**され、9番目のチャンクは解放されないため、9番目と8番目は**トップチャンクとマージされない**。

それをコンパイルして、main関数のretオペコードにブレークポイントを設定してデバッグします。その後、gefを使用して、tcache binが埋まり、unsorted binに1つのチャンクがあるのが見えます。
```bash
gef➤  heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=15, size=0x110, count=7] ←  Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] unsorted_bins[0]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
→   Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[+] Found 1 chunks in unsorted bin.

Small Bins

Small binsはlarge binsよりも速く、fast binsよりも遅いです。

62のbinのそれぞれには同じサイズのチャンクがあります: 16, 24, ... (32ビットでは最大504バイト、64ビットでは1024バイト)。これにより、空間を割り当てるべきbinを見つける速度や、これらのリストにエントリを挿入および削除する速度が向上します。

これがsmall binのサイズがbinのインデックスに応じてどのように計算されるかです:

最小サイズ: 2*4*index (例: インデックス5 -> 40)
最大サイズ: 2*8*index (例: インデックス5 -> 80)

// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711
#define NSMALLBINS         64
#define SMALLBIN_WIDTH    MALLOC_ALIGNMENT
#define SMALLBIN_CORRECTION (MALLOC_ALIGNMENT > CHUNK_HDR_SZ)
#define MIN_LARGE_SIZE    ((NSMALLBINS - SMALLBIN_CORRECTION) * SMALLBIN_WIDTH)

#define in_smallbin_range(sz)  \
((unsigned long) (sz) < (unsigned long) MIN_LARGE_SIZE)

#define smallbin_index(sz) \
((SMALLBIN_WIDTH == 16 ? (((unsigned) (sz)) >> 4) : (((unsigned) (sz)) >> 3))\
+ SMALLBIN_CORRECTION)

関数は、小さなビンと大きなビンの間で選択します：

#define bin_index(sz) \
((in_smallbin_range (sz)) ? smallbin_index (sz) : largebin_index (sz))

小さなチャンクの例を追加

```c #include #include

int main(void) { char *chunks[10]; int i;

// Loop to free the allocated memory for (i = 0; i < 8; i++) { free(chunks[i]); }

chunks[9] = malloc(0x110);

return 0; }

9つの同じサイズのチャンクを割り当てて解放する方法に注目してください。これにより、それらが**tcacheを埋める**ようになり、8つ目は**fastbinには大きすぎる**ため、unsorted binに格納され、9つ目は解放されないため、9つ目と8つ目は**トップチャンクとマージされない**。その後、0x110の大きなチャンクを割り当てることで、**unsorted binのチャンクがsmall binに移動**します。

それをコンパイルして、main関数のretオペコードにブレークポイントを設定してデバッグします。その後、gefを使用して、tcache binが埋まり、small binに1つのチャンクがあるのが見えます。
```bash
gef➤  heap bins
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
Tcachebins[idx=15, size=0x110, count=7] ←  Chunk(addr=0xaaaaaaac1d10, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1c00, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac1af0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac19e0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac18d0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac17c0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  Chunk(addr=0xaaaaaaac12a0, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in unsorted bin.
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
[+] small_bins[16]: fw=0xaaaaaaac1e10, bk=0xaaaaaaac1e10
→   Chunk(addr=0xaaaaaaac1e20, size=0x110, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[+] Found 1 chunks in 1 small non-empty bins.

ラージビン

小さなビンが固定サイズのチャンクを管理するのに対し、各ラージビンはチャンクサイズの範囲を扱います。これにより、システムはさまざまなサイズを別々のビンを必要とせずに収容できるようになります。

メモリアロケーターにおいて、ラージビンは小さなビンの終わりから始まります。ラージビンの範囲は徐々に大きくなり、最初のビンは512から576バイトのチャンクをカバーし、次のビンは576から640バイトをカバーします。このパターンが続き、最大のビンには1MBを超えるすべてのチャンクが含まれます。

ラージビンは、割り当てに最適なチャンクを見つけるためにさまざまなチャンクサイズのリストをソートして検索する必要があるため、小さなビンよりも操作が遅くなります。チャンクがラージビンに挿入されると、ソートする必要があり、メモリが割り当てられるときにシステムは適切なチャンクを見つける必要があります。この追加作業により、ラージビンは遅くなりますが、大きな割り当てが小さな割り当てよりも少ないため、これは許容できるトレードオフです。

以下のようなものがあります：

64B範囲の32ビン（小さなビンと衝突する）
512B範囲の16ビン（小さなビンと衝突する）
4096B範囲の8ビン（一部が小さなビンと衝突する）
32768B範囲の4ビン
262144B範囲の2ビン
残りのサイズ用の1ビン

ラージビンサイズのコード

```c // From a07e000e82/malloc/malloc.c (L1711)

#define largebin_index_32(sz)
(((((unsigned long) (sz)) >> 6) <= 38) ? 56 + (((unsigned long) (sz)) >> 6) :
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :
126)

#define largebin_index_32_big(sz)
(((((unsigned long) (sz)) >> 6) <= 45) ? 49 + (((unsigned long) (sz)) >> 6) :
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :
126)

// XXX It remains to be seen whether it is good to keep the widths of // XXX the buckets the same or whether it should be scaled by a factor // XXX of two as well. #define largebin_index_64(sz)
(((((unsigned long) (sz)) >> 6) <= 48) ? 48 + (((unsigned long) (sz)) >> 6) :
((((unsigned long) (sz)) >> 9) <= 20) ? 91 + (((unsigned long) (sz)) >> 9) :
((((unsigned long) (sz)) >> 12) <= 10) ? 110 + (((unsigned long) (sz)) >> 12) :
((((unsigned long) (sz)) >> 15) <= 4) ? 119 + (((unsigned long) (sz)) >> 15) :
((((unsigned long) (sz)) >> 18) <= 2) ? 124 + (((unsigned long) (sz)) >> 18) :
126)

#define largebin_index(sz) \
(SIZE_SZ == 8 ? largebin_index_64 (sz) \: MALLOC_ALIGNMENT == 16 ? largebin_index_32_big (sz) \; largebin_index_32 (sz))

</details>

<details>

<summary>大きなチャンクの例を追加</summary>
```c
#include <stdlib.h>
#include <stdio.h>

int main(void)
{
char *chunks[2];

chunks[0] = malloc(0x1500);
chunks[1] = malloc(0x1500);
free(chunks[0]);
chunks[0] = malloc(0x2000);

return 0;
}

2つの大きな割り当てが行われ、そのうち1つが解放されます（これにより、それが未整列のビンに配置されます）、そしてより大きな割り当てが行われます（解放されたものが未整列のビンから大きなビンに移動します）。

それをコンパイルし、メイン関数からのretオペコードにブレークポイントを設定してデバッグします。その後、gefを使用してtcacheビンのフィルと大きなビン内の1つのチャンクを確認できます。

gef➤  heap bin
──────────────────────────────────────────────────────────────────────────────── Tcachebins for thread 1 ────────────────────────────────────────────────────────────────────────────────
All tcachebins are empty
───────────────────────────────────────────────────────────────────────── Fastbins for arena at 0xfffff7f90b00 ─────────────────────────────────────────────────────────────────────────
Fastbins[idx=0, size=0x20] 0x00
Fastbins[idx=1, size=0x30] 0x00
Fastbins[idx=2, size=0x40] 0x00
Fastbins[idx=3, size=0x50] 0x00
Fastbins[idx=4, size=0x60] 0x00
Fastbins[idx=5, size=0x70] 0x00
Fastbins[idx=6, size=0x80] 0x00
─────────────────────────────────────────────────────────────────────── Unsorted Bin for arena at 0xfffff7f90b00 ───────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in unsorted bin.
──────────────────────────────────────────────────────────────────────── Small Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
[+] Found 0 chunks in 0 small non-empty bins.
──────────────────────────────────────────────────────────────────────── Large Bins for arena at 0xfffff7f90b00 ────────────────────────────────────────────────────────────────────────
[+] large_bins[100]: fw=0xaaaaaaac1290, bk=0xaaaaaaac1290
→   Chunk(addr=0xaaaaaaac12a0, size=0x1510, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[+] Found 1 chunks in 1 large non-empty bins.

トップチャンク

// From https://github.com/bminor/glibc/blob/a07e000e82cb71238259e674529c37c12dc7d423/malloc/malloc.c#L1711

/*
Top

The top-most available chunk (i.e., the one bordering the end of
available memory) is treated specially. It is never included in
any bin, is used only if no other chunk is available, and is
released back to the system if it is very large (see
M_TRIM_THRESHOLD).  Because top initially
points to its own bin with initial zero size, thus forcing
extension on the first malloc request, we avoid having any special
code in malloc to check whether it even exists yet. But we still
need to do so when getting memory from system, so we make
initial_top treat the bin as a legal but unusable chunk during the
interval between initialization and the first call to
sysmalloc. (This is somewhat delicate, since it relies on
the 2 preceding words to be zero during this interval as well.)
*/

/* Conveniently, the unsorted bin can be used as dummy top on first call */
#define initial_top(M)              (unsorted_chunks (M))

基本的に、これは現在利用可能なヒープ全体を含むチャンクです。mallocが実行されると、使用可能なフリーチャンクがない場合、このトップチャンクは必要なスペースを提供するためにサイズを減らします。
トップチャンクへのポインタは、malloc_state構造体に格納されています。

さらに、最初に、未整列のチャンクをトップチャンクとして使用することができます。

トップチャンクの例を観察

```c #include #include

int main(void) { char *chunk; chunk = malloc(24); printf("Address of the chunk: %p\n", (void *)chunk); gets(chunk); return 0; }

コンパイルしてデバッグを行い、mainのretオペコードでブレークポイントを設定したところ、mallocがアドレス`0xaaaaaaac12a0`を返し、これがチャンクです:
```bash
gef➤  heap chunks
Chunk(addr=0xaaaaaaac1010, size=0x290, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac1010     00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................]
Chunk(addr=0xaaaaaaac12a0, size=0x20, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac12a0     41 41 41 41 41 41 41 00 00 00 00 00 00 00 00 00    AAAAAAA.........]
Chunk(addr=0xaaaaaaac12c0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac12c0     41 64 64 72 65 73 73 20 6f 66 20 74 68 65 20 63    Address of the c]
Chunk(addr=0xaaaaaaac16d0, size=0x410, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)
[0x0000aaaaaaac16d0     41 41 41 41 41 41 41 0a 00 00 00 00 00 00 00 00    AAAAAAA.........]
Chunk(addr=0xaaaaaaac1ae0, size=0x20530, flags=PREV_INUSE | IS_MMAPPED | NON_MAIN_ARENA)  ←  top chunk

トップチャンクがアドレス0xaaaaaaac1ae0にあることがわかります。これは最後に割り当てられたチャンクが0xaaaaaaac12a0にあり、サイズが0x410であったため、0xaaaaaaac12a0 + 0x410 = 0xaaaaaaac1ae0という結果になります。
また、トップチャンクの長さをそのチャンクヘッダーで見ることもできます。

gef➤  x/8wx 0xaaaaaaac1ae0 - 16
0xaaaaaaac1ad0:	0x00000000	0x00000000	0x00020531	0x00000000
0xaaaaaaac1ae0:	0x00000000	0x00000000	0x00000000	0x00000000

最後のリマインダー

mallocが使用され、チャンクが分割されると（未リンクリストからまたはトップチャンクからなど）、分割されたチャンクの残りから作成されたチャンクは「最後のリマインダー」と呼ばれ、そのポインタはmalloc_state構造体に格納されます。

割り当てフロー

次をチェックしてください：

{% content-ref url="heap-memory-functions/malloc-and-sysmalloc.md" %} malloc-and-sysmalloc.md {% endcontent-ref %}

解放フロー

次をチェックしてください：

{% content-ref url="heap-memory-functions/free.md" %} free.md {% endcontent-ref %}

ヒープ関数のセキュリティチェック

ヒープ内で頻繁に使用される関数によって実行されるセキュリティチェックを確認してください：

{% content-ref url="heap-memory-functions/heap-functions-security-checks.md" %} heap-functions-security-checks.md {% endcontent-ref %}

参考文献

AWSハッキングをゼロからヒーローまで学ぶ htARTE（HackTricks AWS Red Team Expert）！

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

HackTricksで企業を宣伝したいまたはHackTricksをPDFでダウンロードしたい場合は、SUBSCRIPTION PLANSをチェックしてください！
公式PEASS＆HackTricksスウォッグを手に入れる
The PEASS Familyを発見し、独占的なNFTsのコレクションを見つける
**💬 Discordグループに参加するか、telegramグループに参加するか、Twitter 🐦 @hacktricks_liveをフォローする
ハッキングトリックを共有するために、HackTricksとHackTricks CloudのGitHubリポジトリにPRを提出する

40 KiB Raw Blame History Unescape Escape

ビンとメモリ割り当て

基本情報

Tcache（スレッドごとのキャッシュ）ビン

Tcacheの構造体と関数

define TCACHE_MAX_BINS 64

define MAX_TCACHE_SIZE tidx2usize (TCACHE_MAX_BINS-1)

define tidx2usize(idx) (((size_t) idx) * MALLOC_ALIGNMENT + MINSIZE - SIZE_SZ)

define csize2tidx(x) (((x) - MINSIZE + MALLOC_ALIGNMENT - 1) / MALLOC_ALIGNMENT)

define usize2tidx(x) csize2tidx (request2size (x))

define TCACHE_FILL_COUNT 7

define MAX_TCACHE_COUNT UINT16_MAX

Tcache インデックス

ファストビン

Unsorted bin

Small Bins

ラージビン

トップチャンク

最後のリマインダー

割り当てフロー

解放フロー

ヒープ関数のセキュリティチェック

参考文献

40 KiB

Raw Blame History