Detta är ett arbete jag skrev vt 2005.
Se hela arbetet i pdf-format.

Öppen källkod ur ett säkerhetsperspektiv

INLEDNING

Detta arbete handlar om på vilket sätt öppen källkod påverkar informationssäkerheten i ett system. Vilka är fördelarna och vilka är nackdelarna med öppen källkod jämfört med sluten källkod ur ett säkerhetsperspektiv? Analysen är uppdelad i fyra delar där den första är en allmän diskussion kring säkerhet i öppen källkod. Denna del berör det som är gemensamt för de nästföljande uppdelningarna. De övriga delarna är fördjupningar i områdena nätverkssäkerhet, kryptering samt skadlig kod, och de tar upp säkerhetsperspektiv som är speciella för respektive område. Man ska dock tänka på att det är svårt att göra fullständiga uppdelningar mellan dessa områden eftersom gränserna är flytande och delarna hör ihop och många gånger överlappar varandra.

ANALYS

Allmänt

Vid första anblicken kan öppen källkod tyckas ha en stor nackdel vad gäller säkerheten. Att koden är öppen och tillgänglig gör ju att vem som helst kan söka i koden efter brister och programmeringsfel för att sedan utnyttja dessa. Sluten källkod känns däremot är på grund av sin otillgänglighet mer säker. TruSecure[1] gör jämförelsen att på samma sätt som en låst dörr avskräcker av potentiell inbrottstjuv och får den att välja ett lättare mål, på samma sätt avskräcker sluten kod många potentiella hackers. Att göra koden öppen skulle enbart inbjuda till nya attacker.

Sluten källkod innebär dock nödvändigtvis inte att koden är fullständigt oåtkomlig. TruSecure[1] påpekar vidare att det är vanligt att källkoden licenseras ut till andra, vilket gör den delvis öppen. Det är sedan inte säkert att de som innehar licensen klarar av att skydda källkoden. Jag tror att i princip så kommer koden förr eller senare att läcka ut på ett eller annat sätt. Antingen genom oförsiktig hantering, hacker-attacker, sabotage eller baklängeskompilering. Man ska också komma ihåg alla de programmerare och andra anställda inom organisationen som har tillgång till mer eller mindre stora delar av koden och som medvetet eller omedvetet kan läcka information om källkoden. På detta sätt anser jag att sluten källkod kan inge en falsk trygghet som kan leda till att koden skrivs på ett mer sårbart sätt än om det från början var givet att källkoden skulle publiceras. Programmerare lockas till att skriva säkerhetsapplikationer som grundar sig på hemlighållning istället för svårknäckbar kod. SIG Security[2] skriver:

"En grundregel är att [...] aldrig på något sätt förledas att tro att det går att uppnå någon långsiktig säkerhet genom att dölja hur något implementerats. [...] säkerhetsarbetet ska bedrivas på ett sådant sätt att all information skulle kunna komma i orätta händer och trots detta ska systemet fortfarande vara säkert. Man ska alltså kunna gå hem och sova även den dagen då någon publicerat allt på Internet"

Kanske kan det rentav ligga en säkerhetsfördel i själva idèn att publicera källkoden. Detta möjliggör nämligen för alla användare att inspektera koden, eller låta en expert göra det. Om någon brist upptäcks kan man snabbt göra någonting åt den, eftersom det även är tillåtet att ändra i koden. Om man inte har tillgång till källkoden är men helt enkelt utelämnad åt det företag som sålt applikationen och får lita på att deras programmerare upptäcker brister och rättar till dem genom att skicka ut patchar. Det kan betyda att, beroende på företagets ekonomi och organisation, samma programmerare som skrivit koden också kontrollerar den. Att det inte är ett speciellt bra sätt att upptäcka fel och brister på kan nog alla som någon gång har programmerat intyga; hur lätt det inte är att bli hemmablind! Dessutom påpekar Sourcefire[3] att när programmet väl släppts är det inte en så stor grupp som fortsätter kontrollera den gamla källkoden, utan de flesta programmerare har redan gått över till ett nytt projekt.

