Dobin 0x52_DefeatExploitMitigations.pdf
Dobin 0x52_DefeatExploitMitigations.pdf
Dobin 0x52_DefeatExploitMitigations.pdf
Kartei Details
| Karten | 21 |
|---|---|
| Sprache | English |
| Kategorie | Religion/Ethik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 24.06.2019 / 24.06.2019 |
| Lizenzierung | Keine Angabe |
| Weblink |
https://card2brain.ch/box/20190624_dobin_0x52defeatexploitmitigations_pdf
|
| Einbinden |
<iframe src="https://card2brain.ch/box/20190624_dobin_0x52defeatexploitmitigations_pdf/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
How can you defete the stack canary with arbitrary write?
With a string format like:
- userData = "AAAA%204x%n";
204 bytes are skiped.
When we have an arbitrary write we can write behind the stack canary.
How can we prevent arbitrary write?
Wrong:
- printf(userData);
Correct:
- printf("%s", userData)
What causes the arbitrary write vulnerability and why is this not a problem nowerdays?
Example: Formatstring attacks
- Problem:
- Did not specify format in source
- Problem: %n writrs data
- Nowadays:
- Easy to detect on compile time (static analysis)
- Easy to completly fix (rmeove %n)
- Nowadays: Net a problem anymore, solved
What does the stack cannary protect, does it protect from overwriting local variables?
The stack canary protects metadata fo the stack (SBP [Stored Base Pointer], SIP [Stored Instruction Pointer])
It does NOT protect Local variables.
Is the heap protected by the Stack Canary, and name some Heap Bug classes.
The heap is not protected by the Stack Canary.
Heap bug classes:
- Inter-chunk heap overflow/corruption
- Use after free
- Intra-chunk heap overflow / relative write
- Type confusion
How can you brute force the stack canary?
A network server fork()'s on connect()
- If child crashes, next connection gets an "identical" child with the same stack canary.
Stack canary stay's the same.
This allows us to iteratively bruteforce the stack cannary, by only partially overwriting it an testing.
A stack canary has 32 bites = 4 billion possibilites, how many posibilities are there if we brute force it iteratively?
4 * 2^8 = 1024 possibilities
This means an avarege of 512 tries (crashes)
Why do you need to brute force the SBP (Stored Base Pointer) first, before you can brute force the stack canary?
Need to break SBP (Stored Base Pointer) first...
Defeat ASLR (Address Space Layout Randomization) for free, because brute force SBP
- SBP points into stack segment
- ASLR is minimum on per-page level, lower 4096 bytes stay the same
