Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Knut Yrvin – 23.03.2007 Sikkerhet gjennom uoversiktlighet eller oversiktlighet? Kilder: David A. Wheeler:dwheeler «at» dwheeler.com Theo de Raadt:deraadt.

Liknende presentasjoner


Presentasjon om: "Knut Yrvin – 23.03.2007 Sikkerhet gjennom uoversiktlighet eller oversiktlighet? Kilder: David A. Wheeler:dwheeler «at» dwheeler.com Theo de Raadt:deraadt."— Utskrift av presentasjonen:

1 Knut Yrvin – Sikkerhet gjennom uoversiktlighet eller oversiktlighet? Kilder: David A. Wheeler:dwheeler «at» dwheeler.com Theo de Raadt:deraadt «at» openbsd.org

2 KNUT YRVIN Televerket teleteknisk assistent – 1986 Høgskoleingeniør elektronikk – 1992 Planlegger transmisjon Hovedfag systemutvikling – 2000 Verdipapirsentralen, Objectware Startet Skolelinux, prosjektleder – 2001 Trolltech – 2006 Direktør utviklersamfunn

3 PLAN 1Grunnleggende om sikkerhet i programvare 2Tiltak som ikke virker 3Eksempler på sårbarhet 4Sikkerhet i fri og produsenteid programvare 5Spørsmål og svar

4 ALL PROGRAMVARE HAR FEIL Buffer Overflow Ekstra tilganger til programvaren Åpner for (automatisk) installasjon og kjøring av usikret programvare Uautorisert utnytting av grensesnitt (ABI) Enkelte feil kan utnyttes

5 EKSTREME PÅSTANDER Fri programvare er alltid mer sikkert Produsenteid programvare er alltid mer sikkert Virkeligheten: Verken fri eller produsenteid programvare er alltid sikrere En del fri programvare er sikrere enn tilsvarende produsenteid programvare

6 USTABIL PROGRAMVARE Firefox krasjer ofte (Internet Explorer oftere) Blander data og kjørekode i minnet. Enklere å kjøre angrep med utnyttelse av kjøreminnet E-postklienter som tillater automatisk kjøring av nedlastet programvare (Outlook) Designvalg: åpner opp for kjøring av skadelig programvare (julekort hos IBM i 1987) Windows er vanligvis påskrudd med root- privilegier til alle. Skrus root-privilegiene av får man redusert brukervennlighet Designvalg: favoriserer superbrukertilgang, åpner opp for uheldig bruk og skadelig programvare åpner for flere problemer med sikkerheten

7 ET PAR MORSOMME HISTORIER - I Romerriket benyttet ROT-13 som kryptering Flytter alle bokstavene i alfabetet 13 plasser 1. Digitale RestriksjonsMekanismer Brukt av Cæsar for å hindre at fienden leser meldinger om kureren blir tatt til fange Hva skjer når en general som kjenner ROT-13 bytter side i konflikten? Nøkkelen for dekoding følger med på alle DVD-er Eksempel: Flytting tre plasser

8 ET PAR MORSOMME HISTORIER - II Mange IT-avdelinger gjør en hel del arbeide med å låse ned dataprogrammene Det installeres virusfjerner Innlogging med fingeravtrykk eller elektroniske nøkler Men hva er dette verdt når Avlesing av dataskjermer via radiatorer Skjermstråling kan fanges opp av andre uten passord, fingeravtrykk og nedlåsing av program. De ser allikevel alt du gjør.

9 BRUKER VI RIKTIG MATEMATIKK? På 1930-tallet beregnet en ekspert på aerodynamikk at humlen var for baktung til å kunne fly. Senere har det vist seg at feilslutningen var bygget på en antagelse om at humlen skulle fly som et fly. Men humlen flyr som et helikopter. Modellene som ble brukt for å beskrive fenomenet, var feil. I 1936 viste Alan Turing: at man ikke kan lage en generell oppskrift som avgjør om et program stopper gitt alle mulig program med tilhørende inndata. Feil metoder og matematikk hjelper lite når man skal styrke sikkerheten Hvilke forutsetninger velger vi?

10 BRUKER VI RIKTIG STATISTIKK? I 2003 delte Microsoft ut et notat som viste 34 sikkerhetsvarsler på Windows Debian 3.0 hadde 124 varsler. Hvilke forutsetninger velger vi? Hva mangler her?

11 Microsoft har utelatt antall programmer Windows 2000 har rundt regnet 125 programmer. Debian 3.0 har 8710 programmer. Hvilke forutsetninger velger vi? Hva mangler her?

