90 procent van de programma's gedekt door SDL ?
Vallen windows en IE zeker onder die resterende 10 procent !

Betekent dit dat microsoft hiervoor geen aandacht aan
security besteedde gedurende de ontwerp-fase? Niet dat dat
me verrast hoor :-)

Dat is natuurlijk ook een manier om te brengen dat je
eigenlijk jarenlang op onverantwoordelijke wijze producten
gemaakt hebt en in de markt hebt gezet. Ah well.. marketing..

Iedereen die wel eens een CGI-script voor een webserver
heeft geschreven en zich een beetje verdiept heeft in
veiligheid weet dat het veilig schrijven een gigantische
klus is. Simpel voorbeeld;

Variabele $file kan ingevoerd worden op een pagina en wordt
gebruikt in: system("ls $file");
Als de gebruiker nu eens "help.txt; rm -rf /" invoerd heb je
al een probleem. Gaan we controleren op meta-characters
krijgen we;

if ($file =~ /[;~[]{}&'"]/)
exit;
else
system ("ls $file");

Echter is het nog steeds mogelijk om via code een
meta-character in de system-aanroep te krijgen. Uiteindelijk
wordt het dus;

system 'wc', '-c', $file;

Ik hoop dat het nu een beetje duidlijk is dat ECHT veilig
programmeren een drama is. Je kan tenslotte niet alles overzien.

"
Iedereen die wel eens een CGI-script voor een webserver
heeft geschreven en zich een beetje verdiept heeft in
veiligheid weet dat het veilig schrijven een gigantische
klus is. Simpel voorbeeld;

Variabele $file kan ingevoerd worden op een pagina en wordt
gebruikt in: system("ls $file");
Als de gebruiker nu eens "help.txt; rm -rf /" invoerd heb je
al een probleem. Gaan we controleren op meta-characters
krijgen we;

if ($file =~ /[;~[]{}&'"]/)
exit;
else
system ("ls $file");

Echter is het nog steeds mogelijk om via code een
meta-character in de system-aanroep te krijgen. Uiteindelijk
wordt het dus;

system 'wc', '-c', $file;

Ik hoop dat het nu een beetje duidlijk is dat ECHT veilig
programmeren een drama is. Je kan tenslotte niet alles overzien.

"

Het probleem ligt in de programmeertalen van tegenwoordig.
Je gebruikt lib functies om het te vergemakkelijken.
Wat betreft de commando's in zo'n programmeertaal ?
Maar wat als hierin niet wordt gecontroleerd op de voorwaarden
zoals je bijvoorbeeld boven aan geeft ?
Zelf schrijven gaat niet want daar krijg je de tijd niet voor. Of de
kennis hoe het onderliggende systeem werkt is niet aanwezig om
diverse redenen.

Ik denk dat dat het probleem in de flexibiliteit ligt. Om soepel te
zijn kan een gegeven programmeertaal een hoop. Om veiligheid
te bieden kan een programmeertaal weinig. 2 Door meer
personen al opgemerkte onverenigbare situaties zolang het
fundament niet vanaf stap 1 goed doordacht is.

Dat microsoft dit nu inziet is mooi, maar alles uitsluiten, ik denk
het niet. Je kan niet alles overzien, maar je kan wel degelijk van
tevoren een hoop problemen voorkomen en vervelende situaties
uitsluiten. Dat heet visie. De visie van microsoft ligt meer op het
economische vlak en dat doen ze dan ook verdraaid goed.

ALG

Het betekent m.i. dat men eerst de code schreef om de
dead-line te halen en als er nog tijd over was ook nog even
naar de bugs zocht.
Het op tijd uitbrengen van software is goed voor de
aandelen, het vervolgens nog jaren moeten plakken en
pleisteren om het veilig te krijgen heeft blijkbaar geen
effect op die aandelen, terwijl het voor de leverancier
enorm kostbaar kan zijn.

Probleem lijkt er een beetje op dat je managers eigenlijk
niet wijs kunt maken dat dingen nou eenmaal langer duren (=
duurder worden), als je ze goed wilt doen; "daar is geen
budget voor".

We worden dus uiteindelijk allemaal geregeerd door mensen
die op korte termijn winst willen.

En dat is meer dan jammer.

veilig programmeren begint aan de basis nl. ontwerpen voor
veiligheid. Vaak is veiligheid omgekeerd evenredig met
productiviteit. Het zou handig zijn als het OS M$ van de
grond af aan opnieuw wordt ontworpen en geschreven met
veiligheid in het achterhoofd, ipv security-patch na
security-patch uit te moeten geven.

Nu maar hopen dat Longhorn vanaf de grond af aan veilig is
ontworpen en gebouwd