Nakonec jsem svůj shell kód napsal jiným způsobem. Protože jsem nemohl přijít na to, jak se vrátit, nechal jsem jádro, aby za mě udělalo těžkou práci při návratu do uživatelské země. Cílem bylo provést můj bit eskalace privilegií a skočit zpět tam, kde se měla zranitelná funkce vrátit, s opravenými registry a zásobníkem.
Jakmile se jádro vrátilo ze zranitelné funkce (když nebylo přetečeno), všiml jsem si něčeho přes gdb . (Adresy jsou imaginární, ale stejně vysvětlují koncept.)
(gdb) x/i $eip
0xadd1: ret
(gdb) x/xw $esp
0xadd1: 0xadd2
(gdb) x/6i 0xadd2
0xadd2: add esp,0x40
0xadd3: pop ...
0xadd4: pop ...
0xadd5: pop ...
0xadd6: pop ...
0xadd7: ret
Ihned po návratu je tedy 0x40 bajtů zásobníku nevyužito a jednoduše zmizí s add esp návod. Využitím této skutečnosti jsem tedy zkonstruoval řetězec ROP (konstruoval jsem ho již při psaní této otázky, jeho úkolem bylo deaktivovat SMEP a skočit na můj shell kód uživatelské země), který byl dlouhý 24 bajtů. 4 bajty by přepsaly EIP v době návratu a zbývajících 20 (0x14 ) by ji následoval přímo do nepoužitého zásobníku. Zbývá nám tedy 0x2c bajtů nevyužitého zásobníku stále.
Ale kdybychom se vrátili zpět do 0xadd2 , riskovali bychom ztrátu dalších 0x14 bajtů cenných informací registru ze zásobníku a zaplnění registrů neplatnými daty. Mohli bychom add 0x2c na esp v našem shell kódu uživatelské země a přímo přejděte na 0xadd3 , přeskočí aktuální add instrukce.
Všimněte si také z relace ladění, vše kromě eax a ebx byly řádně obnoveny. Protože moje přetečení zničilo oba, musel jsem je obnovit s hodnotami podobnými případům, kdy funkce provedla čistý návrat. (To bylo jednoduché:nastavil jsem bod přerušení na 0xadd2 a extrahoval hodnoty z info reg )
Takže můj konečný shell kód uživatelské země byl tento:
Execute privesc payload -> add esp,0x2c -> register fixup -> jump to 0xadd3
Díky tomu se cesta kódu vrátila dokonale čistá a jádro za mě provedlo úkol skočit zpět do uživatelského režimu.