Sikkerhet - Hvorfor er alt så dårlig?

[Flin]

snipe

 

Her har vi det beste svaret i tråden. Som i bunn og grunn svarer på det jeg lurer på.

 

Så svaret på det jeg lurer på er vel rett og slett: Det kunne vært mulig å lage noe som er mindre komplisert, men alle plattformer må nødvendigvis være ganske komplekse for å kunne brukes. Hvis man kobler dette med menneskelige feil og at feil vil snike seg inn kommer man frem til at plastformer som mange tester og jobber med å forbedre vil ha fordeler over små spesialiserte løsninger.

 

Mulig man i teorien kan gjøre det jeg spør etter i første post, men i praksis blir det vanskelig.

[tommyb]

Samtidig skal man være oppmerksom på at mange store og nesten alle mellomstore prosjekter også drives av en liten håndfull nøkkelpersoner... Noe så smått som bankID skal være mulig å lage like bra uten å støtte seg på et enormt rammeverk som Java.

[David Brown]

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.

 

Det er riktig at en pålitelig program er ikke nødvendigvis sikkert - men for å være sikkert, så /må/ det være pålitelig.

 

Det fins tre typer sikkerhetsfeil. Det er designfeil (som f.eks. å lagre passord i klar tekst), implementasjonsfeil (som buffer overflow), og brukerfeil (som brukerer med "123" som passord).

 

Designfeil er vanskelig å eliminere totalt - man må tenke gjennom alle mulige konsekvenser av systemet. Men man kan komme langt med god design prosess, med blant annet mye diskusjon og samarbeid mellom forskjellige folk på forskjellige nivå. Alt for ofte er det kun sluttprogrammereren som bestemme kritiske design funksjonalitet.

 

Implementasjonsfeil kan elimineres nesten helt i noen type kode - og reduseres dramatisk fra "industry standard" av opp til 10-50 per KLOC ifølge noen rapporter. Bruk av bedre tilpasset programmeringsspråk hjelper mye, samt begrenset bruk av funksjonalitet (bruker man bare funksjoner som "strncat" istedenfor "strcat" i C, eliminere man mange muligheter til buffer overflow), bruk av testing og verifikasjons verktøy, og bruk av programmeringsstyl som gjør det lett å verifisere programmet. Og for kritiske funksjoner - som lavnivå biblioteker og VM'er til java, python, osv., kan man bruke mer tid og krefter og mer formelle metoder.

 

Bruker feil blir det alltid. Selv om man jobber hardt i designfasen, som å spesifisere at "123" ikke godtas som passord, blir man aldri kvitt muligheten for at brukeren gjøre noe dumt. Men god design og god dokumentasjon kan redusere risikoen.

[David Brown]

Samtidig skal man være oppmerksom på at mange store og nesten alle mellomstore prosjekter også drives av en liten håndfull nøkkelpersoner... Noe så smått som bankID skal være mulig å lage like bra uten å støtte seg på et enormt rammeverk som Java.

 

Jeg er ikke en ekspert på browser sikkerhet, men jeg ser ikke at det er noen grunn her til å bruke Java istedenfor Javascript. Jeg antar at det er fordi de tror at browseren vil kanskje lagre passordet hvis det er en vanlig html form felt. Men det blir det ikke med mindre enn at både websiden og brukeren tillater det - og så lenge det fins keylogger trojans, er det ikke særlig grunn til å gjøre noe mer ut av det. Og hvis man virkelig ville gjøre noe mer avanserte, er det ingen problem i javascript å kapre tasttrykk uten å ha en tekst boks - da blir passordet aldri lagret i sin helhet.

[GeirGrusom]

Det er riktig at en pålitelig program er ikke nødvendigvis sikkert - men for å være sikkert, så /må/ det være pålitelig.

 

Hvorfor det?

[David Brown]

Hvorfor det?

 