Anderson[4] skriver om en annan nackdel med att vara tvungen att förlita sig på företaget man köpt en programvara av, nämligen den att man inte kan vara säker på att de gör någonting åt fel och brister som upptäcks. Kanske tycker de att det försvagar deras förtroende att gång på gång skicka ut patchar när de tidigare lovade att deras programvara var fullständigt säker. De har helt enkelt mer att tjäna på att inte berätta om brister i programkoden eftersom ingen kan kritisera dem. Men trots allt tror jag att detta argument inte alltid håller eftersom ett säkerhetshål kan ge väldigt dålig publicitet om det upptäcks av någon utanför företaget eller, ännu värre, genom en uppmärksammad hacker-attack eller liknande. Dock beskiver Anderson[4] en rapport som visade att IBM tidigare (hur det är nu vet jag inte) endast åtgärdade ett fel när det blivit anmält åtta gånger. Helt klart är i alla fall att liknande problem inte kan uppstå vid användande av öppen källkod. Företaget som utvecklat programvaran har inte något att förlora på att avslöja och rätta till fel eftersom någon annan annars skulle påpeka felen. Och om företaget själva inte rättar till felen så finns det andra som gör det.

I en EU-rapport[5] konstateras att en fördel med öppen källkod är att utvecklingen inte är lika tidspressad som i fallet med sluten källkod där ett företag kan släppa en programvara trots att många buggar kvarstår bara för att respektera releasedatumet. TruSecure[1] understryker samma problem och berättar att den version av Windows 2000 som släpptes i februari (2000) innehöll mer än 63 000 kända fel, och av dessa var 28 000 sådana som var förmodade att kunna ställa till problem. Vidare menar de att programmerare som jobbar med öppen källkod ofta utvecklar mer eleganta lösningar eftersom alla kommer att kunna se deras kod och de inte vill skämmas över alltför många buggar.

När brister upptäcks åtgärdas de i regel snabbare när det handlar om öppen källkod menar TruSecure[1]. Programmerare värden över jobbar parallellt på problemet och tävlar mot varandra för att först komma på den bästa lösningen. I fallet med sluten källkod däremot är det få programmerare som har tillgång till koden och med färre resurser tar det naturligtvis längre tid att rätta till ett problem och under tiden kan bristerna utnyttjas.

Ju fler människor som undersöker en källkod, desto färre brister kan leva kvar gömd i koden. Schneier[6] menar att det enda sättet att få en riktigt säker applikation är att många undersöker koden flera gånger, från olika synvinklar, under ett lopp av flera år. Det bästa sättet att genomföra det måste ju vara att publicera källkoden. TruSecure[1] skriver om publicerad kod: "With few exceptions, bugs that occur in a given release do not remain undetected." Men tillgängligheten kan också leda till problem. Den betyder att de med mindre nobla avsikter också har fri tillgång till källkoden och kan söka igenom den efter brister som sedan kan utnyttjas. Andelen personer med ärliga avsikter som letar i koden måste ändå anses vara många gånger större och sannolikt bör brister som hittas av någon illasinnad även snart upptäckas av minst en, troligtvis flera, som rapporterar den. Men det är klart att det kan hända att någon illasinnad person upptäcker något som ingen annan kommer att upptäcka på ett tag, och när en programvara precis är släppt finns det alltid många säkerhetshål kvar i koden. Anderson[4] påpekar att en genomsnittlig användare inte nödvändigtvis studerar samma område i koden som en illasinnad. En användare undersöker och modifierar oftast endast de områden som han eller hon kommer i kontakt med i sin vanliga användning och det är kanske inte alls i de delarna som en illasinnad söker efter brister. Anderson[4] ger också en liknelse med Vilda Västern där banditerna kan koncentrera sig på att attackera vilken bank som helst i området medan sheriffens mannar måste försvara överallt eftersom de aldrig kan veta i förväg var attacken kommer.

Nätverkssäkerhet