12 HVA ER VIKTIG? Antall varsler sier lite eller ingen ting om hvilke programmer som er i faktisk bruk Programmer dere bruker kan være sikkert, eller det er har sikkerhetsbrist man ikke har oppdaget Statistikk er lite relevant når man må rette feil Hvilke forutsetninger velger vi? Er det oppdaget en sikkerhetsbrist er man opptatt av å rette på dette

13 EKSEMPEL PÅ SÅRBARHET Eksempel: 8-byte langt strengbuffer A – bare nuller '0' 2-byte langt integer i B – tallet 3 BUFFER OVERFLOW Programmet lagrer “excessive” i A, etterfulgt av 0, som indikerer enden av strengen Uten å sjekke lengden på strengen blir B overskrevet. Verdien av 'e' og 0 blir 25856

14 STAKK-BASERT UTNYTTELSE Ved overskriving av lokale variable nær stakken (program-minnet), kan en angriper endre programmet Retur-adresse i kjøreminnet overskrives. Straks en funksjon returnerer, fortsetter kjøring fra adressen angriper har lagt inn. Det kan bety at datamaskinen fortsetter programkjøring fra kode som f.eks. ligger i inndata-bufferet. Kode angirper har plassert der. Manipulering av program-minnet

15 PÅLITELIGHET Fuzzy-testing på operativsystem [U Wisconsin] Produsenteid UNIX: 23-28% ustabilitet Linux 9% ustabilitet, GNU-verktøy 6% ustabilitet Windows 100% ustabilitet, 45% ved forbud mot enkelte Win32-kall GNU/Linux versus NT [ZDNet] NT krasjer i snitt hver sjette uke. GNU/Linux aldri Microsoft Internet Information Server (web-server) har to ganger mer nedetid enn Apache Fuzzy-studier: vilkårlige inndata til systemet

16 SIKKERHET I FRI PROGRAMVARE - I Siste halvdel 2006: Internet Explorer 54 sårbarheter, Mozilla 40 sårbarheter. Maks 78 dager før sårbarhet er rettet i Internet Explorer, Mozilla 33 dager. Sårbarheten fikses vanligvis 5x raskest i Mozilla. Delvis skyldes den hurtige feilrettingen i Mozilla at sikkerhetsfikser lages av frivillige. Premie på $500 Vellykket innbrudd på nettverksystem: Først etter 3 måneder med Linux. Timer med Windows (Honeynet.org, Doc 2004) J.S. Wurzler hacker-forsikring koster 5-15% mer har man Windows enn for Unix og Linux.

17 SIKKERHET I FRI PROGRAMVARE - II Virus er primært et Windows-fenomen (tall fra 2004) 60,000 på Windows, 40 på Mac, 5 på komersielle UNIX-system, 40 for Linux 91% av bredbåndsbrukere har spionprogrammer på hjemme-pc-en (Nasjonal sikkerhetsallianse, mai 2003). ~0% på fri programvare

18 ER FRI PROGRAMVARE ALLTID SIKRERE? Nei: Sendmail, bind 4 Må vurderes fra tilfelle til tilfelle Men det er prinsipper som gir fri programvare potensielle sikkerhetsfordeler

19 ÅPENT DESIGN: GRUNNLEGGENDE Saltzer & Schroeder ( ) – Åpent design prinsipp Beskyttelsesmekanismen må ikke avhenge av angriperens uvitenhet Fri programvare etterlever dette prinsippet Sikkerhetseksperter belyser dette Bruce Schneier: “forutsett fri programvare for alt relatert til sikkerhet” Vincent Rijmen (AES): “tvinger folk å skrive mer klar kode i henhold til standarder” Whitfield Diffie: “det er urealistisk å basere sikkerhet på hemmelighold”

20 PROBLEMER MED Å SKJULE KILDEKODEN Forutsetter at kildekoden er hemmelig Det finnes legitime måter å få tak i koden Dynamiske angrep trenger ikke kildekode eller binærfiler Observasjon av inn- og utdata er nok til å angripe Angrep kan gjøres med mønstergjenkjenning mot programmer (binærfiler) – f.eks. Fuzzy testing Kildekode kan gjenskapes ved dekompilere binærkode. Dette gir kildekode som forenkler søk etter sårbarhet Hemmeligholdelse hindrer de som vil hjelpe uten å stoppe angripere Hemmelighold av kildekode hindrer ikke angrep

