Afsløring: Åbent sikkerhedshul i Java

Tre år gammel Java-sårbarhed er ikke fikset korrekt. Polske it-specialister afslører nu, hvordan svagheden udnyttes.

Polske Security Explorations afslører nu, at en sårbarhed i Java, som Oracle burde have fjernet for flere år siden, fortsat eksisterer, skriver digi.no.

Security Explorations har tidligere opdaget en række alvorlige sårbarheder ved Java og kan nu igen afsløre et sikkerhedshul i det verdensomspændende plugin.

Men denne gang er der tale om en tre år gammel sårbarhed, som det ikke er lykkedes for Oracle at lukke korrekt.

Offentliggøre detaljer

Security Explorations har derfor valgt at offentliggøre alle detaljer om sårbarheden, og hvordan den kan udnyttes. Dette skyldes, at firmaet netop har vedtaget en ny politik om, at man ikke længere vil tilbageholde oplysninger om mislykkede sikkerhedsrettelser.

Oracle blev i september 2013 opmærksom på fejlen og udsendte en opdatering til systemet. Men de polske it-specialister afslører nu, at Oracle ikke har gjort deres arbejde ordentligt.

Alt, hvad der skal til for igen at udnytte den gamle svaghed, er ifølge it-specialisterne at ændre fire tegn i den gamle kode til de oprindelige tegn offentliggjort af Security Explorations i en PAC-kode tilbage i oktober 2013.

Ved herefter at fremprovokere en fejl 404 (side ikke fundet) i browseren er det muligt at gå bag om Javas sandkasse og få fuld adgang til det eksterne system.

Oracle kun de første

Security Explorations har indtil videre afsløret, at sårbarheden omfatter Java SE 7 opdatering 97, Java SE 8 opdatering 74 og Java SE 9.

‘Oracle er de første, der får den tvivlsomme ære at opleve vores ændrede politik,’ skriver Security Explorations i en meddelelse, hvilket indikerer, at vi kan forvente lignende afsløringer fra dem i fremtiden.

Der er ifølge digi.no intet, der tyder på, at nogen endnu har udnyttet sårbarheden.

Kom gratis med til Danmarks største IT-sikkerhedsevent!

Infosecurity, Europas mest populære IT-sikkerhedsevent, afholdes for første gang i Danmark den 3. og 4. maj 2016. 50 udstillere, 5 konferencesale og mere end 60 seminarer og caseoplæg fra ind- og udland. Læs mere her.

Kommentarer (11)

Morten Hansen

Kære V2.
Som Danmarks største IT medie er det vigtigt I husker på jeres faglighed.
Det indebærer i dette tilfælde at kende forskel på Java sproget, og en Java fortolker, i form af dette browser plugin fra Oracle.
Vi ved godt at browser pluginnet er hullet som en si. Det skal ikke gå ud over sproget, som nogle mindre teknisk kyndige der læser denne nyhed kunne forledes til at tro.
Det er en del af jeres ansvar som medie at løfte niveauet hos jeres læsere så debatten ikke foregår på niveauer såsom "MS er noget skidt", "Føj java kan ikke bruges til noget" osv, men handler om at træde nogle skridt tilbage og debattere på et højere plan. Det ansvar falder dog også på os IT kyndige, træk niveauet lidt op så vi har noget at snakke om ;)

Mogens Lysemose

Jeg er helt enig i ein generelle opfordring.
Men har svært ved helt præcist at forstå din anke i den konkrete sag.
Er det du kritiserer at v2 skriver java (navnet på en åben standard for et programmeringasprog) - når de burde skrive Oracles java plugin til intermetbrowsere (JRE)? Det sidste er jo ret tungt at skrive og læse. Og for de fleste almindelige brugere helt overflødigt.

Det du mener er at man kan køre java bytecode lokalt på en maskine uden at involvere en browser?
Og at eer principiet kunne være andre implenteringer end Oracles, f.eks. IBMs JRE somdøde for en del år siden.
Standalone java systemprogrammering har jeg ikke set siden universitetet, og kender ikke nogen steder det bruges. Men hatten af hvis det er det du lever af.

