Oracle løfter bedre java-sikkerhed

I lyset af de nylige sårbarheder, der findes i Java, og den løbende bekymring for teknologiens samlede sikkerhed, har Oracle lovet - igen - at det vil løse problemerne.

Oracle har allerede foretaget nogle ændringer i Java og arbejder på nye initiativer til forbedring af sikkerhed, skrev Nandini Ramani, leder af Java-udvikling hos Oracle, i et blogindlæg på fredag. Efter en række højprofilerede webbaserede angreb målrettet medarbejdere på tværs af forskellige brancher, lovede Orace at løse de underliggende problemer i tværplatformmiljøet.

To af ændringerne, der er skitseret i Ramanis indlæg, herunder opdateringer til applet-sikkerhedsmodellen og Java-plugins standardadfærd, er allerede live. Andre ændringer, som hvordan Java-applikationer håndterer tilbagekaldte certifikater, implementerer lokale sikkerhedspolitikker for at oprette brugerdefinerede regler og begrænser biblioteker, der er tilgængelige for applikationer på serversiden, er i øjeblikket under udvikling. Ramani angav ikke, hvornår disse opdateringer ville være tilgængelige.

Hvad med sandkassen?

"Taget som en helhed er dette godt for Java, men disse ændringer løser ikke det underliggende problem med selve Java-sandkassen, " siger HD Moore, chefforsker for Rapid7 og skaberen af ​​Metasploit-penetrationsprøvningsrammen, i en e-mail til SecurityWatch.

Java-sandkassen er et beskyttet område, hvor applikationer udføres, adskilt fra det underliggende system. Sandkassen skal fange skadelige eksekverbare computere, før de kan overtage maskinen eller kapre kørende processer. Angribere har dog med succes udnyttet flere sårbarheder til at omgå Java-sandkassen.

”Indtil Oracle implementerer sandboxing på procesniveau, såsom det, der bruges af Adobe Reader og Google Chrome, kan en ondsindet applet med en gyldig signatur stadig misbruge JRE-sikkerhedsfejl for at undslippe sandkassen og kompromittere systemet, ” sagde Moore.

Ændringerne indtil videre

Oracle opdaterede sikkerhedsmodellen for nylig, så brugere kan køre underskrevne applets uden at give yderligere privilegier og blokere, at ikke underskrevne applets kører. Dette betyder, at bare underskrift af en applet ikke længere automatisk giver programmet mulighed for at bryde ud af sandkassen.

"Dette er en god ting for sikkerhed, " sagde Moore.

En anden god ting er, at standardindstillingerne for plug-in-sikkerhedsindstillinger nu forhindrer, at underskrevne eller selvsignerede appletter udføres. Ændringen gør det nu muligt at hvidliste specifikke websteder og centralt administrere Java-sikkerhedspolitikker i virksomheden, bemærkede Moore.

Og kommer snart...

I øjeblikket understøtter Java både Certificate Revocation Lister (CRL) og Online Certificate Status Protocol (OCSP) for at kontrollere, om et underskrevet certifikat stadig er gyldigt. Da kontrollen ikke udføres som standard, selvom et certifikat var blevet tilbagekaldt, ville angribere dog kunne fortsætte med at bruge det dårlige certifikat. Oracle planlægger en opdatering, der muliggør kontrol som standard.

Den kommende lokale sikkerhedspolitik giver administratorer yderligere kontrol over politikindstillinger, såsom at lade systemadministratorer definere, hvilke computere der skal køre Java-applets, og hvilke computere ikke kan.

Selvom alle Java's nylige forsøg påvirkede applets, der kører i webbrowser, undersøger Oracle også måder at sikre, at serversiden-applikationer forbliver sikre, sagde Ramani. En ændring ville være at fjerne visse biblioteker, der ikke er nødvendige på serversiden for at reducere angreboverfladen.

Ny plan for opdateringer

Oracle vil også opdatere Java lidt hyppigere. I øjeblikket opdateres Java tre gange om året efter en separat opdateringsplan fra alle andre Oracle-produkter. Den kvartalsvise kritiske opdatering af opdateringer begynder med Java-rettelser i oktober, sagde Ramani. Oracle vil stadig frigive nødopdateringer, "ude af bånd", når det er nødvendigt.

I betragtning af at CPU allerede er en tidskrævende indsats for administratorer, tilføjelse af Java til blandingen giver bare en endnu mere gargantuansk opdatering. På den anden side betyder det, at administratorer ikke behøver at huske Java's separate opdateringsplan.