Hvis du ikke kan stole på at programmet gjøre det det skal, kan du ikke stole på at sikkerhetsfunksjonalitet i programmet fungere.

 

Det er klart at en bugs i programmet betyr ikke nødvendigvis en sikkerhetshul - men hvis du først tillater at programmet har bugs, så kan du ikke være sikker på at sikkerheten er under kontroll.

 

Du kan godt prøve å si at f.eks. programkrasj eller feil i display ikke har noe med sikkerheten å gjøre. Men i praksis kan det være indirekte tilkoblinger som er vanskelig å forutsi. Tidlig i denne diskusjonen ble det nevnt en feil i java om konvertering av rare tall fra ascii til doubles - det er nepe noen som tenkte at det var en del av sikkerhetskoden i biblioteket, men det ble en sikkerhetsfeil likevel. På samme måte trengs det ikke mye fantasi eller googling for å se at programkrasj kan også fører til sikkerhetsfeil.

[GeirGrusom]

Hvis du ikke kan stole på at programmet gjøre det det skal, kan du ikke stole på at sikkerhetsfunksjonalitet i programmet fungere.

 

Det er klart at en bugs i programmet betyr ikke nødvendigvis en sikkerhetshul - men hvis du først tillater at programmet har bugs, så kan du ikke være sikker på at sikkerheten er under kontroll.

 

Du kan godt prøve å si at f.eks. programkrasj eller feil i display ikke har noe med sikkerheten å gjøre. Men i praksis kan det være indirekte tilkoblinger som er vanskelig å forutsi. Tidlig i denne diskusjonen ble det nevnt en feil i java om konvertering av rare tall fra ascii til doubles - det er nepe noen som tenkte at det var en del av sikkerhetskoden i biblioteket, men det ble en sikkerhetsfeil likevel. På samme måte trengs det ikke mye fantasi eller googling for å se at programkrasj kan også fører til sikkerhetsfeil.

 

Du kan aldri være sikker på at sikkerheten er udner kontroll. Å sette likhetstegn mellom pålitelighet og sikkerhet er en feiltagelse etter min mening.

 

Steam feiler betaling hver gang jeg prøver å kjøpe noe med "Error code -5". Jeg må refreshe og betale på nytt hver gang jeg kjøper noe på steam.

 

Er betalingsløsningen til Steam usikker, eller upålitelig?

 

Skype brukere kunne logge på som andre brukere enn seg selv. Er tjenesten usikker, eller upålitelig?

[tomsi42]

Du kan aldri være sikker på at sikkerheten er udner kontroll. Å sette likhetstegn mellom pålitelighet og sikkerhet er en feiltagelse etter min mening.

Jeg tolket ikke David dithen at han setter likhetstegn mellom pålitelighet og sikkerhet. Men at pålitelighet er en forutsetning for kunne gjøre noe sikkert.

[Unlimited LTD]

Jeg tolket ikke David dithen at han setter likhetstegn mellom pålitelighet og sikkerhet. Men at pålitelighet er en forutsetning for kunne gjøre noe sikkert.

Og sånn tror jeg Geir også tolket det.

 

Betalingssystemet til Steam er sikkert, men ikke veldig pålitelig.

Skype er pålitelig, men ikke nødvendigvis like sikkert.

Ero, pålitelighet og sikkerhet er ikke nødvendigvis avhengig av hverandre.

 

Sikkerheten må være pålitelig, det er klart, men da mener jeg man nærmer seg kverulering og blanding av uttrykk.

[tommyb]

Disse er ikke to uavhengige verdier.

 

 

Minnelekkasjer går direkte på begge begrepene, samtidig. Når en løsning ikke er pålitelig betyr der direkte at sikkerheten heller ikke er pålitelig. Det er også sannsynlig at brudd på sikkerhet kan ramme pålitelighet. Om det er en orm på romstasjonen, kan den medføre minnelekkasjer, CPU-bruk, kræsj, med mer.

[GeirGrusom]