Brister förekommer alltid kod, ingen är någonsin helt felfri. Ju mer kod desto större säkerhetsrisk utsätter man sig alltså för. Om man ska installera ett system med sluten källkod får man oftast färdiga programpaket och systemlösningar. Även om man kan kan välja till eller välja bort vissa delar så kan man bara anpassa installationen till en viss grad. Om man använder sig av öppen källkod däremot har man oftast större möjligheter att skräddarsy sitt system. Och inte nog med att man kan välja bort de program som är onödiga för sin verksamhet, man kan också gå in i programmen och ta bort onödiga programdelar som man inte behöver vilket betyder att man tar bort kod med möjliga buggar och på så sätt reducerar möjliga säkerhetsrisker. Möjligheterna att lägga till och anpassa säkerhetsmekanismer är också bättre med öppen källkod, vilket gör att man kan utforma sin säkerhetsarkitektur i systemet så att det passar för just sin verksamhet.

EU-rapporten[5] skriver:

"The main strength of open source software is that it is "constructed for interoperability" and "closely associated to open standards". OSS is considered to better respect standards because no proprietary standards are used to "protect" the vendor captive market"

Sourcefire[3] tar upp samma sak och konstaterar att företag som säljer program med sluten källkod på ett enkelt sätt kan få kunder att tvingas fortsätta köpa deras produkter genom att inte använda internationella standarder utan konstruera egna. Detta gör att man som kund kan tvingas välja en produkt som inte fullt når upp till den säkerhetnivå man vill ha, bara för att den är den enda tillgängliga som fungerar bra i det system man använder. Om man från början däremot har ett system baserat på öppen källkod har man lättare att välja det alternativ som når upp till just de speciella säkerhetskrav man ställer och inte tvingas välja produkt efter kompatibilitet.

Som tidigare nämnt tar det ofta längre tid från det att en bugg upptäcks till det att en patch skickas ut när det handlar om sluten källkod. Negativt i detta sammanhang är inte bara den genomsnittliga tiden noterar TruSecure[1]:

"when vulnerabilities are discovered in closed source code, there is no guarantee that patches will be created quickly because the relatively small group of programmers with source code access typically must prioritize their efforts to fix bugs in what the vendor determines to be order of importance."

Om man nu har oturen att råka ut för ett fel som få påverkas av måste man helt enkelt vänta på att problemet ska komma upp högre på prioritetsordningen och under tiden har man ett försvagat system. Om man istället hade haft ett system med öppen källkod hade detta inte varit något problem då man helt enkelt hade kunnat rätta till felet själv, låta någon annan göra det eller söka efter någon som redan skrivit en pach.

Kryptering

Inom kryptografin har ända sedan artonhundratalet Kerckhoffs princip varit en av de mest använda. Sing[7] formulerar den: "Ett kryptosystems säkerhet bör icke bero på hemlighållandet av krypteringsalgoritmen. Säkerheten beror endast av att nyckeln hålles hemlig." Därför borde öppen källkod vara något naturligt när det gäller kryptering. SIG Security[2] menar att det enda sättet att bygga ett bra krypteringssystem på är att konstruera det så säkert att det går att publicera hur det är uppbyggt. Schneier[6] går så långt att han säger att öppen källkod är nödvändigt inom kryptografin:

"In the cryptography world, we consider open source necessary for good security [...] The idea is simple: cryptography is hard to do right, and the only way to know if something was done right is to be able to examine it."

Vissa skulle kanske mena att hemlighållandet av de bakomliggande algoritmerna skulle förstärka säkerheten och inte tvärtom. Men det tar Schneier[6] avstånd ifrån och anser att om algoritmer är bra endast då de hålls hemliga är det inga bra algoritmer och konstaterar: "Once they have been made public, they have been broken." Det kan i och för sig dölja sig en mycket kraftfull algoritm bakom sluten källkod också, som skulle klara av att publiceras och ändå fortsätta vara säker, men hur ska man veta det när man inte får kontrollera källkoden?

Sourcefire[3] berättar om kryptografen Andrew Fernandes som i augusti 1999 följde releasen av NT4 Service Pack 5. Det var allmänt känt att Microsoft hade två dekrypteringsnycklar varav de uppenbarligen hade nytta av den ena själv. Fernandes råkade emellertid hitta variabelnamnet på den andra nyckeln, som en programmerare glömt att ta bort, vilket var NSAKEY. Microsoft dementerade att nyckeln skulle ha någonting med US National Security Agency, NSA, att göra och så är kanske inte heller fallet. Men möjligheten att gömma hemliga bakdörrar i sluten källkod finns och man kan aldrig helt göra sig fri från misstankarna om att de existerar. EU-rapporten[5] tar också fram detta som en fördel med öppen källkod: "OSS contains less "black boxes". [...] with OSS you will have no (or less) backdoor(s), no electronic spy that may be totally hidden somewhere in the software."

