Sikkerhet - Hvorfor er alt så dårlig?

[Flin]

Hei, jeg har et spørsmål til dere IT folk. Kan programmere selv, men det er da rettet mot fysikk og da tenker man aldri på sånt.

 

Man leser til stadighet om problemer i forskjellige språk og plattformer, sist ute er java. Samtidig er ikke java de eneste som har hatt sikkerhets problemer og de blir nok ikke de siste heller.

 

Det jeg ikke skjønner er hvorfor ingen utvikler en løsning som kun er fokusert på å gjøre høy sikkerhets oppgaver, ting som bankid. Jeg tenker at hvis man lager noe som er veldig fokusert og kompakt så kan man unngå sikkerhetshull eller iallefall minimere sjansene for å ha de. Java foreksempel er jo en stor plattform som gjør mye mer enn det man trenger for en ting som bankid. Er det for vanskelig å utvikle noe sånt? Er det feil at java har mer enn det man trenger? Hvis ikke hvorfor er det ingen som gjør det?

[FenrisC0de]

Hei, jeg har et spørsmål til dere IT folk. Kan programmere selv, men det er da rettet mot fysikk og da tenker man aldri på sånt.

 

Man leser til stadighet om problemer i forskjellige språk og plattformer, sist ute er java. Samtidig er ikke java de eneste som har hatt sikkerhets problemer og de blir nok ikke de siste heller.

 

Det jeg ikke skjønner er hvorfor ingen utvikler en løsning som kun er fokusert på å gjøre høy sikkerhets oppgaver, ting som bankid. Jeg tenker at hvis man lager noe som er veldig fokusert og kompakt så kan man unngå sikkerhetshull eller iallefall minimere sjansene for å ha de. Java foreksempel er jo en stor plattform som gjør mye mer enn det man trenger for en ting som bankid. Er det for vanskelig å utvikle noe sånt? Er det feil at java har mer enn det man trenger? Hvis ikke hvorfor er det ingen som gjør det?

 

All kode inneholder feil. Så på spørsmålet ditt om det er vanskelig å utvikle "noe sånt", så er svaret ja. Det er ikke bare Java som det stadig oppdages sikkerhetshull i, men også feks Windows, VLC, OSX, Chrome, Adobe Reader, etc. Problemet er at sikkerhet på et applikasjonslaget er komplekst, og kompleks kode har en lettere tendes til å inneholde sikkerhetsfeil.

 

Så enkelt er det

 

Og det handler også om hva som blir brukt. Hvis han hadde gått vekk fra Java og satset på en annen teknologi, ville alle de som leter etter sårbarheter rettet søkelyset sitt mot denne og det ville nok ikke tatt lang tid før man ville oppdaget hull der også. Adobe Reader har fått mye (velfortjent) kritikk for sikkerhetsproblemene sine, men det viste seg etterhvert at FoxIt Reader ikke var spesielt bedre selv

Endret 29. januar 2013 av Untouchab1e

[GeirGrusom]

Alt av kode inneholder programmeringsfeil. Det finnes bortimot ingen unntak. Selv ikke et "Hello World!" er nødvendigvis uten sikkerhetsproblematikk eller programmeringsfeil.

 

Ulempen til java er det at tjenesten den utfører kan potensielt gjøre stor skade dersom feilene i programvaren utnyttes.

 

Java er i utgangspunktet en virtuell maskin som kjører på alle klientene. Denne er også åpnet mot alle nettsider som brukere besøker (gjennom Java Applets). Det finnes derimot masse funksjonalitet som skal sørge for sikkerhet, men som sagt inneholder all programvare feil.

Endret 29. januar 2013 av GeirGrusom

[quantum]

Syns svarene her blir litt "feil"; Det er jo ikke slik at man skal la vær å sikte mot høy sikkerhet fordi man tror man aldri når 100%-nivået uansett. Ikke at jeg tror noen mener akkurat det heller. Men: Java JVM fins i mange utgaver, JRocket, Oracle Java standard, OpenJDK, gcc som produserer native-kode, Dalvik, Java ME og så videre. Husker tilogmed en liten variant som kunne kjøre standard bytecode med strippa biblioteker på Palm-pilot, en gang i 1.2/1.4-tiden. Tipper den jvm'en kun hadde en mikroskopisk brøkdel kodelinjer sammenlignet med den som folk flest bruker i browseren sin i dag.

 

