Beveiligingsindustrie wijst 25 gevaarlijkste programmeerfouten aan

Wat wordt er in het artikel gezegd over certificaten en browsers die daar rekening mee gaan houden?

De bedoeling van die certificaten is naar mijn inziens om programmeurs veilig te leren programmeren en ze vooral op de hoogte brengen van de veiligheid problemen. Het probleem nu is dat heel veel programmeurs niet op de hoogte zijn van de fouten die ze maken en al helemaal niet weten hoe ze dan wel veilig moeten programmeren. Een groot probleem bijv. op websites zijn onder andere XSS en CSRF exploits. Deze problemen zijn erg goed gedocumenteerd en staat ook keurig beschreven hoe je het kan voorkomen/oplossen. Alleen niemand lijkt ze te lezen.

Helaas zijn deze veiligheids problemen niet bekend bij de meeste programmeurs en het zou natuurlijk prachtig zijn als je het door middel van een certificaat onder de aandacht kan brengen met als resultaat veel veiligere software

[Reactie gewijzigd door maxjuh op dinsdag 13 januari 2009 21:38]

Ik weet niet of je het beseft, maar Microsoft gebruikt al een aantal jaar een secure development process om fouten zoals de hierboven vermelde 25 te voorkomen. Een secure development process is een gewoon development process (bv. RUP) uitgebreid met een aantal security related activities (zoals threat modeling) .

Ik zou een buffer overflow toch echt als een software probleem beschrijven. Je software schrijft data over de grens heen waar die data zou mogen staan, waardoor andere dingen overschreven worden die naast de buffer in het geheugen zitten.

Op die manier kun je een applicatie in een onbepaalde staat brengen en laten crashen, terwijl mogelijkerwijs de verbinding nog open is. Dit is een van de meest gebruikte exploits.

Er bestaan twee plaatsen waar de programmeur zijn variabelen kan stokkeren: de heap of de stack.

De heap wordt gebruikt om dynamisch geheugen te alloceren. Stel ik heb een instantie van de klasse CMyBigClass nodig, die ik elders ga gebruiken in één of andere berekening, dan zou ik dus in C++ het volgende doen: CMyBigClass* pMyBigClass = new CMyBigClass(...);. Het voordeel van de heap is dat ik dynamisch geheugen kan alloceren. Dus ik moet niet op voorhand weten hoeveel geheugen ik nodig heb. Het nadeel is weer dat ik zelf verantwoordelijk ben voor het vrijgeven van het geheugen. Maar de meer recentere programmeertalen (zoals java, c#, ...) hebben tegenwoordig allemaal garbage collectors, dus geen memory leaks meer.

De stack wordt gebruikt om variabelen in een scope aan te maken. Een scope is een déél van een functie dat een begin en een eindpunt heeft. In C(++) gebruikt men hiervoor de accolades. bv.
void foo()
{
CMyBigClass MyBigClass(...);
...
while (...)
{
CMySecondBigClass MySecondBigClass(...);
...
}
}
Het eerste object MyBigClass wordt op de stack aangemaakt. Van zodra de functie foo klaar is, wordt dit object gedestroyed en van de stack gesmeten (stack unwinding). Het MySecondBigClass wordt pas op de stack geplaatst van zodra men het while statement binnengaat. De stack werkt dus volgens een LIFO systeem (Last In First Out). Als wij in de while onmiddellijk de functie verlaten, dan zal eerst MySecondBigClass object worden gedestroyed (destructor) en vervolgens MyBigClass. MAAR!!! De stack wordt dus ook gebruikt door de CPU om terug te gaan naar de plaats waar foo oorspronkelijk werd opgeroepen. Als de CPU foo wilt uitvoeren, dan zal de CPU eerst de IP (Instruction Pointer) van het adres na de call op de stack plaatsen. Vervolgens zal de CPU foo uitvoeren. Uiteindelijk zal de functie foo worden afgesloten met een ret (return) instructie. Deze zal het adres dat momenteel op de stack staat (SP of stackpointer) naar de IP zetten. En vervolgens gaat de CPU weer voort met de opdracht die na 'call foo' stond.

Er komt nog iets meer bijkijken, maar hier komt het op neer. Om terug te gaan naar je opmerking. Het is dus géén fout in het OS, maar gewoon hoe een CPU werkt. HEt gevaar bestaat er dus in dat je in de functie foo de stack kan manipuleren door een bufferoverflow, omdat je dan de stack gaat wijzigen en dus ook het return adres. Op die manier kan je dus na het verlaten van de functie foo, ervoor zorgen dat de CPU plots andere code gaat uitvoeren.