Skadlig kod

En duktig programmerare kan lätt lägga till skadlig kod i ett program med öppen källkod och sedan sprida denna vidare. Den skadliga koden kan dock också lätt upptäckas eftersom den inte kan gömmas, men innan någon gör det kan den naturligvis redan ha hunnit gjort skada. Detta är självklart en nackdel med öppen källkod. I program baserade på sluten källkod från välkända företag kan man nog (förhoppningsvis) räkna med att skadlig kod inte finns implementerad. Däremot i program med sluten källkod från mindre kända tillverkare finns risken att skadlig kod är implementerad, och på grund av den otillgängliga koden är det så svårt att ta reda på den saken. Ett exempel är Kazaa, ett fildelningsprogram som används bland annat för att söka upp musik och film på Internet. Kazaa innehåller dock spywareprogram som användaren får "på köpet" utan att veta om det. Men alla de som publicerar sin källkod har ju troligtvis inga hemligheter där och därför är dessa program mer säkra.

Som tidigare nämnt är en fördel med öppen källkod att man kan gå in i programmen och ta bort onödiga programdelar som man inte behöver och på så sätt reducera möjliga säkerhetsrisker. På detta sätt kan man kraftigt minska risken att drabbas av till exempel virus genom att bland annat ta bort funktioner som makron och mallar.

AVSLUTNING

I detta arbete har jag försökt reda ut de säkerhetsmässiga fördelarna och nackdelarna med öppen källkod i jämförelse med sluten källkod. Man bör vara införstådd med att ingen av dessa två är en helt felfri eller fullständigt säker metod utan båda två har både starka och svaga sidor. Det man får ta ställning till när det gäller öppen källkod är om öppenheten främst gagnar förövaren eller försvaret.

Jag tycker mig se att den främst gagnar försvaret. Fördelarna med öppen källkod överväger enligt min åsikt nackdelarna. Möjligheten att själv bestämma och kontrollera exakt vad som finns på ens dator är något som borde prioriteras högt. Även om man som vanlig användare kanske inte går in i källkoden så är vetskapen om att man faktiskt kan göra det om man vill, och att det finns andra som har gjort det, en vinning.

De allra flesta skulle nog hålla med om att ju fler människor som kontrollerar en kod, desto säkrare blir den. Då många människor har möjlighet att undersöka källkoden kan rent av inte en dålig programdesign överleva. TruSecure[1] gör uppskattningen att ungefär 15 miljoner människor har "rört" vid koden till Linux. Hur många programmerare ett företag än anställer kan de aldrig konkurrera med den siffran.

Självklart finns det många andra aspekter än säkerheten i debatten om öppen källkod som också borde lyftas fram, men det är en helt annan diskussion...

REFERENSER

[1]TruSecure, Open Source Security: A Look at the Security Benefits of Source Code Access, TruSecure Corporation 2001-08

[2]SIG Security, Säkerhetsarkitekturer, SIG Security, Studentlitteratur, Lund 1999

[3]Sourcefire, The Strengths and Weaknesses of Open Source Software And Its Role in the Security Model, Sourcefire 2002-06

[4]Anderson R., Security in Open versus Closed Systems - The Dance of Boltzmann, Coase and Moore, Cambridge University 2002

[5]IDA (Interchange of Data between Administrations), Study into the use of Open Source Software in the Public Sector - Part 3 - The Open Source Market Structure, IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Business and Citizens) and the European Commission 2001-06

[6]Schneier B., Crypto-Gram Newsletter, 1999-09-15 (www.schneier.com/crypto-gram-9909.html)

[7]Sing S., Kodboken, Norstedts Förlag, Stockholm 2000


toppen på sidan tillbaka till förstasidan [Teknik och data] tillbaka till förstasidan [Saras hemsida]

Valid HTML 4.01!