Så, hvis noen tok seg tid tli å lage en jvm/plugin med strippa funksjonalitet, få optimaliseringer, generelt ryddig kode med substansielt færre kodelinjer enn en vanlig jvm-plugin ville hatt, og samtidig en uttalt og dedikert prioritering av sikkerhet, så ville resultatet sikkert blitt et helt annet enn vi ser i dag? OpenBSd gjør jo dette i dag og mange foretrekker den løsningen til visse oppgaver fremfor linux, windows, freebsd mv.

 

Så spørsmålet er jo fortsatt; hvorfor er det ingen som gjør det? Hele java-tankegangen er jo basert på en best-of-breed-filosofi, ville bare vært naturlig å lage en variant rettet mot enkelhet, korrekthet og sikkerhet, strippa for funksjoner og features som ikke er nødvendig for formålet.

Endret 29. januar 2013 av quantum

[Flin]

Akkurat, hvorfor er det ingen som lager en løsning med så lite som mulig. Hvis komplekse koder inneholder problemer hvorfor er det ingen som prøver å la en kode som gjør en ting veldig bra, men bare den tingen.

 

Lage noe som er ment for høysikkerhets applikasjoner og ikke noe annet. Hvis jeg skal løse noe og jeg finner ut at løsningen min har veldig mange problemer og er veldig komplisert og derfor vanskelig å forbedre ville jeg vurdert å begynne på nytt.

Endret 29. januar 2013 av Flin

[GeirGrusom]

Så, hvis noen tok seg tid tli å lage en jvm/plugin med strippa funksjonalitet, få optimaliseringer, generelt ryddig kode med substansielt færre kodelinjer enn en vanlig jvm-plugin ville hatt, og samtidig en uttalt og dedikert prioritering av sikkerhet, så ville resultatet sikkert blitt et helt annet enn vi ser i dag? OpenBSd gjør jo dette i dag og mange foretrekker den løsningen til visse oppgaver fremfor linux, windows, freebsd mv.

 

Hva mener du er "strippet" funksjonalitet? Dalvik er forøvrig heller ikke en Java VM.

[quantum]

Hva mener du er "strippet" funksjonalitet? Dalvik er forøvrig heller ikke en Java VM.

med det så mener jeg at funksjonalitet som ikke er nødvendig er fjernet. og forøvrig er ikke Dalvik en Java VM. i likhet med gcc og wabi. hvordan det?

Endret 29. januar 2013 av quantum

[GeirGrusom]

med det så mener jeg at funksjonalitet som ikke er nødvendig er fjernet. og forøvrig er ikke Dalvik en Java VM. i likhet med gcc og wabi. hvordan det?

Hva mener du er unødvendig funksjonalitet? Hvordan vet du at dette vil forbedre sikkerheten?

 

Fikk bare et inntrykk fra posten at du mente Dalvik var en Java VM implementasjon. Men det er uvesentlig.

[Flin]

Men kunne det vært mulig Geir? Å lage noe med mindre funksjonalitet,dermed mindre sjanse for hull, men som forsatt kan gjøre jobben. Side på en annen måte: Trenger man alt java har å tilby for å lage foreksempel bankid?

[GeirGrusom]

Men kunne det vært mulig Geir? Å lage noe med mindre funksjonalitet,dermed mindre sjanse for hull, men som forsatt kan gjøre jobben. Side på en annen måte: Trenger man alt java har å tilby for å lage foreksempel bankid?

 

Jeg kan forestille meg at Java er helt unødvendig for BankID, men jeg har bare sittet på brukerstedets standpunkt (jeg utviklet en BankID-basert tjeneste i fjor sommer) og jeg er ikke egentlig istand til å vurdere juridisk-, sikkerhets- eller kostnadskrav rundt BankID på andre plattformer, så jeg bare vegrer meg for å bombastisk hevde at det finnes andre gode løsninger, og at disse er enkle, og at det er NETS som bare er slappfisker slik som noen kommentatorer ser ut til å hevde.

 

