Oracle lovar bättre java-säkerhet

Mot bakgrund av de sårbarheter som nyligen hittats i Java och pågående oro över teknikens övergripande säkerhet har Oracle lovat - igen - att det kommer att lösa problemen.

Oracle har redan gjort några ändringar i Java och arbetar med nya initiativ för att förbättra säkerheten, skrev Nandini Ramani, chef för Java-utvecklingen på Oracle, i ett blogginlägg på fredag. Efter en serie högprofilerade webbaserade attacker riktade till anställda i olika branscher, lovade Orace att ta itu med de underliggande problemen i plattformsmiljön.

Två av förändringarna i Ramanis inlägg, inklusive uppdateringar av appletens säkerhetsmodell och Java-insticksprogrammets standardbeteende, är redan live. Andra ändringar, till exempel hur Java-applikationer hanterar återkallade certifikat, implementerar lokala säkerhetspolicyer för att skapa anpassade regler och begränsa bibliotek som är tillgängliga för applikationer på serversidan, håller på att utvecklas. Ramani angav inte när dessa uppdateringar skulle vara tillgängliga.

Vad sägs om sandlådan?

"Sammantaget är detta bra för Java, men dessa förändringar löser inte det underliggande problemet med själva Java-lådan, " sade HD Moore, chef för Rapid7 och skapare av Metasploit-penetrationsprovningsramen, i en e-post till SecurityWatch.

Java-sandlådan är ett skyddat område där applikationer körs, separat från det underliggande systemet. Sandlådan är tänkt att fånga skadliga körbara filer innan de kan ta över maskinen eller kapa igång processer. Men angriparna har framgångsrikt utnyttjat flera sårbarheter för att kringgå Java-sandlådan.

"Fram till att Oracle implementerar sandboxning på processnivå, till exempel den som används av Adobe Reader och Google Chrome, kan en skadlig applet med giltig signatur fortfarande missbruka JRE-säkerhetsbrister för att undkomma sandlådan och äventyra systemet, " sa Moore.

Förändringarna hittills

Oracle uppdaterade säkerhetsmodellen nyligen så att användare kan köra signerade appletar utan att ge ytterligare behörigheter och blockera osignerade applets från att köras. Detta innebär att bara att skriva en applet inte längre automatiskt ger programmet möjlighet att bryta ut ur sandlådan.

"Detta är bra för säkerheten, " sade Moore.

En annan bra sak är det faktum att standardinstickssäkerhetsinställningarna nu förhindrar att inte signerade eller självsignerade applets körs. Ändringen gör det nu möjligt att vitlista specifika webbplatser och centralt hantera Java-säkerhetspolicyer i företaget, konstaterade Moore.

Och kommer snart...

För närvarande stöder Java både certifikatåterkallningslister (CRL) och onlinecertifikatstatusprotokoll (OCSP) för att verifiera om ett signerat certifikat fortfarande är giltigt. Eftersom kontrollen inte utförs som standard, även om ett certifikat hade återkallats, skulle angripare kunna fortsätta använda det dåliga certifikatet. Oracle planerar en uppdatering som gör det möjligt att kontrollera som standard.

Den kommande lokala säkerhetspolicyn ger administratörer ytterligare kontroll över policyinställningar, som att låta systemadministratörer definiera vilka datorer som ska köra Java-appleter och vilka datorer inte kan.

Även om alla Javas senaste tester påverkade appletarna som körs i webbläsaren, undersöker Oracle också sätt att säkerställa serverns applikationer förbli säkra, sade Ramani. En förändring skulle vara att ta bort vissa bibliotek som inte behövs på serversidan för att minska attackytan.

Nytt schema för uppdateringar

Oracle kommer också att uppdatera Java lite oftare. Just nu uppdateras Java tre gånger per år, efter ett separat uppdateringsschema från alla andra Oracle-produkter. Den kvartalsvisa kritiska uppdateringen kommer att börja inkludera Java-korrigeringar i oktober, sade Ramani. Oracle kommer fortfarande att släppa nöduppdateringar "utan band" när det är nödvändigt.

Med tanke på att CPU redan är en tidskrävande ansträngning för administratörer, läggs Java till blandningen bara för en ännu mer gargantuan uppdatering. Å andra sidan betyder det att administratörer inte behöver komma ihåg Java: s separata uppdateringsschema.