Sikkerhet - Hvorfor er alt så dårlig?

[tommyb]

Man kan inspisere implementasjonen. Men du som utvikler i en SMB har ikke tid og anledning til å sjekke koden selv. Du er avhengig at andre legger ned det arbeidet, og dermed har du outsourca en risiko uten å kunne måle effekt/sikkerhetsnivået.

 

Beviselig er det store sikkerhetshuller også i OSS, den kanskje største fordelen er at man kan avdekke disse ved mistanke.

[Phyltre]

Hvorfor heller ikke lage ett "browserish" program som man kan innstallere hvis man skal ha "nettbank" i stedet for å bruke "hullete" browsere og java. ? Just a thought

 

 

Og at dette programmet kun kan brukes til nettbank og ikke noe annet.

[quantum]

Ja, det var vel ganske nøyaktig det som var spørsmålet her ...

[elf_man]

Kan hende det er lettere å ta problemet i den andre enden; bedre og enklere informasjon om hva som faktisk er installert på en pc og hvilke konsekvenser dette har for brukeren. Jeg synes personlig det er mye bedre å lære en person hvordan den kan fikse problemer, enn å fikse det faktiske problemet.

 

Forøvrig har jo Iain M Banks en fiffig løsning på sikkerhet i sin Culture-serie, hvor alle datamaskiner skriver sine egne OS. Veldig utopisk, men tanken på et OS som tilfeldig genererer sikkerhet for hver enkelt bruker høres jo unektelig flott ut

[Capitalist Hippie]

Hvorfor heller ikke lage ett "browserish" program som man kan innstallere hvis man skal ha "nettbank" i stedet for å bruke "hullete" browsere og java. ? Just a thought

 

 

Og at dette programmet kun kan brukes til nettbank og ikke noe annet.

 

dette er kun en annerledes strategi på andre siden av problemer som oppstår uansett; selv her ...

 

risiko for feil blir bare mer spredd (med konsekvensene; ja) -- og mulighet for at samme feil gjøres flere steder øker uten at en vet at en fiks "her" vil være nyttig også "der"

 

edit: litt dårlig formulert dette, men joda..

Endret 30. januar 2013 av nostdal.org

[Capitalist Hippie]

forøvrig er alt av plugins på klientsiden en dårlig idé; altså ikke bare java

 

en nøkkelting her fremover vil bli nacl: http://en.wikipedia.org/wiki/Google_Native_Client

[David Brown]

Som C.A.Hoare skrev:

 

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

 

 

Problemet med sikkerhet ligger hovedsakelig i at de fleste velger metode 2. Det alle meste programvare er for komplisert, og bugs er derfor vanskelig å finne.

 

Det er ikke vanskelig å lage programvare som er feilfritt. Da jeg lærte om programvareutvikling (fra bl.a. Tony Hoare), behandlet vi programvare som matematikk - det er enten bevist feilfritt, ellers er det temmelig verdiløs bortsatt fra læringsmuligheter. Men det er to store utfordring i praksis for å skrive feilfritt kode - først skal man være klar over hva koden skal gjøre, og så koster det mer å skrive bevist korrekt kode.

 

Første utfordringen her er faktisk det vanskeligst. Det er svært få programmer der det ble laget en klar spesifikasjon over hva den skal gjøre. Har man ikke det på plass først, er det umulig å si at koden faktisk gjøre det det skal. Men her kan man komme langt ved "divide and conquer" - del opp programmet i stykker der man vet akkurat hva hvert enkelt bit skal gjøre, og at man er sikkert på at det gjør jobben.

 

Andre utfordringen er kostnad - i tid, penger, og ekspertise under utvikling, og tid og plass på run-time. Løsningen her er prioritering - det er viktigst å legge mest vekt på kode som er kritisk til sikkerhet eller pålitelighet av systemet, og på kode som er mye brukt.

 

Noen nevnte en feil i en java bibliotek funksjon for konvertering av ASCII til doubles. En sånn feil skal aldri kunne oppstå - det er lett å spesifisere akkurat hva en slikk funksjon skal gjøre, og dermed lett å skrive det slik at det er bevist korrekt. Og når det er kode som blir brukt i så mange systemer, har man råd til å bruke litt ekstra tid for å øke kvaliteten.

 

