mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/libc-heap/heap-overflow.md', 'src/b
This commit is contained in:
Translator
parent
35b4fc441b
commit
bd4f4ac7f1
@ -2,40 +2,40 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basiese Inligting
|
||||
## Basic Information
|
||||
|
||||
'n Heap overflow is soos 'n [**stack overflow**](../stack-overflow/index.html) maar in die heap. Basies beteken dit dat 'n sekere ruimte in die heap gereserveer is om data te stoor en **gestoorde data was groter as die gereserveerde ruimte.**
|
||||
|
||||
In stack overflows weet ons dat sommige registers soos die instruksie-aanwyser of die stack-raam gaan herstel word vanaf die stack en dit kan moontlik misbruik word. In die geval van heap overflows, daar **is geen sensitiewe inligting wat standaard in die heap chunk gestoor word** wat oorgeloop kan word nie. Dit kan egter sensitiewe inligting of aanwysers wees, so die **kritikaliteit** van hierdie kwesbaarheid **hang af** van **watter data oorgeskryf kan word** en hoe 'n aanvaller dit kan misbruik.
|
||||
In stack overflows weet ons dat sommige registers soos die instruksie-aanwyser of die stack-raam herstel gaan word vanaf die stack en dit kan moontlik misbruik word. In die geval van heap overflows, daar **is geen sensitiewe inligting wat standaard in die heap chunk gestoor word** wat oorgestroom kan word nie. Dit kan egter sensitiewe inligting of aanwysers wees, so die **kritikaliteit** van hierdie kwesbaarheid **hang af** van **watter data oorgeskryf kan word** en hoe 'n aanvaller dit kan misbruik.
|
||||
|
||||
> [!TIP]
|
||||
> Om overflow offsets te vind, kan jy dieselfde patrone gebruik soos in [**stack overflows**](../stack-overflow/index.html#finding-stack-overflows-offsets).
|
||||
> Om overflow offsets te vind, kan jy dieselfde patrone gebruik as in [**stack overflows**](../stack-overflow/index.html#finding-stack-overflows-offsets).
|
||||
|
||||
### Stack Overflows vs Heap Overflows
|
||||
|
||||
In stack overflows is die rangskikking en data wat teenwoordig gaan wees in die stack op die oomblik dat die kwesbaarheid geaktiveer kan word, redelik betroubaar. Dit is omdat die stack lineêr is, altyd toeneem in botsende geheue, in **spesifieke plekke van die program se uitvoering stoor die stack geheue gewoonlik soortgelyke tipe data** en dit het 'n spesifieke struktuur met sommige aanwysers aan die einde van die stack-gedeelte wat deur elke funksie gebruik word.
|
||||
In stack overflows is die rangskikking en data wat teenwoordig gaan wees in die stack op die oomblik dat die kwesbaarheid geaktiveer kan word, redelik betroubaar. Dit is omdat die stack lineêr is, altyd toeneem in botsende geheue, in **spesifieke plekke van die program se uitvoering stoor die stack geheue gewoonlik soortgelyke tipe data** en dit het 'n spesifieke struktuur met sommige aanwysers aan die einde van die stack deel wat deur elke funksie gebruik word.
|
||||
|
||||
In die geval van 'n heap overflow, is die gebruikte geheue egter nie lineêr nie, maar **toegewyde chunks is gewoonlik in geskeide posisies van geheue** (nie een langs die ander nie) as gevolg van **bins en sones** wat toewysings volgens grootte skei en omdat **vorige vrygemaakte geheue gebruik word** voordat nuwe chunks toegewy word. Dit is **gekompliseerd om die objek te weet wat gaan bots met die een wat kwesbaar is** vir 'n heap overflow. So, wanneer 'n heap overflow gevind word, is dit nodig om 'n **betroubare manier te vind om die gewenste objek volgende in geheue te maak** van die een wat oorgeloop kan word.
|
||||
In die geval van 'n heap overflow, is die gebruikte geheue egter nie lineêr nie, maar **toegewyde chunks is gewoonlik in geskeide posisies van geheue** (nie een langs die ander nie) as gevolg van **bins en sone** wat toewysings volgens grootte skei en omdat **vorige vrygemaakte geheue gebruik word** voordat nuwe chunks toegewy word. Dit is **komplikasies om die objek te weet wat gaan bots met die een wat kwesbaar is** vir 'n heap overflow. So, wanneer 'n heap overflow gevind word, is dit nodig om 'n **betroubare manier te vind om die gewenste objek volgende in geheue te maak** van die een wat oorgestroom kan word.
|
||||
|
||||
Een van die tegnieke wat hiervoor gebruik word, is **Heap Grooming** wat byvoorbeeld gebruik word [**in hierdie pos**](https://azeria-labs.com/grooming-the-ios-kernel-heap/). In die pos word verduidelik hoe wanneer in die iOS-kern wanneer 'n sone sonder geheue raak om chunks van geheue te stoor, dit dit uitbrei met 'n kernblad, en hierdie blad word in chunks van die verwagte groottes gesplit, wat in volgorde gebruik sal word (tot iOS weergawe 9.2, dan word hierdie chunks op 'n gerandomiseerde manier gebruik om die uitbuiting van hierdie aanvalle te bemoeilik).
|
||||
Een van die tegnieke wat hiervoor gebruik word, is **Heap Grooming** wat byvoorbeeld [**in hierdie pos**](https://azeria-labs.com/grooming-the-ios-kernel-heap/) gebruik word. In die pos word verduidelik hoe wanneer in die iOS-kern wanneer 'n sone uit geheue vir die stoor van chunks van geheue, dit dit uitbrei deur 'n kernbladsy, en hierdie bladsy word in chunks van die verwagte groottes gesplit, wat in volgorde gebruik sal word (tot iOS weergawe 9.2, dan word hierdie chunks op 'n randomiseerde manier gebruik om die uitbuiting van hierdie aanvalle te bemoeilik).
|
||||
|
||||
Daarom, in die vorige pos waar 'n heap overflow plaasvind, om die oorgeloopde objek te dwing om met 'n slagoffer volgorde te bots, word verskeie **`kallocs` deur verskeie drade gedwing om te probeer verseker dat al die vrye chunks gevul is en dat 'n nuwe blad geskep word**.
|
||||
Daarom, in die vorige pos waar 'n heap overflow plaasvind, om die oorgestroomde objek te dwing om met 'n slagoffer volgorde te bots, word verskeie **`kallocs` deur verskeie drade gedwing om te probeer verseker dat al die vrye chunks gevul is en dat 'n nuwe bladsy geskep word**.
|
||||
|
||||
Om hierdie vul met objek van 'n spesifieke grootte te dwing, is die **out-of-line toewysing geassosieer met 'n iOS mach port** 'n ideale kandidaat. Deur die grootte van die boodskap te vervaardig, is dit moontlik om die grootte van die `kalloc` toewysing presies te spesifiseer en wanneer die ooreenstemmende mach port vernietig word, sal die ooreenstemmende toewysing onmiddellik teruggegee word aan `kfree`.
|
||||
Om hierdie vul met objek van 'n spesifieke grootte te dwing, is die **out-of-line toewysing geassosieer met 'n iOS mach port** 'n ideale kandidaat. Deur die grootte van die boodskap te vervaardig, is dit moontlik om presies die grootte van `kalloc` toewysing te spesifiseer en wanneer die ooreenstemmende mach port vernietig word, sal die ooreenstemmende toewysing onmiddellik teruggegee word aan `kfree`.
|
||||
|
||||
Dan kan sommige van hierdie plekhouers **vrygestel** word. Die **`kalloc.4096` vrye lys stel elemente in 'n laaste-in-eerste-uit volgorde vry**, wat basies beteken dat as sommige plekhouers vrygestel word en die uitbuiting probeer om verskeie slagoffer objek te toewys terwyl dit probeer om die objek wat kwesbaar is vir overflow toe te wys, is dit waarskynlik dat hierdie objek gevolg sal word deur 'n slagoffer objek.
|
||||
Dan kan sommige van hierdie plekhouers **vrygestel** word. Die **`kalloc.4096` vrye lys stel elemente in 'n laaste-in-eerste-uit volgorde vry**, wat basies beteken dat as sommige plekhouers vrygestel word en die uitbuiting probeer om verskeie slagoffer objekte toe te wys terwyl dit probeer om die objek wat kwesbaar is vir overflow toe te wys, is dit waarskynlik dat hierdie objek gevolg sal word deur 'n slagoffer objek.
|
||||
|
||||
### Voorbeeld libc
|
||||
### Example libc
|
||||
|
||||
[**In hierdie bladsy**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) is dit moontlik om 'n basiese Heap overflow emulering te vind wat wys hoe om die prev in gebruik bit van die volgende chunk en die posisie van die prev grootte te oorskry, is dit moontlik om 'n **gebruikte chunk te konsolideer** (deur dit te laat dink dit is ongebruikte) en **dan dit weer toe te wys** terwyl dit in staat is om data wat in 'n ander aanwyser gebruik word, ook te oorskry.
|
||||
[**In hierdie bladsy**](https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html) is dit moontlik om 'n basiese Heap overflow emulering te vind wat wys hoe om die prev in gebruik bit van die volgende chunk te oorskryf en die posisie van die prev grootte, dit is moontlik om 'n **gebruikte chunk te konsolideer** (deur dit te laat dink dit is ongebruikte) en **dan dit weer toe te wys** terwyl dit in staat is om data wat in 'n ander aanwyser gebruik word, ook te oorskryf.
|
||||
|
||||
'n Ander voorbeeld van [**protostar heap 0**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap0/index.html) wys 'n baie basiese voorbeeld van 'n CTF waar 'n **heap overflow** misbruik kan word om die wenner funksie aan te roep om **die vlag te kry**.
|
||||
|
||||
In die [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) voorbeeld is dit moontlik om te sien hoe om 'n buffer overflow te misbruik, is dit moontlik om **in 'n naburige chunk 'n adres te oorskry** waar **arbitraire data van die gebruiker** geskryf gaan word.
|
||||
In die [**protostar heap 1**](https://guyinatuxedo.github.io/24-heap_overflow/protostar_heap1/index.html) voorbeeld is dit moontlik om te sien hoe om 'n buffer overflow te misbruik, dit is moontlik om **in 'n naby chunk 'n adres te oorskryf** waar **arbitraire data van die gebruiker** geskryf gaan word.
|
||||
|
||||
### Voorbeeld ARM64
|
||||
### Example ARM64
|
||||
|
||||
In die bladsy [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) kan jy 'n heap overflow voorbeeld vind waar 'n opdrag wat uitgevoer gaan word, in die volgende chunk van die oorgeloopde chunk gestoor word. So, dit is moontlik om die uitgevoerde opdrag te verander deur dit te oorskry met 'n maklike uitbuiting soos:
|
||||
In die bladsy [https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/](https://8ksec.io/arm64-reversing-and-exploitation-part-1-arm-instruction-set-simple-heap-overflow/) kan jy 'n heap overflow voorbeeld vind waar 'n opdrag wat uitgevoer gaan word, in die volgende chunk van die oorgestroomde chunk gestoor word. So, dit is moontlik om die uitgevoerde opdrag te verander deur dit te oorskryf met 'n maklike uitbuiting soos:
|
||||
```bash
|
||||
python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
|
||||
```
|
||||
@ -43,6 +43,38 @@ python3 -c 'print("/"*0x400+"/bin/ls\x00")' > hax.txt
|
||||
|
||||
- [**Auth-or-out. Hack The Box**](https://7rocky.github.io/en/ctf/htb-challenges/pwn/auth-or-out/)
|
||||
- Ons gebruik 'n Integer Overflow kwesbaarheid om 'n Heap Overflow te verkry.
|
||||
- Ons korrigeer wysers na 'n funksie binne 'n `struct` van die oorloopstuk om 'n funksie soos `system` in te stel en kode-uitvoering te verkry.
|
||||
- Ons korrigeer pointers na 'n funksie binne 'n `struct` van die oorloopde stuk om 'n funksie soos `system` in te stel en kode-uitvoering te verkry.
|
||||
|
||||
### Werklike Voorbeeld: CVE-2025-40597 – Misbruik van `__sprintf_chk`
|
||||
|
||||
In SonicWall SMA100 firmware 10.2.1.15 allokeer die reverse-proxy module `mod_httprp.so` 'n **0x80-byte** heap stuk en voeg dan verskeie strings daarin saam met `__sprintf_chk`:
|
||||
```c
|
||||
char *buf = calloc(0x80, 1);
|
||||
/* … */
|
||||
__sprintf_chk(buf, /* destination (0x80-byte chunk) */
|
||||
-1, /* <-- size argument !!! */
|
||||
0, /* flags */
|
||||
"%s%s%s%s", /* format */
|
||||
"/", "https://", path, host);
|
||||
```
|
||||
`__sprintf_chk` is deel van **_FORTIFY_SOURCE**. Wanneer dit 'n **positiewe** `size` parameter ontvang, verifieer dit dat die resulterende string binne die bestemmingsbuffer pas. Deur **`-1` (0xFFFFFFFFFFFFFFFF)** te stuur, het die ontwikkelaars effektief die **grenskontrole gedeaktiveer**, wat die versterkte oproep terug na 'n klassieke, onveilige `sprintf` verander.
|
||||
|
||||
Die verskaffing van 'n te lang **`Host:`** kop laat dus 'n aanvaller toe om **die 0x80-byte stuk oor te vloei en die metadata van die volgende heap stuk te verwoes** (tcache / fast-bin / small-bin, afhangende van die toewysingsmeganisme). 'n Crash kan herproduseer word met:
|
||||
```python
|
||||
import requests, warnings
|
||||
warnings.filterwarnings('ignore')
|
||||
requests.get(
|
||||
'https://TARGET/__api__/',
|
||||
headers={'Host': 'A'*750},
|
||||
verify=False
|
||||
)
|
||||
```
|
||||
Praktiese uitbuiting sou **heap grooming** vereis om 'n beheerde objek reg na die kwesbare stuk te plaas, maar die wortel oorsaak beklemtoon twee belangrike afleidings:
|
||||
|
||||
1. **_FORTIFY_SOURCE is nie 'n silwer koeël nie** – misbruik kan die beskerming nietig maak.
|
||||
2. Gee altyd die **korrekte buffer grootte** aan die `_chk` familie (of, selfs beter, gebruik `snprintf`).
|
||||
|
||||
## References
|
||||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,11 +4,11 @@
|
||||
|
||||
## Wat is 'n Stack Overflow
|
||||
|
||||
'n **stack overflow** is 'n kwesbaarheid wat voorkom wanneer 'n program meer data na die stapel skryf as wat dit toegeken is om te hou. Hierdie oortollige data sal **aangrensende geheue ruimte oorskryf**, wat lei tot die korrupsie van geldige data, onderbreking van die beheerstroom, en moontlik die uitvoering van kwaadwillige kode. Hierdie probleem ontstaan dikwels as gevolg van die gebruik van onveilige funksies wat nie grensekontrole op invoer uitvoer nie.
|
||||
'n **stack overflow** is 'n kwesbaarheid wat voorkom wanneer 'n program meer data na die stap skryf as wat dit toegeken is om te hou. Hierdie oortollige data sal **aangrensende geheue ruimte oorskryf**, wat lei tot die korrupsie van geldige data, onderbreking van die beheerstroom, en moontlik die uitvoering van kwaadwillige kode. Hierdie probleem ontstaan dikwels as gevolg van die gebruik van onveilige funksies wat nie grensekontrole op invoer uitvoer nie.
|
||||
|
||||
Die hoofprobleem van hierdie oorskrywing is dat die **gestoor instruksie-aanwyser (EIP/RIP)** en die **gestoor basisaanwyser (EBP/RBP)** om na die vorige funksie terug te keer, **op die stapel gestoor word**. Daarom sal 'n aanvaller in staat wees om dit te oorskry en **die uitvoeringsvloei van die program te beheer**.
|
||||
Die hoofprobleem van hierdie oorskrywing is dat die **gestoor instruksie-aanwyser (EIP/RIP)** en die **gestoor basisaanwyser (EBP/RBP)** om na die vorige funksie terug te keer, **op die stap gestoor word**. Daarom sal 'n aanvaller in staat wees om dit te oorskryf en **die uitvoeringsvloei van die program te beheer**.
|
||||
|
||||
Die kwesbaarheid ontstaan gewoonlik omdat 'n funksie **meer bytes binne die stapel kopieer as die hoeveelheid wat daarvoor toegeken is**, en dus in staat is om ander dele van die stapel te oorskry.
|
||||
Die kwesbaarheid ontstaan gewoonlik omdat 'n funksie **meer bytes binne die stap kopieer as die hoeveelheid wat daarvoor toegeken is**, en kan dus ander dele van die stap oorskryf.
|
||||
|
||||
Sommige algemene funksies wat kwesbaar is hiervoor, is: **`strcpy`, `strcat`, `sprintf`, `gets`**... Ook, funksies soos **`fgets`**, **`read` & `memcpy`** wat 'n **lengte argument** neem, kan op 'n kwesbare manier gebruik word as die gespesifiseerde lengte groter is as die toegeken.
|
||||
|
||||
@ -21,13 +21,13 @@ gets(buffer); // This is where the vulnerability lies
|
||||
printf("You entered: %s\n", buffer);
|
||||
}
|
||||
```
|
||||
### Vind van Stack Overflows offsets
|
||||
### Vind van Stap Oorloop verskuiwings
|
||||
|
||||
Die mees algemene manier om stack overflows te vind, is om 'n baie groot invoer van `A`s te gee (bv. `python3 -c 'print("A"*1000)'`) en 'n `Segmentation Fault` te verwag wat aandui dat die **adres `0x41414141` probeer is om toegang te verkry**.
|
||||
Die mees algemene manier om stap oorloop te vind, is om 'n baie groot invoer van `A`s te gee (bv. `python3 -c 'print("A"*1000)'`) en 'n `Segmentation Fault` te verwag wat aandui dat die **adres `0x41414141` probeer is om toegang te verkry**.
|
||||
|
||||
Boonop, sodra jy gevind het dat daar 'n Stack Overflow kwesbaarheid is, sal jy die offset moet vind totdat dit moontlik is om die **terugadres te oorskryf**, hiervoor word gewoonlik 'n **De Bruijn-sekwensie** gebruik. Wat vir 'n gegewe alfabet van grootte _k_ en subreekse van lengte _n_ 'n **cykliese sekwensie is waarin elke moontlike subreeks van lengte _n_ presies een keer verskyn** as 'n aaneengeskakelde subreeks.
|
||||
Boonop, sodra jy gevind het dat daar 'n Stap Oorloop kwesbaarheid is, sal jy die verskuiwing moet vind totdat dit moontlik is om die **terugadres te oorskry**, hiervoor word gewoonlik 'n **De Bruijn-sekwensie** gebruik. Wat vir 'n gegewe alfabet van grootte _k_ en subreekse van lengte _n_ 'n **sikliese sekwensie is waarin elke moontlike subreeks van lengte _n_ presies een keer verskyn** as 'n aaneengeskakelde subreeks.
|
||||
|
||||
Op hierdie manier, in plaas daarvan om handmatig uit te vind watter offset nodig is om die EIP te beheer, is dit moontlik om een van hierdie sekwensies as opvulling te gebruik en dan die offset van die bytes te vind wat dit oorgeskryf het.
|
||||
Op hierdie manier, in plaas daarvan om handmatig uit te vind watter verskuiwing nodig is om die EIP te beheer, is dit moontlik om een van hierdie sekwensies as opvulling te gebruik en dan die verskuiwing van die bytes te vind wat dit oorgeskryf het.
|
||||
|
||||
Dit is moontlik om **pwntools** hiervoor te gebruik:
|
||||
```python
|
||||
@ -50,14 +50,14 @@ pattern search $rsp #Search the offset given the content of $rsp
|
||||
```
|
||||
## Exploiting Stack Overflows
|
||||
|
||||
Tydens 'n oorgang (as die oorganggrootte groot genoeg is) sal jy in staat wees om **oor te skryf** waardes van plaaslike veranderlikes binne die stapel totdat jy die **EBP/RBP en EIP/RIP (of selfs meer)** bereik.\
|
||||
Tydens 'n oorgang (veronderstel dat die oorganggrootte groot genoeg is) sal jy in staat wees om **oor te skryf** waardes van plaaslike veranderlikes binne die stapel totdat jy die **EBP/RBP en EIP/RIP (of selfs meer)** bereik.\
|
||||
Die mees algemene manier om hierdie tipe kwesbaarheid te misbruik, is deur die **terugadres te wysig** sodat wanneer die funksie eindig, die **kontrole vloei na waar die gebruiker gespesifiseer het** in hierdie pointer.
|
||||
|
||||
E however, in ander scenario's mag dit net **om te skryf van sommige veranderlikes waardes in die stapel** genoeg wees vir die uitbuiting (soos in maklike CTF-uitdagings).
|
||||
|
||||
### Ret2win
|
||||
|
||||
In hierdie tipe CTF-uitdagings, is daar 'n **funksie** **binne** die binêre wat **nooit aangeroep word** en wat **jy moet aanroep om te wen**. Vir hierdie uitdagings moet jy net die **offset vind om die terugadres te oorskryf** en **die adres van die funksie** vind om aan te roep (gewoonlik [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) sal gedeaktiveer wees) sodat wanneer die kwesbare funksie terugkeer, die verborge funksie aangeroep sal word:
|
||||
In hierdie tipe CTF-uitdagings, is daar 'n **funksie** **binne** die binêre wat **nooit aangeroep word** en wat **jy moet aanroep om te wen**. Vir hierdie uitdagings moet jy net die **offset vind om die terugadres oor te skryf** en **die adres van die funksie** vind om aan te roep (gewoonlik [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) sal gedeaktiveer wees) sodat wanneer die kwesbare funksie terugkeer, die verborge funksie aangeroep sal word:
|
||||
|
||||
{{#ref}}
|
||||
ret2win/
|
||||
@ -71,7 +71,7 @@ In hierdie scenario kan die aanvaller 'n shellcode in die stapel plaas en die be
|
||||
stack-shellcode/
|
||||
{{#endref}}
|
||||
|
||||
### ROP & Ret2... techniques
|
||||
### ROP & Ret2... tegnieke
|
||||
|
||||
Hierdie tegniek is die fundamentele raamwerk om die hoofbeskerming van die vorige tegniek te omseil: **Geen uitvoerbare stapel (NX)**. En dit stel in staat om verskeie ander tegnieke uit te voer (ret2lib, ret2syscall...) wat sal eindig met die uitvoering van arbitrêre opdragte deur bestaande instruksies in die binêre te misbruik:
|
||||
|
||||
@ -95,4 +95,32 @@ Daar is verskeie beskermings wat probeer om die uitbuiting van kwesbaarhede te v
|
||||
../common-binary-protections-and-bypasses/
|
||||
{{#endref}}
|
||||
|
||||
### Real-World Example: CVE-2025-40596 (SonicWall SMA100)
|
||||
|
||||
'n Goeie demonstrasie van waarom **`sscanf` nooit vertrou moet word vir die ontleding van onbetroubare invoer** het in 2025 in SonicWall se SMA100 SSL-VPN toestel verskyn. Die kwesbare roetine binne `/usr/src/EasyAccess/bin/httpd` probeer om die weergawe en eindpunt uit enige URI wat met `/__api__/` begin, te onttrek:
|
||||
```c
|
||||
char version[3];
|
||||
char endpoint[0x800] = {0};
|
||||
/* simplified proto-type */
|
||||
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
|
||||
```
|
||||
1. Die eerste konversie (`%2s`) stoor veilig **twee** bytes in `version` (bv. `"v1"`).
|
||||
2. Die tweede konversie (`%s`) **het geen lengte spesifiseerder nie**, daarom sal `sscanf` aanhou kopieer **tot die eerste NUL byte**.
|
||||
3. Omdat `endpoint` op die **stack** geleë is en **0x800 bytes** lank is, sal die verskaffing van 'n pad langer as 0x800 bytes alles wat na die buffer sit, korrupteer ‑ insluitend die **stack canary** en die **gestoor terugadres**.
|
||||
|
||||
'n Enkellyn bewys-van-konsep is genoeg om die krag te aktiveer **voor outentisering**:
|
||||
```python
|
||||
import requests, warnings
|
||||
warnings.filterwarnings('ignore')
|
||||
url = "https://TARGET/__api__/v1/" + "A"*3000
|
||||
requests.get(url, verify=False)
|
||||
```
|
||||
Alhoewel stapelkanaries die proses beëindig, verkry 'n aanvaller steeds 'n **Denial-of-Service** primitief (en, met bykomende inligtingslekke, moontlik kode-uitvoering). Die les is eenvoudig:
|
||||
|
||||
* Verskaf altyd 'n **maksimum veldwydte** (bv. `%511s`).
|
||||
* Verkies veiliger alternatiewe soos `snprintf`/`strncpy_s`.
|
||||
|
||||
## References
|
||||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user