Når det gjelder Java så er det viktig å ha i tankene hva Java egentlig er. Det er en plattform for programvareutvikling, og den må kunne tilfredsstille de krav utviklerne setter til det. Dette er også noe de har fått til ganske bra da Java er et av hvis ikke den mest brukte utviklingsplattformen i dag. Dersom de tar vekk noe, så vil det gå ut over en eller annen kunde.

 

Skal man starte på nytt, så har man helt andre utgangspunkt. Men mye sikkerhetsproblematikk er vanskelig å finne ut av på forhånd. En kan ta forhåndsregler, men jeg er sikker på at alle utviklere på dette forumet har opplevd fenomenet at ting ikke går i stykker før kundene får tak i det.

Hvorfor ikke gjøre alt perfekt fra begynnelsen? Veldig lett å si i etterkant.

[quantum]

Hva mener du er unødvendig funksjonalitet? Hvordan vet du at dette vil forbedre sikkerheten?

 

Fikk bare et inntrykk fra posten at du mente Dalvik var en Java VM implementasjon. Men det er uvesentlig.

jeg mener ikke at OpenBSD er en javavm heller. generelt tror jeg færre kodelinjer fører til færre feil. det gjelder sikkert her også, men hvis du trenger hard proof kan jeg ikke hjelpe deg. med unødvendig funksjonalitet mener jeg funksjonalitet som ikke er nødvendig for å utføre det man ønsker å utføre. så det koker ned til - som du sikkert skjønner - hva man ønsker å gjøre, og hva det er kan ikke jeg svare på, men for det som er på bordet nå dreier deg seg om det bank-id-appleten gjør. uten at jeg vet hva det er i detalj, men jeg antar det er noe avgrenset i forhold til alt mulig annet en jvm kan tenkes å bli brukt til.

[GeirGrusom]

JIT kompilering er ikke nødvendig for at BankID skal funke, og kan potensielt være en kilde til sikkerhetsproblemer. Burde man fjerne det?

 

Jeg bare hevder at det er vanskelig å skulle vurdere hva som er essensielt eller ikke, fordi Java har et massivt kundegrunnlag. Opplevelsen min er at uansett hvor obskur en funksjon er så er det alltid en eller annen gjøk, et eller annet sted, som bruker det.

 

Skal man starte på nytt med en annen VM, noe jeg hadde applaudert, så hadde det muligens vært en annen sak.

[quantum]

Skal man starte på nytt med en annen VM, noe jeg hadde applaudert, så hadde det muligens vært en annen sak.

 

Ja, det fins alltid en gjøk, et eller annet sted ... Edit: men han, og alle andre brukere av java, må gjerne beholde den rike funksjonaliteten, selvfølgelig. Til visse formål, hvor det er begrenset funksjonalitetsbehov, f.eks. som når man på død og liv skal lage en autentiseringsplugin for webbrowsere, blir java med all denne funksjonaliteten, og dertil hørende bugs og sikkerhetshull, helt feil verktøy, slike løsninger bør heller baseres på noe enklere og mer spesialisert, gitt at det da vil være enklere å vedlikeholde mht. sikkerhetshull. En kan jo også spørre seg hvor pottetett dette kan bli så lenge det skal kjøre i en hullete browser.

 

Problemet her er ellers ikke knytta til bank-id, det er knytta til alt mulig annet en java-plugin kan (mis)brukes til, så hvis man vil løse sikkerhetsproblemet må man enten parkere - eller fikse - java-plugin'en, og skal man parkere den må bank-id baseres på en annen teknologi.

 

Inntil Java-plugin, Java-webstart og jpln kan erklæres pottetett - noe som ikke kommer til å skje - burde bruken avgrenses til kontrollerte miljøer, f.eks. i bedrifter hvor det kan være en nyttig mekanisme for å få rulla ut klientapplikasjoner. Pt. er bank-id den eneste praktiske bruken av java i browseren jeg selv benytter meg av, så det enkleste (i lys av mitt noe selvsentrerte verdensbilde) er kanskje å si no-thanks, akkurat som man bør til en haug andre suspekte browserplugins.

Endret 29. januar 2013 av quantum

[wingeer]

Det forskes vel på slikt så vidt jeg vet. F.eks. ved NTNU jobber det noen med det her.

[NoShoes]