Heldigvis har det faktisk blitt mer vanlig med "unit testing" i utvikling - der man deler opp koden veldig i stykker som kan testes godt. Testing er ikke bevis for feilfritt kode, men det er ihvertfall et stegg i rett retning.

 

Det kan også nevnes her en av de viktigste grunn til at *nix systemer (Unix, BSD, Linux, osv.) har en velfortjent rykte for å være mer sikkert enn Windows systemer. Det kommer av unix programvare filosofi av at programmer skal gjøre kun én ting, men gjør det bra. Det stammer fra at unix systemer har alltid vært utmerket i å håndtere mange programvare om gangen, og koble dem sammen. Windows programvare filosofi stammer fra DOS dagene, der DOS var minimalt og man kjørte bare en applikasjon - dermed skal applikasjonen prøve å gjøre alt mulig. Man skal være forsiktig ved å generalisere for mye, og *nix har sine komplekse, svake programvare også (som Firefox med java...) - men mønsteret er klart at jo større og mer kompliserte programvaren er, jo vanskeligere det er å være feilfritt.

[GeirGrusom]

Det er ikke vanskelig å lage programvare som er feilfritt. Da jeg lærte om programvareutvikling (fra bl.a. Tony Hoare), behandlet vi programvare som matematikk - det er enten bevist feilfritt, ellers er det temmelig verdiløs bortsatt fra læringsmuligheter. Men det er to store utfordring i praksis for å skrive feilfritt kode - først skal man være klar over hva koden skal gjøre, og så koster det mer å skrive bevist korrekt kode.

Matematikk og unit-tester sørger for at koden gjør det den skal, ikke at den er trygg.

 

Et eksempel er at telecombransjen benytter seg av telefonnummer som brukernavn. Kanskje ikke alle engang er klar over at dette er et sikkerhetsproblem, og det kan ikke avdekkes i koden. For å fikse problemet må man gjøre løsningen mer kompleks, ikke enklere.

[David Brown]

Matematikk og unit-tester sørger for at koden gjør det den skal, ikke at den er trygg.

 

Det er absolutt korrekt. Et program kan godt være korrekte uten at det er sikkert eller trygt. Men et program kan ikke sikkert eller trygt uten at det er korrekt.

 

Det er bl.a. derfor at det viktigste stegget er å være klar over hva programmet skal gjøre.

[leafmaybe]

Bare ta en titt på stackoverflow.com - du vil da få et bilde av hva dagens programmerere sliter med. Det som vil slå deg mest er hvor mange dårlige programmerere som ikke kan programmere sin vei ut av en papirpose, blir tiltrodd med ansvar over kommersielle produkter. Riktignok ikke Java akkurat, men tendensen er altså slik at man må bare lage noe, og om det er sikkert er det ikke så nøye med. En slik tankegang kan fungere for noen type programmer, selv om jeg må innrømme at selv følelsen at din office pakke kræsjer (ofte vil feil som påvirker sikkerhet også påvirke pålitelighet) midt i arbeidet, er heller ikke noe fin. En slik tankegang er spiker i kista for "mission critical" applikasjoner, og i den forstand er Java, hvis brukt som nettbank innlogging, også en av disse.

 

Til og med senior-programmerere, utvikler ofte merkelige og mindre brukbare vaner, og i vekt av deres senioritet, nekter å forandre de, selv når de går i en ny jobb. Jeg vil ikke en gang nevne mine Java-forelesere på skolen, som overrasker meg altfor ofte med noen merkelige valg de tar i programmene de skriver foran oss.

 

Mye av dette skyldes at bransjen er ung og ikke helt har skjønt at vi er ingeniører som alle andre - og hvis man ikke tar byggingen seriøst, like seriøst som byggebransjen har utviklet seg å ta dette, så vil bygg vi reiser kollapse. Fun fact: Empire State Building ble bygget på 14 måneder, og det står fortsatt helt fint. Til sammenligning, har til og med NASA med all kompetanse de sitter på, greid å introdusere feil i koden til de fjernstyrte robotene de har og har hatt på Mars, og franske Arianne-5 bæreraketten ikke klarte å fly ordentlig grunnet såkalt rounding-error der en 64-bit verdi ble feilaktig konvertert til en 16-bit verdi.

 

