Off by one overflow

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!

Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.

Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Basiese Inligting

Net toegang tot ’n 1B overflow laat ’n aanvaller toe om die size-veld van die volgende chunk te wysig. Dit maak dit moontlik om te manipuleer watter chunks werklik vrygestel word, wat moontlik ’n chunk kan genereer wat ’n ander legit chunk bevat. Die uitbuiting is soortgelyk aan double free of overlapping chunks.

Daar is 2 tipes off by one kwetsbaarhede:

Arbitrary byte: Hierdie tipe laat toe om daardie byte met enige waarde oor te skryf
Null byte (off-by-null): Hierdie tipe laat toe om daardie byte slegs met 0x00 oor te skryf
’n Algemene voorbeeld van hierdie kwetsbaarheid is in die volgende kode sigbaar waar die gedrag van strlen en strcpy inkonsekwent is, wat toelaat om ’n 0x00-byte aan die begin van die volgende chunk te plaas.
Dit kan uitgebuit word met die House of Einherjar.
As Tcache gebruik word, kan dit benut word tot ’n double free situasie.

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; } ```

Onder ander kontroles, nou wanneer ’n chunk vry is word die previous size vergelyk met die grootte wat in die metadata se chunk gekonfigureer is, wat hierdie aanval redelik kompleks maak vanaf weergawe 2.28.

Code example:

https://github.com/DhavalKapil/heap-exploitation/blob/d778318b6a14edad18b20421f5a06fa1a6e6920e/assets/files/shrinking_free_chunks.c
Hierdie aanval werk nie meer weens die gebruik van Tcaches nie.
Boonop, as jy probeer om dit te misbruik met groter chunks (sodat tcaches nie betrokke is nie), kry jy die fout: malloc(): invalid next size (unsorted)

Goal

Laat ’n chunk binne-in ’n ander chunk wees sodat skryf-toegang oor daardie tweede chunk die ingeslote een kan oor-skryf

Requirements

Off by one overflow om die size metadata-inligting te wysig

General off-by-one attack

Allokeer drie chunks A, B en C (bv. groottes 0x20), en nog een om konsolidasie met die top-chunk te voorkom.
Free C (ingesit in 0x20 Tcache free-list).
Gebruik chunk A om op B te overflow. Misbruik off-by-one om die size veld van B van 0x21 na 0x41 te verander.
Nou het ons B wat die vrye chunk C bevat
Free B en allokeer ’n 0x40 chunk (dit sal weer hier geplaas word)
Ons kan die fd pointer van C wysig, wat nog vry is (Tcache poisoning)

Off-by-null attack

3 geheuechunks (a, b, c) word een na die ander gereserveer. Dan word die middelste een gefree. Die eerste bevat ’n off by one overflow vulnerability en die aanvaller misbruik dit met ’n 0x00 (as die vorige byte 0x10 was sou dit maak dat die middelste chunk aangee dat dit 0x10 kleiner is as wat dit eintlik is).
Dan word nog 2 kleiner chunks in die middel-vrye chunk (b) gealloceer, maar aangesien b + b->size nooit die c chunk opdateer nie omdat die aangewese adres kleiner is as wat dit behoort te wees.
Dan word b1 en c gefree. Omdat c - c->prev_size steeds na b wys (b1 nou), word albei in een chunk gekonsolideer. egter, b2 is steeds daarin tussenin (inside).
Laastens word ’n nuwe malloc uitgevoer wat hierdie geheuearea hereis wat eintlik gaan b2 bevat, wat die eienaar van die nuwe malloc toelaat om die inhoud van b2 te beheer.

Hierdie prent verduidelik die aanval perfek:

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

Modern glibc hardening & bypass notes (>=2.32)

Safe-Linking beskerm nou elke singly linked bin pointer deur fd = ptr ^ (chunk_addr >> 12) te stoor, so ’n off-by-one wat slegs die lae byte van size flip gewoonlik ook ’n heap leak benodig om die XOR-masker te herbereken voordat Tcache poisoning werk.
’n Praktiese leakless truuk is om ’n pointer “double-protect” te maak: enkodeer ’n pointer wat jy reeds beheer met PROTECT_PTR, en hergebruik dan dieselfde gadget om jou vervalste pointer te enkodeer sodat die alignment check slaag sonder om nuwe adresse te openbaar.
Werkstroom vir safe-linking + single-byte corruptions:

Groei die slagoffer-chunk totdat dit volledig ’n vrye chunk wat jy reeds beheer dek (overlapping-chunk setup).
Leak enige heap pointer (stdout, UAF, gedeeltelik beheerste struct) en lei die sleutel heap_base >> 12 af.
Her-enkodeer free-list pointers voordat jy dit skryf—stageer die enkodeerde waarde binne user data en memcpy dit later as jy net enkelbyte-skrywes het.
Kombineer met Tcache bin attacks om allocaties na __free_hook of tcache_perthread_struct entries te herlei sodra die vervalste pointer behoorlik enkodeer is.

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

Onlangse werklike teiken: glibc __vsyslog_internal off-by-one (CVE-2023-6779)

In Januarie 2024 het Qualys CVE-2023-6779 beskryf, ’n off-by-one binne __vsyslog_internal() wat uitgelok word wanneer syslog()/vsyslog() formaatstringe INT_MAX oorskry, sodat die terminerende \0 die naaste blokkie se minste-gewigtige size-byte op glibc 2.37–2.39 stelsels korrupteer (Qualys advisory).
Hul Fedora 38 exploit-pyplyn:

Skep ’n oorlange openlog() ident sodat vasprintf ’n heap-buffert teruggee langs aanvallersbeheerde data.
Roep syslog() aan om die buurblok se size | prev_inuse byte te slaan, vry te gee, en konsolidasie te dwing wat met aanvallersdata oorvleuel.
Gebruik die oorvleuelde aansig om tcache_perthread_struct metadata te korrupteer en mik die volgende toegewysing na __free_hook, en oor skryf dit met system/’n one_gadget vir root.

Om die korrupterende skryf in ’n harness te reproduseer, fork met ’n reuse argv[0], roep openlog(NULL, LOG_PID, LOG_USER) en dan syslog(LOG_INFO, "%s", payload) waar payload = b"A" * 0x7fffffff; pwndbg se heap bins wys onmiddellik die enkel-byte oor skryf.
Ubuntu hou die fout op as CVE-2023-6779, en dokumenteer dieselfde INT-trunkering wat dit ’n betroubare off-by-one primêre maak.

Ander Voorbeelde & Verwysings

https://heap-exploitation.dhavalkapil.com/attacks/shrinking_free_chunks
Bon-nie-appetit. HTB Cyber Apocalypse CTF 2022
Off-by-one omdat strlen die volgende blokkie se size-veld in ag neem.
Tcache word gebruik, so algemene off-by-one-aanvalle werk om ’n arbitrary write-primitive te verkry met Tcache poisoning.
Asis CTF 2016 b00ks
Dit is moontlik om ’n off-by-one te misbruik om ’n adres van die heap te leak omdat die byte 0x00 aan die einde van ’n string oor geskryf word deur die volgende veld.
Arbitrary write word verkry deur die off-by-one skryf te misbruik om die pointer te laat wys na ’n ander plek waar ’n vals struct met valse pointers gebou sal word. Dan is dit moontlik om die pointer van hierdie struct te volg om arbitrary write te bewerkstellig.
Die libc-adres word geleak omdat as die heap uitgebrei word met mmap, die geheue wat deur mmap toegeken word ’n vaste offset vanaf libc het.
Uiteindelik word die arbitrary write misbruik om na die adres van __free_hook te skryf met ’n one gadget.
plaidctf 2015 plaiddb
Daar is ’n NULL off-by-one kwesbaarheid in die getline funksie wat gebruikersinvoerlyne lees. Hierdie funksie word gebruik om die “key” van die inhoud te lees en nie die inhoud nie.
In die writeup word 5 aanvanklike blokke geskep:
chunk1 (0x200)
chunk2 (0x50)
chunk5 (0x68)
chunk3 (0x1f8)
chunk4 (0xf0)
chunk defense (0x400) om te verhoed dat dit met die top chunk konsolideer
Dan word chunk 1, 5 en 3 vry gegee, so:

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

- Dan, deur chunk3 (0x1f8) te misbruik, word die null off-by-one misbruik om die prev_size na `0x4e0` te skryf.
- Let daarop hoe die groottes van die aanvanklik toegewezen blokke 1, 2, 5 en 3 plus die headers van 4 van daardie blokke gelyk is aan `0x4e0`: `hex(0x1f8 + 0x10 + 0x68 + 0x10 + 0x50 + 0x10 + 0x200) = 0x4e0`
- Dan word chunk 4 vry gegee, wat ’n blokkie genereer wat al die blokkies tot by die begin inneem:
- ```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 ]

- Dan word 0x200 bytes toegeken wat die oorspronklike chunk 1 vul
- En nog ’n 0x200 bytes word toegeken en chunk2 word vernietig en daarom is daar geen fucking leak en dit werk nie? Miskien moet dit nie so gedoen word nie
- Dan, dit ken ’n ander chunk toe met 0x58 "a"s (oor skryf chunk2 en bereik chunk5) en wysig die `fd` van die fast bin chunk van chunk5 wat dit na `__malloc_hook` wys
- Dan word ’n chunk van 0x68 toegeken sodat die vals fast bin chunk in `__malloc_hook` die volgende fast bin chunk is
- Uiteindelik word ’n nuwe fast bin chunk van 0x68 toegeken en `__malloc_hook` word met ’n `one_gadget` adres oor geskryf

## Verwysings

- [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]
> Leer en oefen 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;">\
> Leer en oefen 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;">
> Leer en oefen 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>Ondersteun HackTricks</summary>
>
> - Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
> - **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks_live**](https://twitter.com/hacktricks_live)**.**
> - **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
>
> </details>