21 PROBLEMER MED Å SKJULE KILDEKODEN Å holde kildekode hemmelig forsinker responsen ved sårbarhet Hemmelighold av sårbarhet hindrer ikke angrep Sårbarhet er tidsinnstilte bomber som mest sannsynlig blir gjenoppdaget av angriper Enkelt hemmelighold varer kanskje dager, ikke måneder og år Konsekvenser

22 VIRKER UOVERSIKTLIGHET? Sikkerhet gjennom uoversiktlighet kan virke hvis: Når det å holde på hemmeligheter gir en reell økning av sikkerhet Må holde kritisk informasjon fullstendig hemmelig For å få dette til Hold all kildekode hemmelig for alle andre. Aldri Selg eller avslør koden til mange. Hold binærutgaven av programmene hemmelig. Selg aldri koden til andre Bruk beskyttelsesmekanismer for programvaren Fjern programvaren før systemet eksporteres Ikke tillat inn- og utdata til programmet for noen andre Ingen tilgang til Internett og lignende nett

23 UBRUKELIG I DET FLESTE TILFELLER! Sikkerhet gjennom uoversiktlighet virker ikke for hyllevare-programmer Produsenteid programvare kan være sikker – men ikke gjennom uoversiktlighet

24 Forbetingelser for fri programvare-sikkerhet Utviklere og inspektører må ha sikkerhetskunnskap Kunnskap er mer viktig enn lisenser Utviklere må faktisk gjøre kodeinspeksjon Detter er mindre sannsynlighet med programmer som sjelden brukes, har få utviklere, eller bruker sære programmeringsspråk Flere bidragsytere, flere gjennomganger Blir programvaren egentlig utviklet av et utviklersamfunn? Sårbarhet må fikses Bedre å fikse før utrulling. Er programmene distribuert og installert må også feilrettingene rulles ut. Utilsiktet sårbarhet

25 BLIR FRI PROGRAMVARE GRANSKET? De fleste store fri programvare-prosjekt har kodegranskning Mozila: program for sikkerhetsfiksing ($500) Linux: hierarkisk gjennomgang Kodegransking av andre enn hovedutviklere som utviklingsmetode: OpenBSD Debian-audit Statisk analyse fra verktøyselskap som bruker fri programvare Feil- og sikkerhetsmeldinger fra andre (bugtrack etc.) Ja

26 EVALUERING AV FRI PROGRAMVARE Identifiser sikkerhetskravene først Se etter bevis på hjemmesidene til fri programvareprosjekt dokumentasjon, diskuteres sikkerhet? prosesser for å rapportere sårbarhet digitale signaturer for versjoner av programvaren et aktivt utviklersamfunn Bruk andre kilder for informasjon Sikkerhetsvarsler fra myndigheter Rykte (f.eks. OpenBSD) Se etter bevis

27 FORDEL MED PRODUSENTEID PROGRAM - I Erfarne utviklere som forstår sikkerhet leverer bedre resultat Erfaring og kunnskap er avgjørende, men... utviklere av fri programvare er ofte erfarne og kunnskapsrike (11 års erfaring når man er 30) – ofte samme folk Utviklere av produsenteid programvare gir høyre kvalitet. Dette er spekulativt fordi: Fri programvare har ofte høy pålitelighet og sikkerhet Tempo i markedet hindrer utviklere å rapporterer feil eller svakheter i produsenteid programvare ikke nødvendigvis

28 FORDEL MED PRODUSENTEID PROGRAM - II Ikke garantert at fri programvare sjekkes Sant nok! Fri programvare som ikke inspiseres kan være svært så usikker Også sant for produsenteid programvare som sjelden inspiseres. Har dere sjekket programvaren dere bruker? Kan saksøke produsenter ved sårbarhet eller utilstrekkelighet Tullball. Produsenteid programlisenser garanterer ikke for kvaliteten i den hensikt å unngå rettslig ansvar. Dessuten vil du ha fikset programvaren framfor kostbare rettsaker ikke nødvendigvis

29 EVALUERING AV FRI PROGRAMVARE Identifiser sikkerhetskravene først Se etter bevis på hjemmesidene til fri programvareprosjekt dokumentasjon, diskuteres sikkerhet? prosesser for å rapportere sårbarhet digitale signaturer for versjoner av programvaren et aktivt utviklersamfunn Bruk andre kilder for informasjon Sikkerhetsvarsler fra myndigheter Rykte (f.eks. OpenBSD som bare har hatt et kjent sikkerhetshull) Se etter bevis