Programmerere blir ikke bedt om samme type kompetanse som andre ingeniører. Du vil aldri betale en amatør for å bygge huset ditt, og du vil kreve sertifikasjon over deres ferdigheter. Det samme skjer nesten aldri i data bransjen, mest fordi sertifikasjon er varierende og det finnes få om noen, goe standarder. Vi har jo Microsoft Certified Professional og slikt, men ærlig talt, dette er bare pent tittel på en som kan konfigurere en Windows Server mm. Det er ikke garanti på at de kan bygge deg en nettbank uten feil.

 

Eller så synes jeg David Brown har mange gode poeng.

 

Kanskje vil funksjonelle språk, som lettere lar dataprogrammer bli sjekket for feil, ta over dagens programvarearena. I dag forteller vi datamaskinene HVORDAN de skal gjøre hva - og dette er alltid mer komplisert, detaljert, og mer større sjanse for feil, enn å fortelle datamaskinene HVA den skal gjøre - og akkurat sistnevnte er noe bl.a. funksjonelle språk er bedre på. Desverre, trenger vi også ytelse, og det er lettere å oppnå hvis menneske tenker som datamaskin (altså dagens programmeringsspråk) enn omvendt (funksjonelle språk).

[GeirGrusom]

Det er absolutt korrekt. Et program kan godt være korrekte uten at det er sikkert eller trygt. Men et program kan ikke sikkert eller trygt uten at det er korrekt.

 

Det er bl.a. derfor at det viktigste stegget er å være klar over hva programmet skal gjøre.

 

Joda, men dette vil alltid være svært enkelt å si i etterpåklokskapens navn.

 

Grunnen til at telecom benytter telefonnummer er at alle kundene har telefonnummer, men ikke alle har nødvendigvis en e-post. Dersom en ikke vurderer det faktum at telefonnummer er mer eller mindre offentlig informasjon og vil tillate brute-force breddeangrep (altså man sitter med en liste med telefonnummer, og man bare forsøker passord 123456 på alle man har i listen. Det er minst én person som har dette som passord, og siden man bare forsøker én gang, så blir man ikke blokkert. Det kan sitte mange kunder på samme IP) når løsningen blir skrevet så faller det helt naturlig å benytte telefonnummer. Løsningen på dette er å innføre to-trinns innlogging og vil øke kompleksiteten til løsningen, og sannsynligvis øke supportmengden.

[David Brown]

Kanskje vil funksjonelle språk, som lettere lar dataprogrammer bli sjekket for feil, ta over dagens programvarearena. I dag forteller vi datamaskinene HVORDAN de skal gjøre hva - og dette er alltid mer komplisert, detaljert, og mer større sjanse for feil, enn å fortelle datamaskinene HVA den skal gjøre - og akkurat sistnevnte er noe bl.a. funksjonelle språk er bedre på. Desverre, trenger vi også ytelse, og det er lettere å oppnå hvis menneske tenker som datamaskin (altså dagens programmeringsspråk) enn omvendt (funksjonelle språk).

 

Det er interessant at du tar opp programmeringsspråk, og programmeringsspråk typer. Du har helt rett i at det er mye lettere å bevise feilfritt funksjonalitet med funksjonelle programmeringsspråk - det var ikke tilfeldig at det er akkurat en slik språk som jeg begynte med på universistet (for mange år siden). En viktig punkt her er at rene funksjonelle språk har ikke variabler - det gjør det mye enklere å behandle dem som matematikk. Og som du sier, man sier hva resultat man ønsker, ikke hvordan man skal beregne det. Dermed er prosessen å gå fra en god spesifikasjon til et fungerene program en serie med stegg fra en abstract beskrivelse av problemet ned til en funksjonelle program som er klar til å kjøre.

 