Mindre kompleksitet gir vil jo gi høyere sikkerhet, problemet er at en del ting krever en del kompleksitet. som Nevnt over, det er vanskelig å lage et OS uten at det blir ganske mye kode, som skal samhandle og virke sammen, som vil gi kompleksitet. Problemet med java er vel ikke Java i seg selv, men browserplugin.

Og det er sant som nevnt over, java får mye tyn siden det er så mye brukt, og dermed er det mangen som prøver å finne. og når da flere hull blir funnet, vil det igjen føre til at enda flere leter etter hull. Men Oracle har også gjort en crapy jobb med oppdateringene og implementeringing.

Men det skal også være sagt at det er vanskelig å drive å patche "usikker" kode. Det har nok vært for lite sikkerhetsfokus fra begynnelsen.

[Unlimited LTD]

"All programs can be optimized, and all programs have bugs; therefore all programs can be optimized to one line that doesn’t work."

 

Greia er at et program er utrolig komplekst. Bare den enkle tingen å ha en tekst i minnet krever å definere en pointer til en adresse, lengden på teksten og encodingen til teksten (ASCII, UTF, osv...).

Eller så har man kanskje en nullterminering (man har et spesielt tegn for å betegne slutten på teksten). Hva skjer da dersom teksten inneholder en premature nullterminering? Eller hvis teksten ikke inneholder en nullterminering? Hva hvis teksten man lagrer er større enn minneområdet man setter av?

 

Når selv noe så enkelt som det å lagre tekst har flere feilkilder, hva da med resten?

 

Ta for eksempel sammenlikning av tekst. Er disse to stringene like? "Hello World" og "Hello world"? Nei, her er w stor og liten.

Men hva med "Hello World" og "Hello World"? De ser like ut for deg, men for en datamaskin kan de være to vidt forskjellige ting. De kan være encodet forskjellig, ASCII og UTF, kanskje, eller UTF-8 og UTF-16? Kanskje mellomrommet er to vidt forskjellige ting?

 

Så for å kunne gjøre noe fornuftig med den teksten må man legge til masse kode rundt for å kunne sammenlikne. Man må plusse, trekke fra, bitskifte, passe på overflow osv...

 

Og så har du desimaltall. En datamaskin kan ikke uten videre representere desimaltall. Istedet bruker man floating points, som er en eksponent. Dette fører til at tallet 0.1 lagres som tallet 0.10000000000000001. Det er ikke en programmeringsfeil, men en begrensning i hvordan datamaskinen lagrer tall.

 

En av feilene i Java var nettopp en feil i et slikt rart tall; 2.2250738585072012e-308

Prøver man å lagre det tallet vil Java fryse.

 

Grunnen til dette er algoritmen som prøver å gjøre om teksten "2.2250738585072012e-308" til en double. Det kan jo fikses, men først måtte jo buggen bli oppdaget.

Koden som feilet har jo blitt testet grundig. Men, hvor grundig er grundig nok? Det finnes uendelig mange tall, hvordan kan man teste alle?

 

Og her er selve greia. Når selv lagring av en tekststring inneholder så mange elementer, hvor mange elementer inneholder da ikke et helt rammeverk?

 

Man kan teste, og teste, men man kan ikke teste alt. Det er hverken mulig eller fornuftig. Og derfor har software bugs.

 

 

hm.. litt mange tankesprang der... var det forståelig?

[Zlatzman]

*snip

Det var ganske forståelig, men så vidt jeg tolker teksten din vil det alltid være feilkilder. Jo flere "features" programmet har, jo flere feilkilder vil det i så fall være.

 

Kan det ikke da være fornuftig å skrive et svært lite program, men dertil færre feilkilder, som kun skal støtte f.eks. Bank ID. For alt som ikke er BankID benytter man enten et eget bunnprogram, eller Java eller lignende, avhengig av hvor kritisk sikkerhet er.

 

Med andre ord: kan fragmentering av applikasjonsmiljøet (av mangel på bedre ordforråd) føre til at hver enkel bit i større grad kan optimaliseres sitt trusselbilde?

[tommyb]

Jeg, som webutvikler, må si meg litt enig med Zlatz og Flin. Men det er ikke så enkelt. Hadde det vært så enkelt, hadde folk ikke gjort det.

 

Hvorfor Java o.l:

