Off by one overflow

Tip

Jifunze na fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Jifunze na fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Jifunze na fanya mazoezi ya Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Support HackTricks

Angalia mpango wa usajili!

Jiunge na 💬 kikundi cha Discord au kikundi cha telegram au tufuatilie kwenye Twitter 🐦 @hacktricks_live.

Shiriki mbinu za hacking kwa kuwasilisha PRs kwa HackTricks na HackTricks Cloud repos za github.

Taarifa za Msingi

Kuwa na ufikiaji wa overflow ya 1B kunaruhusu mshambuliaji kubadilisha uwanja wa size wa chunk inayofuata. Hii inaruhusu kubadilisha ni chunk gani zitaachiliwa, na inaweza kusababisha kuundwa kwa chunk inayojumuisha chunk nyingine halali. Utekelezaji ni sawa na double free au overlapping chunks.

Kuna aina 2 za udhaifu za off by one:

Arbitrary byte: Aina hii inaruhusu kuandika juu ya byte hiyo kwa thamani yoyote
Null byte (off-by-null): Aina hii inaruhusu kuandika juu ya byte hiyo tu kwa 0x00
Mfano wa kawaida wa udhaifu huu unaweza kuonekana katika code ifuatayo ambapo tabia za strlen na strcpy ni tofauti, jambo linalowezesha kuweka byte 0x00 mwanzoni mwa chunk inayofuata.
Hii inaweza kutumiwa kwa kutumia House of Einherjar.
Ikiwa ukitumia Tcache, hili linaweza kutumika kupelekea hali ya double free situation.

Off-by-null

```c // From https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/off_by_one/ int main(void) { char buffer[40]=""; void *chunk1; chunk1 = malloc(24); puts("Get Input"); gets(buffer); if(strlen(buffer)==24) { strcpy(chunk1,buffer); } return 0; } ```

Among other checks, now whenever a chunk is free the previous size is compared with the size configured in the metadata’s chunk, making this attack fairly complex from version 2.28.

Code example:

https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c
Shambulizi hili halifanyi kazi tena kutokana na matumizi ya Tcaches.
Moreover, if you try to abuse it using larger chunks (so tcaches aren’t involved), you will get the error: malloc(): invalid next size (unsorted)

Goal

Fanya chunk iwekwe ndani ya chunk nyingine ili ufikiaji wa kuandika kwenye chunk ya pili uwaruhusu kuandika juu ya ile iliyomo

Requirements

Off by one overflow ili kubadilisha taarifa za size katika metadata

General off-by-one attack

Tenga chunks tatu A, B na C (kwa mfano sizes 0x20), na nyingine ili kuzuia consolidation na top-chunk.
Free C (inserted into 0x20 Tcache free-list).
Tumia chunk A kufanya overflow kwenye B. Abusa off-by-one ili kurekebisha field ya size ya B kutoka 0x21 hadi 0x41.
Sasa B inajumuisha free chunk C
Free B na allocate chunk ya 0x40 (itawekwa hapo tena)
Tunaweza kubadilisha pointer ya fd kutoka C, ambayo bado iko free (Tcache poisoning)

Off-by-null attack

3 chunks of memory (a, b, c) zimetengwa mfululizo. Kisha ile ya katikati ina free. Ile ya kwanza ina udhaifu wa off by one overflow na mshambuliaji anaitumia kwa byte 0x00 (ikiwa byte iliyotangulia ilikuwa 0x10 itafanya chunk ya katikati kuonyesha kwamba ni 0x10 ndogo kuliko ilivyo kweli).
Kisha, chunks 2 ndogo zaidi zinatengenezwa ndani ya freed chunk ya katikati (b), hata hivyo, kwa sababu b + b->size hairudishi mabadiliko kwenye c chunk kwa sababu anwani inayorejelewa ni ndogo kuliko inavyostahili.
Kisha, b1 na c zinafree. Kwa kuwa c - c->prev_size bado inarejea b (sasa b1), zote mbili zinachanganywa kuwa chunk moja. Hata hivyo, b2 bado iko ndani kati ya b1 na c.
Hatimaye, malloc mpya inafanywa ikirejesha eneo hili la kumbukumbu ambalo kwa kweli litakuwa linajumuisha b2, ikimruhusu mmiliki wa malloc mpya kudhibiti yaliyomo ndani ya b2.