Per Bellfield

Mogens, jeg må desværre fortælle dig at du ikke helt har styr på terminologierne og hvad Java ellers bliver brugt til.
Præcist det du skriver er lige netop hvad Morten Hansen referere til at han gerne vil undgå.
Jo vist, jeg er personligt ikke selv helt tilfreds med Java som sprog i sig selv, det har mange irritationsmomenter og mangler. Men det er en HELT anden diskussion som der er mange forskellige holdninger til.

JRE = Java Runtime Environment, og kan på ingen måder side-stilles som Java Plugin for Browsers.

Standalone java systemprogrammering bruges mange flere steder end du aner, knap så meget i vores daglige brug af Desktop applications, men bare lige et par velkendte er
-MATLAB og Eclispe, Nasa World Wind og Lotus Notes og en del andre Nasa web applikationer.
- Desuden bliver JavaServer Pages (jsp) brugt i rigelige mængder i de lidt større corporate områder, så vidt jeg husker var Skat's tidligere side (Nyligt relancheret i ASP.net) skrevet i JSP. Ebay er lavet i Java (JSP), etc.
- Din Blu-ray afspiller bruger Java til dine Blu-ray film til at vise alt det andet ekstra "bonus content" på dine indkøbte Blu-ray film.
- Java er blevet brugt på Hubble Space Telescope.
- Java bliver ofte brugt i mindre produktioner bl.a inden for forsker området.
- Ej at forglemme så bruger ca. 80% af det "smarte" mobile og tablet marked Java til Apps og OS (Her tales selvfølgeligt om Android), og yderligere så er noget nær alle "featurephones" levende i dag, Java baseret.
- Og så lige en lille sjov en som du med garanti ikke havde regnet med, så køre vores danske elektroniske pas Java (JavaCard) fra Gemalto.
- Din set-top box køre med stor sandsynlighed Java.
- Smart TV (Også nogle af dem der ikke nødvendigvis er Android)

Så at anfægte at Java ikke bliver brugt og at du ikke har set det siden universitet skyldtes med stor sandsynlighed specifikt dit præcise arbejdsområde.

Lige netop derfor, har Morten så uendeligt ret i det han skriver.

Slut-note:
Nej, jeg arbejder/lever ikke af Java, tværtimod.

Johnnie Hougaard Nielsen

når de burde skrive Oracles java plugin til intermetbrowsere (JRE)?

Hvis vi taler faglighed, så handler det netop ikke om JRE (der jo er hele Java uden JDK), men det lille hjørne som er at køre applets i en browser via den meget usikre plugin-standard NPAPI.

Og det er ikke altså afgørende at det er et plugin fra Oracle, når grundproblemet egentlig slet ikke er Java, men den hamrende usikre NPAPI fra før nogen spekulerede ret meget på hacking ud af browseren. Muligheden for at køre bytekode (jar/class filer) lokalt uden en browser er heller ikke temaet, dette giver lignende usikkerheder som al anden download af binær kode, bortset fra at Java i det mindste har en infrastruktur der gør at der enten kræves eksplicitte tilladelser, eller fundne huller i JVM.

Java er såmænd udmærket, netop også sikkerhedsmæssigt, sammenlignet med fx Windows .exe filer (m.v.) - lige bortset fra at begge dele ikke står sig ved at kunne aktiveres fra det vilde Internet. Og hvad som helst med NPAPI gør vejen til blødende sikkerhedshuller alt for kort. Det ligger bl.a. også bag Flash-katastrofen, og tilsvarende sårbarheder med andre plugins, bortset fra at de typisk har haft så lille udbredelse (de fleste er døde nu) at det ikke kunne betale sig for hackere at gå efter dem.

