Ik programmeer als hobby het een en ander en nu heb ik een
aantal vraagjes over buffer overflows waarvan ik hoop dat
iemand daar antwoord op weet.

1) Om buffer overflows te voorkomen gooi ik alles (behalve
ints, chars, enz) op de heap. Van te voren de grootte
bepalen en dit met malloc() aanmaken. Ik gebruik dus nooit
iets van "char bla[x]". Is dit een goede methode om buffer
overflows tegen te gaan?
2) Mocht ik toch per ongeluk een te kleine buffer alloceren
en dus buiten de buffer schrijven, is dit dan te expoit-en?
3) Waarom verbieden OS'en niet simpel het uitvoeren van code
in de stack-space. Of is dit niet zo simpel als ik denk?

1) alles op de heap gooien is onzinnig.. dat is
exploitable.. zowel met dlmalloc, sysv malloc als phkmalloc

2) ja dus

3) dat kan voor Linux met patches als PaX / grsec

Je moet je simpelweg aanleren om ten allen tijde je input te
controleren.. nooit meer dan een x aantal bytes copieren als
je x gealloceerd hebt. Dus strncpy gebruiken ipv strcpy etc etc.

de stack non executable maken heeft absoluut geen zin, zolang andere
segmenten nog executable zijn. En dan kan je nog een return-into-libc/plt
attack doen. PaX probeert dit te voorkomen door bijv. de shared library base
address te randomizen, maar als de attacker een info leak kan triggeren,
(dus op een of andere manier in staat is om op bepaalde addressen te
kijken) wint hij als nog wel :)

PaX stopt iig wel de meeste standaard exploits.

Gnepknurk...

Overweeg eens C++ te gebruiken.

Je hoeft niet meteen in hogere sferen in classes en
templates te gaan
denken, maar kunt prima gewone C code combineren met een string
class. Op plaatsen waar geheugen en performance kritische
factoren
zijn (komt zelden voor, tenzij je bijv. een driver schrijft)
kun je terugvallen
op platte C code.

Overigens is het soms verre van ideaal als je (ongemerkt) op
tig plaatsen
strlen() aan het draaien bent; zo'n string class kan jou en
de CPU veel
werk uit handen nemen (opgemerkt moet worden dat i86 en
compatible
CPU's bloedsnelle ingebouwde string functies hebben, bij
korte strings
kunnen deze sneller zijn dan pointer dereferences in structs
en allerlei
heap management functies). De kunst is leren begrijpen wat
er achter
de schermen gebeurt. Dit staat zelden in boeken, je leert
het hands-on
met de low-level debugger. Neem de tijd en verdiep je er in.

Hou er ook rekening mee dat classes geen wondermiddel zijn; daar
komen ook grenzen in voor (die niet altijd even duidelijk
zijn), en je zult
alle denkbare fouten op een juiste manier moeten afvangen.
Dit is waar
goede programmeurs zich onderscheiden van mindere, maar dat
geldt
voor elke programmeertaal.

Sommigen zullen de belachelijke error "Disk full" van MS
Word kennen,
die je kunt krijgen als het document in het geheugen corrupt
geraakt is,
en Word daarom niet kan saven. Exception handling op het laagste
niveau...

EvS

Beste redactie/webmaster, waar is de preview?

Dit ziet er niet uit

EvS