Man bruker eksterne moduler og tredjeparts rammeverk fordi disse gir ferdige verktøy som gjør det enklere og bedre å utvikle det du til syvende og sist skal ende opp med. Men det følger med kostnader.

 

Hvorfor ikke Java o.l.:

Det er et mareritt at man må overlate kontrollen til eksterne aktører der man ikke vet hvor flinke de er i sitt sikkerhetsarbeid, man kan ikke teste, man kan ikke oppdage selv, man kan ikke lukke selv, man må følge med på den eksterne aktørens forum, og selv ta stilling til deres problemer. Har vært innom PHPBB som vi så sparka rett ut igjen fordi de ikke takla sikkerhet.

 

Hvorfor Java o.l. likevel:

Samtidig så vet vi at de der ute ER bedre enn det man får til på egen hånd, rett og slett gjennom sine store ressurser. Java har for eksempel mange kjempeflinke utviklere med spesialkunnskap om sikkerhet, mens våre norske SMB-bedrifter typisk har noen få poteter som skal gjøre alt. De sitter faktisk på mye bedre (samlet både bredere og spissere) kompetanse hos Oracle enn det jeg og mine medprogrammerere i SMB-markedet sitter på.

 

Hvorfor ikke Java o.l. likevel:

Problemet er at Java, og andre rammeverk, er så store at den ekspertkompetansen ikke strekker til der heller. Og når noe rakner, rakner hele greia, og vi får disse monsterhullene som må lukkes umiddelbart.

 

Konklusjon - eller mangel på sådan:

Det ideelle fra et sikkerhetsperspektiv hadde kanskje vært om man faktisk hadde et miljø som det rundt Java til å utvikle optimalt/teste/avdekke feil, men på en så liten og uavhengig komponent som mulig. Dessverre har typisk små komponenter også bittesmå miljøer.

 

Ja, mindre kode betyr langt færre sikkerhetshull. Men mindre miljøer betyr at disse sikkerhetshullene har større ondsinnet "testmiljø" enn godsinnet. De kan lett bli utnyttet før de blir oppdaget.

 

OpenSource betyr at flere folk kan bidra til å avdekke svakheter. Det betyr dessverre ikke at flere folk faktisk bidrar.

[quantum]

Kan det ikke da være fornuftig å skrive et svært lite program, men dertil færre feilkilder, som kun skal støtte f.eks. Bank ID. For alt som ikke er BankID benytter man enten et eget bunnprogram, eller Java eller lignende, avhengig av hvor kritisk sikkerhet er.

 

Problemet her er at bank-id forutsetter at folk har en generelt usikker plugin installert i browseren. Så hvis man kan løse opp denne bindingen er problemet med bank-id forsåvidt løst, forutsatt at man ikke "benytter ... Java eller lignende, avhengig av hvor kritisk sikkerhet er".

 

Altså - folk (både bank-id-brukere og andre) kan ikke ha javaplugin aktivert i browseren. Og med tanke på hvor vanskelig det er for mange å få på plass java-plugin for å bruke bank-id i dag er det vel en smule utopisk å håpe på at folk klarer å få disablet/avinstallert denne når bank-id ikke lenger trenger å ha den installert. Men det er klart, over tid, vil det jo hjelpe noe, særlig hvis Oracle kunne gjøre java-plugin litt mer utilgjengelig for almenheten. Evt. sørge for at den ikke har sikkerhetshull. Og da er vi vel fortsatt i eventyrland, vil jeg tro ...

[quantum]

 

Hvorfor ikke Java o.l.:

Det er et mareritt at man må overlate kontrollen til eksterne aktører der man ikke vet hvor flinke de er i sitt sikkerhetsarbeid, man kan ikke teste, man kan ikke oppdage selv, man kan ikke lukke selv, man må følge med på den eksterne aktørens forum, og selv ta stilling til deres problemer. Har vært innom PHPBB som vi så sparka rett ut igjen fordi de ikke takla sikkerhet.

 

 

Fordelen med java er at man kan velge implementasjon og fordelen med oss er at man kan inspisere implementasjonen hvis man vil. Det er ikke noe problem å ha en ren oss-java-stack, men om man har praktisk anledning til å utnytte mulighetene dette gir ... tja?

 

Det gjelder også å huske på her at alt det vonde og betente er knytta til browserplugin-konseptet, ikke Java i seg selv.