Kort sagt er det alvorligt misvisende blot at skrive "Java". Også uden at skrive en hel beskrivende paragraf, kan der såmænd godt skelnes fra hele Java platformen, ved fx at skrive noget i stil med "Java applets" eller "Java i browser". Værre er det ikke.

Uffe Seerup

Dette er en sårbarhed i Javas class loader. Class loaders er ikke en del af browser plugin - tværtimod, det er en af de mest grundlæggende dele af Java VMs og er altid i spil når der afvikles en hvilken som helst type af Java kode. Det er i kernen af Java.

Der står intet om NPAPI i artiklen. Dette er ikke en sårbarhed udløst af NPAPIs design. Det er en sårbarhed i Javas kerne.

De polske sikkerhedseksperter beviser hvordan denne sårbarhed kan udnyttes i en browser. Det er fordi effekten af en Java sårbarhed bliver mangedoblet hvis den kan bruges til at kompromittere maskiner som kører med Java i browseren.

Men sårbarheden har også betydning for server brug af Java: "This is not true. We proved that Issue 69 could be successfully exploited in a server environment as well such as Google App Engine for Java [2]. "

Mit råd: Før I farer i blækhuset for at forsvare Java, så læs lige den grundlæggende artikel først. Overskriften er (i dette tilfælde) ikke misvisende. Det er en fejl i Java - specifikt i Javas class loader logik.

Ja - version2 gør sig tit skyldige i click-baiting, og man kunne også godt have ønsket sig at de havde taget server vinklen med.

Per Bellfield

Tusind tak for opklaringen :)
Altid dejligt at nogen gider læse de bagvedliggende artikler.
På baggrund af dette, er det vel korrekt, men jeg ønsker stadig gerne sådan generelt at der bliver gået lidt mere i dybden, og i tilfælde af fejl/bugs i Java for Browser (NPAPI implemeneteringen) at man udspecificere det.

Dog syntes jeg stadig at mine punkter er væsentlige i forhold til det Mogens specifikt skrev, bl.a om brugen af Java, og at JRE ikke er det samme som Java for Browsers pluginet.

Mogens Lysemose

Ja det er ikke længe siden V2 skrev at oracle ville stoppe java hvor det var plugin'et. Jeg mener ikke kritikken er lige så berettiget her.

Mht. terminologi vs abstraktionsniveau i terminolog:
Det lader til producenten heller ikke "har styr på terminologien":

www.java.com : "Do I have java? Check to ensure that you have the recommended version of Java installed for your operating system." (checker kun java-plugin i browseren)

og

"What is Java?" "What will I get when I download Java software?" "The JRE is the runtime portion of Java software, which is all you need to run it in your Web browser."

Så jeg mener ikke det er så sært at jeg blander JRE og plugin sammen.

Kan det alternativt tænkes at Oracle vælger et abstraktionsniveau for ikke at forvirre millioner af brugere mere end højst nødvendigt?

Jakob Damkjær

At være nogen destruktive blackhats så er det ok at være det ?

Håber de bliver sagsøgt af alle dem afsløringen af det her sikkerhedshul påvirker.

Desclosure er godt men uden varsel, uden at informere vendor og uden at give vendor tid til at fikse hullet før man kaster det på nettet er hamrende uetisk, åbently PR stunt og burde være ulovligt.

Tobias Tobiasen

Men sårbarheden har også betydning for server brug af Java: "This is not true. We proved that Issue 69 could be successfully exploited in a server environment as well such as Google App Engine for Java [2]. "


En Applet i en browser kører jo kode downloaded fra internettet. Derfor er det forholdsvist simpelt at udnytte dette. Du skal bare have brugeren til at besøge en hjemmeside i en browser og hvis Applets ellers er enabled så kan du udnytte sikkerhedshullet.
Til server brug har man (forhåbentlig) nøje udvalgt de jar filer man bruger og derfor er muligheden for at udnytte dette til at angribe en server meget begrænset.

Log ind eller opret en konto for at skrive kommentarer

JobfinderJob i it-branchen