Disse er ikke to uavhengige verdier.

 

 

Minnelekkasjer går direkte på begge begrepene, samtidig. Når en løsning ikke er pålitelig betyr der direkte at sikkerheten heller ikke er pålitelig. Det er også sannsynlig at brudd på sikkerhet kan ramme pålitelighet. Om det er en orm på romstasjonen, kan den medføre minnelekkasjer, CPU-bruk, kræsj, med mer.

 

Og det går på pålitelighet igjen. Minnelekasje fører ikke nødvendigvis til kompromittert sikkerhet med mindre lekasjene består av ukrypterte passord som kan sniffes fra heapen på en klientmaskin.

[tommyb]

Svært, svært mange sikkerhetsangrep er bygget rundt å utnytte buffer overrun, som såvidt jeg har forstått er å fylle minnet til du bryter ut... Det er angrep basert på manglende eller mangelfull sikkerhet som da som en sideeffekt direkte vil medføre redusert pålitelighet.

 

Wiki:

 

In computer security and programming, a buffer overflow, or buffer overrun, is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety.

Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited.

Endret 1. februar 2013 av tommyb

[David Brown]

Svært, svært mange sikkerhetsangrep er bygget rundt å utnytte buffer overrun, som såvidt jeg har forstått er å fylle minnet til du bryter ut... Det er angrep basert på manglende eller mangelfull sikkerhet som da som en sideeffekt direkte vil medføre redusert pålitelighet.

 

Buffer overrun er fine eksempler av programfeil som er hovedsakelig pålitelighetsproblemer og som av og til også fører til sikkerhets problemer. Skjer det en buffer overflow, gjør ikke programmet det det skal - det er alltid en bugs. Det er sjelden at buffer overflow fører til sikkerhetssvakheter (de fleste fører bare til feil i programmet), selv om relativt mange sikkerhetsbrudd benytter seg av buffer overflow. Men som regel der buffer overflow fører til sikkerhetsproblemer, er ikke overflowen i det man ville klassifisere som sikkerhetrelatert kode. Det er en av grunnene til at jeg mener man kan ikke si at et program er sikker før man har en pålitelig og feilfritt program.

 

Det triste med buffer overflow er at det er nesten alltid lett å unngå dem i programmering. Den enkleste måten er å bruke programmeringsspråk som har mer automatisk kontroll over minne og buffere - da er det mye vanskeligere for programmereren å skrive noe feil. Ellers hvis man er nøye med funksjonene man bruker og ta i bruk kontrollverktøy, er det ikke vanskelig å skrive korrekt kode ved bruk av bufferer.

[tommyb]

Sier du det? Det var i alle fall en egen del av IT-sikkerhetsboka.

 

Det er også dette som gjør at man ikke trengte modchip på Xbox, og det samme er utnyttet på PS2 og Wii, igjen følge Wiki. Buffer overrun er nok ikke like utbredt nå som for ti år siden, siden man bruker høyere andel av høynivåspråk med innebygget minnehåndtering, men det har vært bak noen av de største ormeproblemene Microsoft har hatt i moderne tid.

 

Men dette er uansett bare et eksempel. Hvis man ikke har pålitelighet, er ikke sikkerheten pålitelig. Om man ikke har sikkerhet, kan man ikke garantere pålitelighet. De to er knyttet sammen, om ikke en-til-en på samme skala.

Endret 1. februar 2013 av tommyb

[Laserbeam]

Hva er ulempene og fordelene for nettbankene å bytte fra BankID til en variant av MinID + kodebrikke?

Endret 4. februar 2013 av Gnålern

[tingo]

Noen ulemper:

- bankene har sannsynligvis betalt for BankID, hvis de må bytte så er denne investeringen "bortkastet"

- nettjenestene til bankene må endres til å benytte MinID istedet for BankID, dette koster sikkert en del (ikke minst testingen rundt en slik endring)

[tommyb]