This image explains perfectly the attack:

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks

Modern glibc hardening & bypass notes (>=2.32)

Safe-Linking sasa inalinda kila singly linked bin pointer kwa kuhifadhi fd = ptr ^ (chunk_addr >> 12), hivyo off-by-one inayobadilisha tu byte ya chini ya size kawaida pia inahitaji heap leak ili kukokotoa upya XOR mask kabla Tcache poisoning ifanye kazi.
A practical leakless trick is to “double-protect” a pointer: encode a pointer you already control with PROTECT_PTR, then reuse the same gadget to encode your forged pointer so the alignment check passes without revealing new addresses.
Workflow for safe-linking + single-byte corruptions:

Fanya chunk la victim likue hadi lifunike kabisa free chunk unayodhibiti (overlapping-chunk setup).
Leak pointer yoyote ya heap (stdout, UAF, partially controlled struct) na derivisha key heap_base >> 12.
Re-encode free-list pointers kabla ya kuziandika—panga value iliyokodishwa ndani ya user data na memcpy baadaye ikiwa unaandika tu single-byte writes.
Combine with Tcache bin attacks to redirect allocations into __free_hook or tcache_perthread_struct entries once the forged pointer is properly encoded.

A minimal helper to rehearse the encode/decode step while debugging modern exploits:

def protect(ptr, chunk_addr):
return ptr ^ (chunk_addr >> 12)

def reveal(encoded, chunk_addr):
return encoded ^ (chunk_addr >> 12)

chunk = 0x55555555c2c0
encoded_fd = protect(0xdeadbeefcaf0, chunk)
print(hex(reveal(encoded_fd, chunk)))  # 0xdeadbeefcaf0

Lengo la ulimwengu wa kweli la hivi karibuni: glibc __vsyslog_internal off-by-one (CVE-2023-6779)

Mnamo Januari 2024 Qualys ilielezea kwa undani CVE-2023-6779, off-by-one ndani ya __vsyslog_internal() inayotokea wakati syslog()/vsyslog() format strings zinazidi INT_MAX, hivyo \0 ya mwisho inaharibu byte ya chini kabisa ya size ya chunk inayofuata kwenye mifumo ya glibc 2.37–2.39 (Qualys advisory).
Pipeline yao ya exploit ya Fedora 38:

Tengeneza ident ya openlog() ndefu mno ili vasprintf irudishe heap buffer karibu na data inayodhibitiwa na mdukuzi.
Piga syslog() ili kuvunja byte ya size | prev_inuse ya chunk jirani, kuiweka free, na kulazimisha consolidation inayofunika data ya mdukuzi.
Tumia mtazamo ulioshirikishwa (overlapped view) kuharibu metadata ya tcache_perthread_struct na kuelekeza allocation inayofuata kwenye __free_hook, kuibadilisha na system/one_gadget kwa root.

Ili kuiga (reproduce) uandishi wa kuharibu kwenye harness, fork na argv[0] kubwa sana, piga openlog(NULL, LOG_PID, LOG_USER) kisha syslog(LOG_INFO, "%s", payload) ambapo payload = b"A" * 0x7fffffff; pwndbg’s heap bins inaonyesha mara moja single-byte overwrite.
Ubuntu inafuata mdudu kama CVE-2023-6779, ikidokeza truncation sawa ya INT ambayo inafanya hii kuwa off-by-one primitive yenye kuaminika.

Other Examples & References

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks
Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022
Off-by-one kutokana na strlen kuzingatia uwanja wa size wa chunk inayofuata.
Tcache inatumika, kwa hivyo shambulio la jumla la off-by-one hufanya kazi kupata arbitrary write primitive kupitia Tcache poisoning.
Asis CTF 2016 b00ks
Inawezekana kutumia off-by-one kutoa leak ya anwani kutoka heap kwa sababu byte 0x00 mwishoni mwa string inafutwa na uwanja unaofuata.
Arbitrary write hupatikana kwa kutumia uandishi wa off-by-one kufanya pointer igojee mahali mwingine ambapo struct bandia yenye pointers bandia itajengwa. Kisha, inawezekana kufuata pointer ya struct hii kupata arbitrary write.
Anwani ya libc ina-leak kwa sababu ikiwa heap imeongezwa kwa kutumia mmap, kumbukumbu iliyopewa na mmap ina offset thabiti kutoka libc.
Mwishowe arbitrary write inatumiwa kuandika kwenye anwani ya __free_hook kwa one gadget.
plaidctf 2015 plaiddb
Kuna NULL off-by-one vulnerability katika getline function inayosoma mistari ya input ya mtumiaji. Function hii inatumika kusoma “key” ya content na si content yenyewe.
Katika writeup vipande vya awali 5 viliundwa:
chunk1 (0x200)
chunk2 (0x50)
chunk5 (0x68)
chunk3 (0x1f8)
chunk4 (0xf0)
chunk defense (0x400) ili kuepuka kuunganishwa na top chunk
Kisha chunk 1, 5 na 3 zilirudishwa (freed), kwa hivyo:

