Oracle om Java-sårbarheder: »Der er flere sårbarheder i Google Chrome«

Sommerstafetten: Hvornår bliver Java sikker, lyder spørgsmålet fra sikkerhedsfirmaet Dubex til Oracle, som peger på sårbarheder i andre produkter i stedet.

Opdatering af Java-plugin i browseren blev sidste vinter et emne, som mainstream-medier tog op i stor stil, og som danskerne begyndte at tale om over spisebordet, fordi NemID jo binder danskerne til at bruge Java.

Sikkerhedsfirmaet Dubex har derfor valgt blandt andet at spørge Oracle om sikkerheden i Java - et spørgsmål, der har fået en smiley i halen - i sommerstafetten, hvor virksomhederne, som Version2 besøger, sender spørgsmål videre til den næste i tour-rækken.

Her svarer kommunikationsdirektør Anders Rendtorff på de tre spørgsmål fra Dubex:

1) Sårbarheder i Java har været meget i medierne. Hvornår er Java sikker? :-)

»Jeg tror man skal vende spørgsmålet om. Vi er selvfølgelig en virksomhed, der sætter sikkerhed i vores produkter rigtig højt. Det gælder også Java. Men Java-debatten har måske været noget skævvredet. Det er klart, at man skal fokusere på sikkerhedsrisici, der har at gøre med vores penge og digitale identitet. Men mængden af sårbarheder i Java er faktisk mindre end i andre offentlige produkter, der også kan indgå i løsninger til digital signatur. For eksempel har der været markant flere sårbarheder i Firefox, i Google Chrome og i Adobes produkter (ifølge Secunia var der 66 sårbarheder i Java JRE SE, mens der var 291 i Chrome og 257 i Firefox, red.). Så ja - der har været meget fokus på sårbarheder i Java, men man har nok glemt fra mediernes side at beskrive, hvordan sikkerheden er i forhold til andre produkter. Og også glemt at fortælle, at det typisk har været Standard Edition, som er plugin til browsere, det har handlet om. Det er kun en lille, lille del af hele Java-rammeværket. Så det er altså ikke Java Enterprise Edition, det drejer sig om.«

(Version2 spørger ind:) Men flere uafhængige sikkerhedseksperter har jo sagt, at man bør undgå at bruge Java som browser-plugin. Der er jo ikke nogen, som har sagt, at man bør undgå at bruge Google Chrome fuldstændigt?

»Måske er det fordi, at NemID-løsninger ikke i dag er baseret på HTML5. Men så kan man stille spørgsmålet - hvad vil det betyde for sikkerheden, hvis vi gør det? Det er et åbent spørgsmål.«

2) Hvordan tænker I sikkerhed ind i cloud-løsninger?

»Det korte svar er om vores nye database 12C, hvor vi samler sikkerhedsstrukturen i et fælles lag, hvor man kan plugge containere med databaser ind. Du har adskilt alle kundernes data. Det hele bliver opdateret ét sted og opdateringerne slår igennem hele vejen. Det er en helt ny måde at håndtere multi-tenancy på databaseniveau.«

3) Big data er meget oppe i tiden. Hvad ser I som den største risiko ved big data?

»Den største risiko er, at man ikke anerkender, at big data er en realitet for alle virksomheder, uanset størrelse, og derfor ikke går i gang med at se på big data. Vi ser at europæiske virksomheder generelt er langt længere fremme end danske virksomheder, i forhold ti l at arbejde med fænomenet og bruge det til salg og markedsføring.«
»Uanset om du får flere data eller ej, skal du stadig overholde lovgivningen om databeskyttelse. Så hvis data er indsamlet på lovlig vis, kan jeg ikke se nogen risiko. Så den største risiko er altså, at man tror, det er hype det hele, eller at man synes, man er for lille til det, og derfor ikke går i gang.«

Denne artikel er en del af Version2's sommertour, hvor vi flytter redaktionen ud til en stribe danske it-firmaer. Se hele tour-kalenderen

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (5)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Kasper Lund

Antallet der gør det, men hvor "kritiske" de er - og lige ved år skiftet, efter stortset hver eneste af deres "lyn patches", blev der bare ved med at sprøjte enten nye, eller andre måder at udnytte allerede kritiske huller, som var bleven "lukket". Så den med at der findes xxxx sårbarheder, i XYZ's produkt gider jeg ærligt talt ikke rigtig høre om fra Oracle, når nu snakken samtidigt er faldet på java og når netop deres aller mindste java komponent havde like 40-60 sårbarheder med en CVE score på 10 (hvilket er det absolut højeste). Må ærligt erkende jeg ikke har fulgt op på påstanden af at der skulle være 200+ sårbarheder i de nævnte browsere - men jeg føler mig ret sikker på at de næppe har været oppe og ringe med så samme antal af CVE-10 exploits, som Java gjorde i den periode. Føj det var grelt.

  • 5
  • 0
Joe Sørensen

Et andet stort problem er også selve opdateringsproceduren. Javas browser plugin er ikke let at opdaterer og derfor skal der meget til for at almindelige brugere opdatere produktet.

For at opdaterer Chrome: Genstart browseren.
For at opdaterer Firefox: Genstart browseren fra en bruger med lokalt Administrative rettigheder og tryk ikke cancel.
For at opdaterer Java browser plugin: Du blever bedt om at evaluerer til Administrator rettigheder af Windows. Du skal accepterer dette. Derefter får du at vide at der er en opdatering i et vindue hvor du kan bede om at få den installeret. Du evaluerer igen til Administrative rettigheder i Windows og du kan nu se installationsguiden. Du afslutter nu alle dine browserer og følger guiden. Husk at læse alle punkter i guiden, da Java er kendt for også at installerer crap-ware produkter som en del af opdateringen.

Kan du se forskellen?

  • 4
  • 0
Mads Bendixen

Det er muligt der er flere sårbarheder i Google Chrome, men der har man som dansk forbruger flere alternativer at vælge i mellem. Som dansker er man tvunget til Java plugin og der er ingen alternativer, pga. nemID.

  • 2
  • 0
Allan S. Hansen

Da jeg var i militæret (og sikkert stadigvæk) var der en frase vi fik banket ind i hovedet om at man ikke kan vaske sig ren i andres skidt (okay, jeg omskrev den til noget lidt mere pænt formuleret :)).

Kan godt være andre firmaer har sikkerhedshuller og problemer, men det gør ikke ens egne bedre.

  • 2
  • 0
Johnnie Hougaard Nielsen

Et andet argument for ikke blot at se på antallet, er spørgsmålet om reaktionstiden, altså tiden brugere skal leve med at der er offentligt kendte fejl. Med Chrome vil jeg forvente en rettelse i løbet af et par dage, højst en uge. Med Java skal jeg være glad hvis der er sket noget efter omkring en måned, og som Joe pointerer, er opdateringen mere besværlig end den behøver at være.

Jeg synes såmænd at Java er ganske udmærket, men sådanne lokalt orienterede værktøjer skal ikke udstilles i en browser, på en måde som gør at vilkårlige hjemmesider kan få adgang til at forsøge at finde en sprække. Click-to-run kan skærme her, men det burde i det mindste være standard-indstilling i browserne.

  • 0
  • 0
Log ind eller Opret konto for at kommentere