Seminariekväll om kodanalys och -granskning: Referat del 2

James Dickson från Simovits Consulting hade kvällens andra presentation. Ämnet var manuell kodgranskning. Efter en lätt självironisk start så hakade åhörarna på presentatörens flöde av insikter, verklighetsutblickar och småskämt på egen bekostnad. En egen stil helt enkelt. Trevligt.

Vem beställer manuell kodgranskning?
Drivande för att utvärdera säkerheten i egenutvecklade system är antingen en säkerhetskritisk bransch där organisationen är van att hantera risk eller compliance-krav såsom PCI DSS. De flesta kunder som har köpt granskning av James har redan gjort automatiska tester i stil med vad Fortify erbjuder. Man tar helst inte in en manuell granskare utan att ha gjort hemläxan.

Hur analyserar man?
Hur analyserar man? Ingen svart magi här. Det handlar om läsande av kod, checklistor och fokus på "dyra" dataflöden såsom pengar, krediter, personuppgifter och filer. Det vill säga sådan data som är kringgärdade säkerhetskrav. Man spanar efter rollbacks, bruten atomicitet, trasig felhantering och logiska fel. Det känns alltid viktigt att åstadkomma något så om koden ser fläckfri ut kan man alltid granska dokumentationen. Där finns dessutom många ledtrådar till var buggar lurar -- kommentarer som innehåller TODO, wtf och hmm är varningstecken.

För att göra en bra analys kan man behöva tillgång till andra specialister att bolla med. I James fall har han tillgång till folk som är duktiga på kryptografi och nätverkskonfiguration. Så fort han stöter på något skumt inom de områdena så kan han kolla med kollegorna back-office.

Vad hittar man?
De flesta säkerhetsbrister man hittar är osofistikerade. Man har försökt säkra upp genom gömda filer, man har lagt säkerhetskontroller hos klienten, otillåtna funktioner skyddas bara med hjälp av inaktiverade knappar som enkelt kan aktiveras, och i webbapplikationer ser man ofta ett .Net-viewstate som en attackerare kan koda av, ändra och koda om utan att servern reagerar. James har ett par egenutvecklade verktyg han kör för att testa de här sakerna.

Lite mer avancerade fel kan röra sig om att autentisering glöms bort på vissa sidor/funktioner i en webbapp, att sekvensnummer eller slumpfrön inte har tillräcklig entropi, brister i fel- eller trådhantering, eller obsolet kryptering som SSL 2.0 eller LM-hashar.

Svårast är att hitta deadlocks och race conditions och där är race conditions så klart allvarligast.

Vad blir reaktionen hos utvecklarna?
Hur reagerar utvecklarna som granskas? Kunderna kommer från två kategorier -- de som kan säkerhet och arbetar med det och de som ignorerat säkerhet och nu måste granska sin kod pga compliance. De förstnämnda blir nästan alltid glada för det man hittar -- de vill höja säkerheten. De sistnämda blir oftare arga och en granskning kan leda till dålig stämning i teamet.

James har inte mött på överdrivet mycket politik, dvs där utfallet av granskningen styrts av vem och vilka man "får" kritisera. Ofta har uppdraget beställts av någon högre upp och där är det sanningen som gäller eftersom de inte har något personligt att vinna eller förlora.

Bra trender
James ser vissa positiva trender. Utvecklare har fått både bättre verktyg och ökad kunskap om hur man bygger säkra system. Kompilatorer gör kollar eller bygger in skydd (t ex kanarievärden för att skydda mot vissa buffer overflows), utvecklingsmiljöerna ger allmänt stöd för högre kvalitet och nya språk har färre säkerhetsproblem. Fler och fler utvecklare intresserar sig också för säkerhet.

Dåliga trender
Trots många positiva tecken så tyckte sig James att bristerna kommer att öka. Komplexitetsnivån på applikationer stiger ständigt, applikationer består av ett stort antal subkomponenter som var och en måste konfigureras korrekt och fungera bra ihop, och många tekniker som språk och ramverk används hej vilt och i hårresande kombinationer. I den soppan så blir ofta kvaliteten bristande.

Fler men klurigare brister ger fortsatt flöde av granskningsuppdrag men med färre quick wins.

Våra kommentarer
[Martin]
Själv kan jag hålla med om komplexiteten i floran av tekniker; många verktyg nuförtiden blir alltmer specialiserade; Cherokee, Lighttpd och Nginx är tre exempel på duktigt optimerade webservrar som slåss om förstaplatsen. Det är helt klart en större utmaning för en säkerhetsgranskare ju fler nischade verktyg som används i systemet. Denna komplexitetsökning kan dock vara klart värd att ta -- en one-size-fits-all-monster som Apache är inte världens säkraste programvara heller, vilket James gärna påpekade.

[John]
Jag har stött på rätt mycket politik när jag har testat eller utvärderat system. I ett fall har jag tvingats omformulera kritik till utvecklingsförslag. I ett fall har jag tvingats signera godkända testprotokoll trots att felen inte var åtgärdade än -- "Vi lovar att fixa det sen. Men vi måste ha din signatur på protokollet nu, annars kan vi inte leverera till slutkund." Slutkunden var i tredje världen och hade själva godkänt specar som jag hittade allvarliga fel i. Att ta upp det skulle äventyra hela leveransen eftersom folk skulle tappa ansiktet och så vidare. Sättet att lösa det på var att "upptäcka" felen efter leverans och fixa på plats. Då blev alla nöjda.

Att James inte mött på så mycket politik och bråk tyder på en ökad professionalism bland dem som utvecklar system. Bra.

Jag tror precis som James att komplexiteten är en av de avgörande faktorerna. Men jag sällar mig inte till skaran som tycker att vi ska ändra något där. Vi vill ha mer komplexa it-system. Inte för komplexitetens egen skull utan för att vi vill ha mer it och mer avancerad it. För att klara att bygga större och mer komplexa system så måste fler och fler delar i utvecklingskedjan kvalitetssäkras. Det sker med alla ingenjörsdiscipliner och kommer även ske med vår. Programmeringsspråk, kunskap, metodik, kodanalys och testning måste möta upp komplexitetsutmaningen. Annars får vi osäkra, ineffektiva, oförvaltningsbara system.

Vänta nu -- är det inte osäkra, ineffektiva, oförvaltningsbara system vi har idag? ;)