Oracle lover bedre java-sikkerhet

I lys av nylige sårbarheter som finnes i Java og pågående bekymringer for teknologiens generelle sikkerhet, har Oracle lovet - igjen - at det vil løse problemene.

Oracle har allerede gjort noen endringer i Java og jobber med nye initiativer for å forbedre sikkerheten, skrev Nandini Ramani, leder for Java-utvikling hos Oracle, i et blogginnlegg på fredag. Etter en serie høyprofilerte nettbaserte angrep målrettet ansatte over forskjellige bransjer, lovet Orace å ta opp de underliggende problemene i plattformmiljøet.

To av endringene som er skissert i Ramanis innlegg, inkludert oppdateringer til applet-sikkerhetsmodellen og Java-plugins standard oppførsel, er allerede i live. Andre endringer, for eksempel hvordan Java-applikasjoner håndterer tilbakekalte sertifikater, implementerer lokale sikkerhetsregler for å lage egendefinerte regler og begrenser biblioteker som er tilgjengelige for applikasjoner på serversiden, er for tiden under utvikling. Ramani indikerte ikke når disse oppdateringene ville være tilgjengelige.

Hva med sandkassen?

"Tatt i sin helhet er dette bra for Java, men disse endringene løser ikke det underliggende problemet med selve Java-sandkassen, " sa HD Moore, sjef for Rapid7 og skaper av Metasploit-penetrasjonsprøvingens rammer, i en e-post til SecurityWatch.

Java-sandkassen er et beskyttet område der applikasjoner blir kjørt, atskilt fra det underliggende systemet. Sandkassen er ment å fange skadelige kjørbare filer før de kan overta maskinen eller kapre kjørende prosesser. Imidlertid har angripere utnyttet flere sårbarheter for å omgå Java sandkassen.

"Inntil Oracle implementerer sandboksing på prosessnivå, for eksempel det som brukes av Adobe Reader og Google Chrome, kan en ondsinnet applet med gyldig signatur fortsatt misbruke JRE-sikkerhetsfeil for å unnslippe sandkassen og kompromittere systemet, " sa Moore.

Endringene så langt

Oracle oppdaterte sikkerhetsmodellen nylig, slik at brukere kan kjøre signerte applets uten å gi flere rettigheter og blokkere at ikke signerte applets kjører. Dette betyr at bare å signere en applet ikke lenger automatisk gir programmet muligheten til å bryte ut av sandkassen.

"Dette er en god ting for sikkerhet, " sa Moore.

En annen god ting er det at sikkerhetsinnstillingene for plugin-moduler nå forhindrer at ikke signerte eller selvsignerte appletter kjøres. Endringen gjør det nå mulig å hvitliste spesifikke nettsteder og sentralt administrere Java-sikkerhetspolitikk i bedriften, bemerket Moore.

Og kommer snart...

For øyeblikket støtter Java både Certificate Revocation Lists (CRL) og Online Certificate Status Protocol (OCSP) for å bekrefte om et signert sertifikat fortsatt er gyldig. Men siden sjekken ikke er utført som standard, selv om et sertifikat hadde blitt tilbakekalt, ville angripere kunne fortsette å bruke den dårlige attesten. Oracle planlegger en oppdatering som muliggjør kontroll som standard.

Den kommende lokale sikkerhetspolicyen gir administratorer ekstra kontroll over policyinnstillinger, for eksempel å la systemadministratorer definere hvilke datamaskiner som skal kjøre Java-appleter, og hvilke datamaskiner ikke kan.

Selv om alle Javas nylige studier har påvirket applettene som kjører i nettleseren, undersøker Oracle også måter å sikre at serversidens applikasjoner forblir sikre, sa Ramani. En endring ville være å fjerne visse biblioteker som ikke er nødvendige på serversiden for å redusere angrepsoverflaten.

Ny plan for oppdateringer

Oracle kommer også til å oppdatere Java litt oftere. For øyeblikket oppdateres Java tre ganger i året, etter en egen oppdateringsplan fra alle andre Oracle-produkter. Den kvartalsvise kritiske oppdateringen om oppdatering begynner med Java-fikser i oktober, sa Ramani. Oracle vil fremdeles gi ut nødoppdateringer, "utenfor bandet, " når det er nødvendig.

Tatt i betraktning at CPU allerede er en tidskrevende innsats for administratorer, legger Java til miksen bare til en enda mer garantert oppdatering. På den annen side betyr det at administratorer ikke trenger å huske Javas separate oppdateringsplan.