Funksjonelle programmeringsspråk er blitt langt mer effektivt i praksis - to av de mest populære er Haskell og OCAML, og begge to kan gi veldig effektive programvare. Men det er ofte at man avviker en del fra de rene funksjonelle, for å gjøre programmeringen både lettere og mer effektivt. Det blir alltid en balanse mellom hvor høy kvalitet og sikkerhet man trenger, og hvor mye man er villige til å betale.

 

Det kan også nevnes at mange imperitive språk også støtte en del funksjonelle metoder, som Python og t.o.m. den nyeste C++ standarden.

[mello0110]

Å gjøre kjørbar kode sikker i den forstand at det ikke kan utnyttes mot brukers fordel er som å lete etter gull i enden av en regnbue. Uansett hvor sikkert man gjør et system eller program vil det alltid være noen som er smarte nok til å finne en vei rundt det og gjøre det usikkert igjen. Dette er en ond sirkel som neppe kommer til å ta slutt med det første. Jeg tror ikke det finnes programvare som er 100% sikret mot angrep eller ondsinnet utnyttelse.

 

I tilleg tror jeg at det å gjøre kode så sikker som over hodet mulig betraktelig forlenger utviklingsprosessen og utviklingskostnaden for en applikasjon slik at det ikke lenger er gunstig.

[knuterikb]

Mindre kompleksitet gir vil jo gi høyere sikkerhet, problemet er at en del ting krever en del kompleksitet....

 

Hvis vi løfter blikket litt til fugleperspektiv, så kan vi se et par ting som på overordnet nivå påvirker sikkerheten.

 

- Et miljø som utvikler en teknologi på en mest mulig transparent måte vil på et generelt grunnlag gi høyere sikkerhet, da mange enkelt kan påpeke feil og muligheter for feil - på den annen side er det også enklere for ondsinnede å evaluere teknologien for å angripe den.

 

- En teknologi som brukes av mange, vil i utgangspunktet gjøre at feil avdekkes og rettes fortere, men vil på den annen side i større grad være utsatt for målrettede angrep.

 

- En liten og målrettet teknologi kan i utgangspunktet designes sikrere en en stor og generell platform, men vil på samme tid ikke brukes av like mange mennesker slik at feil ikke vil oppdages og fikses like raskt. Om en slik liten teknologi allikevel utsettes for store målrettede angrep kan man fort være der at ressursene som angriperne har er langt større enn ressursene som kan settes inn til å 'forsvare' platformen og fjerne feil.

 

- Litt koblet til punktet over, så vil det være vanskelig for en liten og målrettet teknologi å oppnå kritisk masse, på leverandørsiden pga at for få benytter platformen og dermed skaper inntekter for leverandøren av platformen.

 

 

Så som alltid ellers innen sikkerhet vil det være snakk om avveiinger mellom mange motstridende faktorer. Det er klart at et bankhvelv ville bli noe sikrere om man valgte å sveise igjen hvelvdøren, men da skaper man istedet utfordringer mtp bruken av hvelvet....

[wingeer]

Programmering er en ting. Sikkerhet er ofte en annen. Det finnes mange som skriver kode uten å ha særlig peiling på hva som er sikkert og ikke. For å bli god på dette krever det gjerne litt abstrakt algebra og kryptografi Et tettere samarbeid mellom utviklere og analytikere ville nok hatt en positiv effekt.

[leafmaybe]

Programmering er en ting. Sikkerhet er ofte en annen. Det finnes mange som skriver kode uten å ha særlig peiling på hva som er sikkert og ikke. For å bli god på dette krever det gjerne litt abstrakt algebra og kryptografi Et tettere samarbeid mellom utviklere og analytikere ville nok hatt en positiv effekt.

 

Godt poeng. Litt av problemet her er at programvarehus er så vant med å slippe billig unna, en slags skamfull status quo, at de vil helst spare penger og bare ansette såkalte "kodere", som i mine øyne sjeldent tilsvarer et menneske med kompetanse du vil beskrive - en som kan analysere et system og kanskje bevise med vitenskapelig metode at systemet gjør hva det skal, ikke mindre og ikke mer.

 