BankID er en tjeneste de har betalt for og brukt i mange år, så det kan knapt sies å være bortkastet.

[dahuff]

Ett moment som ikke er nevnt er ønske om å rulle ut ny funksjonalitet. Hadde alle Oracle/Sun fortsatt vært på Java versjon 5, hadde ikke Java applets fått mange overskrifter om sikkerhetsproblemer, rett og slett fordi det blir færre nye feil å oppdage etterhvert som problemene blir rettet opp i. Men en slik taktikk ville igjen gått på bekostning av økosystemet rundt Java, fordi Java må fornye seg for å holde seg aktuell i forhold til andre plattformer.

 

Ett annet moment som ikke er nevnt, er antall kontaktflater. Man kan diskutere om en ren JavaScript/html/ssl løsning er tryggere i forhold til bankid, eller at en enklere applet-plattform ville gitt mindre sjanse for feil. Momentet er at en ekstra applet, er en ekstra kontaktflate vedsiden av den eksisterende nettleseren, og dette gir svakere sikkerhet. Applets behøver dessuten egne oppdateringsrutiner, og det hviler ett veldig stort ansvar på Oracle og Adobe for å ivareta sikkerheten til brorparten av verdens (PC) internettbrukere. Allerede her, ser jeg svakhet med designet til bankid-plattformen. BankID kan være premieeksempel på god programmeringspraksis, men det har mindre betydning om Oracle ikke klarer å holde brukerne oppdaterte med sikre nettleserplugins.

 

Designfeil er vanskelig å eliminere totalt - man må tenke gjennom alle mulige konsekvenser av systemet. Men man kan komme langt med god design prosess, med blant annet mye diskusjon og samarbeid mellom forskjellige folk på forskjellige nivå. Alt for ofte er det kun sluttprogrammereren som bestemme kritiske design funksjonalitet.

 

Det kommer av at design og programmering ikke kan delegeres til adskilte roller. En rendyrket arkitekt eller en komite vil da designe en løsning på papiret som i teorien ser lovende ut. Programmereren vil som regel sitte på ett annet erfaringsgrunnlag, eller oppdager nye sider av problemet underveis, og det opprinnelige designet kan ikke lenger implementeres slik som det var tenkt. Programvaredesign er den mest ressurskrevende delen av ett prosjekt. Det er faktisk det jeg bruker mest tid på som programmerer, slash "code-monkey". Faktisk kunne vi kalt oss designprogrammerere.

 

Dette er selvsagt med forbehold. For det jevne nettapplikasjonsprosjektet må man forvente at sluttprogrammereren benytter grunnleggende praksis. For prosjekter innenfor spesielle domener må man samarbeide med de som har greie på domenet produktet er rettet mot. Utviklere som jobber med BankID har helt sikkert tilgang på rett kompetanse innen sikkerhet og arkitektur, og slipper da å måtte beherske alle disse domenene på egenhånd.

Endret 9. februar 2013 av dahuff

[quantum]

Ett moment som ikke er nevnt er ønske om å rulle ut ny funksjonalitet. Hadde alle Oracle/Sun fortsatt vært på Java versjon 5, hadde ikke Java applets fått mange overskrifter om sikkerhetsproblemer, rett og slett fordi det blir færre nye feil å oppdage etterhvert som problemene blir rettet opp i. Men en slik taktikk ville igjen gått på bekostning av økosystemet rundt Java, fordi Java må fornye seg for å holde seg aktuell i forhold til andre plattformer.

Vi har vel vært innom dette i en annen tråd om dette emnet ganske nylig. Hvis man først skal lage en plugin så er på mange måter java det mest behagelige valget; cross-browser, cross-platform og med enorm funksjonalitet og utbredelse. Det sier seg vel selv at dette må komme til en viss pris... nemlig sikkerhetshull som blir utnyttet. Så Bank-id har gjort det lett for seg selv, brukerne betaler prisen.