30 Typisk fri programvare-utvikling i fri programvare Utvikler Pålitelig kodelager Pålitelig utvikler Bruker Distributø r Utviklersamfun n Forbedringer (kildekode) evaluering: bruker som utvikler Kildekod e Bruk er ofte uten lisenskostnader Betaler for trening og støtte Selv ansvarlig for ny funksjonalitet og evaluering av behov Aktive utviklersamfunn, stiftelser og firma -> konsortium

31 US DEPARTMENT OF DEFENCE - I That free/open source software (FOSS) plays a more critical role in the Department of Defence than has generally been recognized. FOSS applications are most important in four broad areas: Infrastructure Support, Software Development, Security, and Research. One unexpected result was the degree to which Security depends on FOSS.... Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense

32 US DEPARTMENT OF DEFENCE - II... Banning FOSS would remove certain types of infrastructure components (e.g., OpenBSD) that currently help support network security. It would also limit DoD access to — and overall expertise in — the use of powerful FOSS analysis and detection applications that hostile groups could use to help stage cyberattacks.... Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense

33 US DEPARTMENT OF DEFENCE - III... Finally, it would remove the demonstrated ability of FOSS applications to be updated rapidly in response to new types of cyberattack. Taken together, these factors imply that banning FOSS would have immediate, broad, and strongly negative impacts on the ability of many sensitive and security-focused DoD groups to defend against cyberattacks. Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense

34 OPPSUMMERING Hverken fri eller produsenteid programvare er alltid sikrere Men det er mange situasjoner hvor fri programvare er sikrere Fri programvare er industrielt og brukes over alt, også på kontoret 71% av verdens utviklere bruker fri programvare (IDC) Bedriftspolitikk må ikke hindre eller gjøre det vanskelig å bruke fri programvare En utfordring. Endrer antagelser om hvordan programvare skaffes Finnes løsninger med dobbelt lisens Ta med fri programvare ved anskaffelse, evaluer! Er fri programvare ekskludert?

35 SPØRSMÅL og SVAR 35

36 SPØRSMÅL og SVAR 36

37 EKSEMPLER: SKADELIGE KODE Linux kernel-angrep – kode i versjonssystemet Forsøkte å hjemme = framfor == Feilet (kode-håndtering, review, konvensjoner) Debian-angrep Stoppet, gjenskapt via eksterne kopier Borland InterBase/Firebird bakdør Bruker: politicallly, passord: correct Gjemt i 7 år i produsenteid programvare Frigitt som fri programvare: bakdør funnet etter 5 måneder Fri programvare

38 EKSEMPLER: SKADELIGE KODE Angrep på distibusjonssystemet Mange kopier, sammenlignende prosesser Forsterkede programlager Digital signatur ved distribusjon Håndtering av skadelige utviklere man stoler på Finn ut hvem som programmerer ditt system (alltid) Håndter skadelige utviklere man ikke stoler på Forsterket inspeksjonprosess Oppdateringspross når sårbarheter blir funnet Produsenteid programvare

39 SKADELIGE ANGREPSSTRATEGIER - I Angrep på distribusjon Produsenter kan koble fra Internett Dette er upraktisk Fri programvare kan enklere gjenskapes grunnet mange kopier Skadelige utviklere Fri programvare noe bedre via inspeksjon Fri programvare er det mer sannsynlig å kjenne utvikleren Virkeligheten: Sjekk hvem som utvikler Fri programvare versus produsenteid

40 SKADELIGE ANGREPSSTRATEGIER - II Skadelige upålitelige utviklere Fordel for produsent: Færre upålitelige utviklere Underleverandører: “Pålitelige” utviklere kan være upålitelige Fri programvare fordeler på lang sikt: Mange sikkerhetsgjennomganger (bedre) Uklar vinner: - Ingen bevis at produsenteid programvare alltid er bedre Fri programvare versus produsenteid

41 KAN FRI PROGRAMVARE BRUKES I Effektive fri programvare system har et stort utviklersamfunn deling av kostnader med utvikling og gjennomgang Samme måte som hyllevare virker, mange kunder deler deler kostnadene Kundesystem kan lages med fri programvare- komponenter Om det ikke eksisterer et system, kan man lage det Undersøk behovene du har og gjør en risiko/nytte-analyse før man går videre tilpassede system


Laste ned ppt "Knut Yrvin – 23.03.2007 Sikkerhet gjennom uoversiktlighet eller oversiktlighet? Kilder: David A. Wheeler:dwheeler «at» dwheeler.com Theo de Raadt:deraadt."

Liknende presentasjoner


Annonser fra Google