Jeg kan videre nevne, at problemet med å analysere og verifisere kildekode skrevet i moderne imperative språk har vist seg å være SVÆRT VANSKELIG å løse, og det for vitenskapsmenn og mattematikere, ikke kodere som sitter i Cool Software AS. Kan referere til f.e. http://en.wikipedia....Halting_problem - ut fra det kan man konkludere at hvis man ikke vet om at et program avslutter eller kjører evig, så kan man heller ikke assesere hva programmet vil gjøre. Kort sagt, imperative språk har en øvre grense på hva slags pålitelighet man kan bevise ved et program.

 

Når det er sagt, har NASA oppnåd en feilstatistikk på mindre enn 1 feil per halv million linjer kode (kombinasjon av C, C++, Fortran men mest av alt HAL/S) med programvaren for romferjen sin. HAL/S er et imperativt språk, men det stoppet ikke NASA fra å utvikle verktøy for å analysere programvaren.

 

Poenget er at man kan eliminere flest feil ved høyt antall øyne som leter etter disse ("with enough eyes, all bugs are shallow" utsagnet til Linus Torvalds) og man KAN forbedre sikkerhetenmed automatiske verktøy, men i bunn og grunn kunne vi tatt et steg videre mot språk som "nesten verifiserer seg selv" ("kan denne arrayen ha en buffer overflow, ever?") eller lett lar seg verifisere med såkalte formal metoder, altså metoder basert på hundrevis av år med strenge vitenskap som matte, logikk, ikke fuzzy logic Software AS bruker for å sove godt om natten ;-) Og før noen sier at det er forskjellige krav til forskjellig programvare, husk at man vet ikke hva programvaren vil brukes til - Java var brukt før til uskyldige applets som tegnet på skjermen, men i dag brukes før man potensielt overfører store summer penger til andre, hvem skulle visst? Hvis et program aksepterer input fra bruker, så kan man ikke bevise at programmet IKKE er mission-critical.

Endret 31. januar 2013 av Amn

[GeirGrusom]

Jeg kan videre nevne, at problemet med å analysere og verifisere kildekode skrevet i moderne imperative språk har vist seg å være SVÆRT VANSKELIG å løse, og det for vitenskapsmenn og mattematikere, ikke kodere som sitter i Cool Software AS. Kan referere til f.e. http://en.wikipedia....Halting_problem - ut fra det kan man konkludere at hvis man ikke vet om at et program avslutter eller kjører evig, så kan man heller ikke assesere hva programmet vil gjøre. Kort sagt, imperative språk har en øvre grense på hva slags pålitelighet man kan bevise ved et program.

Du blander mellom pålitelighet og sikkerhet.

 

NASA er i utgangspunktet ikke opptatt av sikkerhet, men av pålitelighet.

 

ISS hadde worm på et tidspunkt, men ettersom den ikke utgjorde noen trussel mot systemets pålitelighet, eller mannskapets velferd, var det ikke viktig. Det var brudd på sikkerheten, men ikke påliteligheten.

 

Dette handler om sikkerhet, og et program som ikke er pålitelig er ikke nødvendigvis usikkert og vice versa. Det er to forskjellige problemer.

[sinnaelgen]

Jeg mener nå at i utgangspunktet så er det fult mulig å lage kode og programmer helt sikker.

problemene oppstår når kompilatoren ikke kompilerer koden "helt riktig" .

Det er også vanskelig å få alle til følge de nødvendige reglene som må til

 

Bruker man et kode bibliotek for subrutiner i kildekoden så vet man jo ikke hvor sikker funksjonene er

Så det er ikke muligheten men reglene man følger som er problemet

[Paull]

Det som vil slå deg mest er hvor mange dårlige programmerere som ikke kan programmere sin vei ut av en papirpose, blir tiltrodd med ansvar over kommersielle produkter.

 

Hm, syns det høres vanskelig ut å programmere seg ut av en papirpose. Tips til algoritmer som kan benyttes?

[wingeer]

Dybde først-søk, vel.