[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]

- Kisha kwa kutumia vibaya chunk3 (0x1f8) null off-by-one inatumika kuandika prev_size hadi `0x4e0`.
- Angalia jinsi sizes za chunks 1, 2, 5 na 3 zilizotengwa awali pamoja na headers za 4 ya chunks hizo zinalingana na `0x4e0`: `hex(0x1f8 + 0x10 + 0x68 + 0x10 + 0x50 + 0x10 + 0x200) = 0x4e0`
- Kisha, chunk 4 ilifreed, ikizalisha chunk inayochukua chunks zote hadi mwanzo:
- ```python
[ 0x4e0 Chunk 1-2-5-3 (free) ] [ 0xf0 Chunk 4 (corrupted) ] [ 0x400 Chunk defense ]

[ 0x200 Chunk 1 (free) ] [ 0x50 Chunk 2 ] [ 0x68 Chunk 5 (free) ] [ 0x1f8 Chunk 3 (free) ] [ 0xf0 Chunk 4 ] [ 0x400 Chunk defense ]

- Kisha, `0x200` bytes zimetengwa zikijaza chunk 1 ya awali.
- Na 0x200 nyingine za bytes zimetengwa na chunk2 iliharibiwa; kwa hivyo hakuna leak na hii haifanyi kazi? Labda hii haipaswi kufanywa.
- Kisha, inatenga chunk nyingine na 0x58 "a"s (inaandika juu ya chunk2 na kufikia chunk5) na inabadilisha `fd` ya fast bin chunk ya chunk5 kuiielekeza kwenye `__malloc_hook`.
- Kisha, chunk ya 0x68 imetengwa ili fake fast bin chunk katika `__malloc_hook` iwe fast bin chunk inayofuata.
- Mwishowe, fast bin chunk mpya ya 0x68 inatengwa na `__malloc_hook` inabandikwa (overwritten) na anwani ya `one_gadget`.

## References

- [Qualys Security Advisory – CVE-2023-6246/6779/6780](https://www.qualys.com/2024/01/30/cve-2023-6246/syslog.txt)
- [Ubuntu Security – CVE-2023-6779](https://ubuntu.com/security/CVE-2023-6779)
- [Breaking Safe-Linking in Modern Glibc – Google CTF 2022 "saas" analysis](https://blog.csdn.net/2402_86373248/article/details/148717274)

> [!TIP]
> Jifunze na fanya mazoezi ya AWS Hacking:<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../../../../../images/arte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">\
> Jifunze na fanya mazoezi ya GCP Hacking: <img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training GCP Red Team Expert (GRTE)**](https://training.hacktricks.xyz/courses/grte)<img src="../../../../../images/grte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
> Jifunze na fanya mazoezi ya Azure Hacking: <img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">[**HackTricks Training Azure Red Team Expert (AzRTE)**](https://training.hacktricks.xyz/courses/azrte)<img src="../../../../../images/azrte.png" alt="" style="width:auto;height:24px;vertical-align:middle;">
>
> <details>
>
> <summary>Support HackTricks</summary>
>
> - Angalia [**mpango wa usajili**](https://github.com/sponsors/carlospolop)!
> - **Jiunge na** 💬 [**kikundi cha Discord**](https://discord.gg/hRep4RUj7f) au [**kikundi cha telegram**](https://t.me/peass) au **tufuatilie** kwenye **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Shiriki mbinu za hacking kwa kuwasilisha PRs kwa** [**HackTricks**](https://github.com/carlospolop/hacktricks) na [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos za github.
>
> </details>