Niet read-only code segment

[Olaf van der Spek]

Je leest vrij vaak over bugs die door middel van een buffer overflow eigen code kunnen uitvoeren. Maar waarom is dit in de huidige OSs nog steeds mogelijk?
Waarom is het code segment niet gewoon read-only en is er geen alias die write toegang verleend?

[jeroen|IA]

Code segmenten zijn ook read-only. Een buffer overflow vindt meestal op de stack plaats. Bij de aanroep van een functie worden variabelen en het return address waar je programma verder moet gaan na de functie op de stack geplaatst. Door de inhoud van zo'n variabele veel groter te maken dan door de programmaschrijver bedoeld is (en wat hij dus niet afvangt met checks) kun je het return address van de functie terug laten wijzen naar een adres op de stack, bijvoorbeeld het adres van diezelfde variabele. Door nu de inhoud van je overflow slim te kiezen (in feite een stukje machinecode) kun je een stukje code laten uitvoeren. met de permissies van het aanroepende programma. Als die permissies die van root zijn heb je dus in feite toegang tot het hele systeem.

Overigens zijn er wel compilers die buffer overflows proberen af te vangen, en Linux distributies die daarop zijn gebaseerd door ze helemaal met die compiler te compileren. Immunix en Trustix zijn twee van zulke distributies.

[Olaf van der Spek]

Maar als je code segment read-only is en er geen alias is en het stack segment niet executeerbaar is werkt dat toch niet?

[deadinspace]

Op vrijdag 21 december 2001 16:08 schreef OlafvdSpek het volgende:
Maar als je code segment read-only is en er geen alias is en het stack segment niet executeerbaar is werkt dat toch niet?

Jawel.

code:

------------+-----------------+----------------
variabelen  | buffer        | stack
------------+-----------------+---------------

Als een function aangeroepen wordt, wordt het adres van het uitgevoerde commando op de stack gepusht, en naar de locatie van de function gesprongen. Als de function returnt, wordt die waarde van de stack gepopt, en weer daarheen gesprongen.

Maar als in die function nu 'buffer' wordt gebruikt, en deze buffer is te klein, dan wordt de stack overschreven met de informatie in de buffer. Als de function dan returnt, wordt gesprongen naar het adres wat in de stack staat. Door de buffer met een specifieke waarde te overschrijven kan dus bepaald worden waargeen gesprongen moet worden.

Dit gaat overigens niet alleen op voor stacks, maar voor alle informatie die misbruikt kan worden en na een te korte buffer staat.

[Olaf van der Spek]

Wat ik dus bedoel is dat het stack segment niet executeerbaar zou moeten zijn.

[jeroen|IA]

Daar zijn patches voor (althans voor Linux). Zie www.openwall.com. Zoals ik al zei zijn er ook compilers die programma's zo compileren dat buffer overflows afgevangen worden. Overigens heeft het SPARC platform volgens mij "echte" non-executable stack area's. Persoonlijk zie ik ook niet waarom stacks niet altijd non-executable zijn. Programma's die er gebruik van maken zijn gewoon vies geprogrammeerd.

[JayTaph]

Dit heb ik al ooit eens aan bod gebracht:

Voor de gevorderde coder

Wel pittige leesvoer, maar toch misschien interessant voor de "nieuwelingen"..

[serkoon]

Uiteindelijk maak je het alleen maar moeilijker om te exploiten, niet onmogelijk.

Dat is winst. Maar nog meer winst is netjes programmeren. En netjes programmeren begint bij netjes ontwerpen.

Maarjah.. het is niet allemaal rozegeur en maneschijn

[Olaf van der Spek]

Op vrijdag 21 december 2001 22:10 schreef JayTaph het volgende:
Dit heb ik al ooit eens aan bod gebracht:

Voor de gevorderde coder

Wel pittige leesvoer, maar toch misschien interessant voor de "nieuwelingen"..

Toevallig had ik dat gevonden via de search. Maar het onderwerp/subject leek me aan te geven dat het hier niet over ging.

[JayTaph]

Ja.. sorry..

(btw, Deze mag trouwens best naar /14 toe)