Stort sikkerhedshul i Java åbner for angreb

25 kommentarer.  Hop til debatten
Stort sikkerhedshul i Java åbner for angreb
Illustration: Java.
Et stort sikkerhedshul er blevet konstateret i den seneste version af Java. Sikkerhedsfirma anbefaler at deaktivere Java - eller bruge Chrome.
27. august 2012 kl. 15:30
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Et sikkerhedshul i Java 7 er dukket frem, og Ifølge DK CERT kan hullet bruges til at angribe sårbare computere. Java-programmerne er en forudsætning for at bruge NemID, som rigtig mange danskere benytter, når de eksempelvis skal besøge deres netbank. Det skriver DK CERT.

Umiddelbart ser det ud til, at sikkerhedshullet kun findes i Java 7 og i browserne Internet Explorer, Firefox og Opera. Googles Chrome skulle efter sigende ikke være påvirket. Ingen ældre versioner af Java skulle være ramt af sårbarheden, men Oracle, som står for sikkerhedshåndteringen i Java, har ifølge DK CERT endnu ikke lukket sikkerhedsbristen.

Slå Java fra eller brug Chrome

Sikkerhedsfirmaet Deep End Research har gennemgået, hvordan et angreb vil se ud. Så snart Java-programmet begynder at starte, og kaffekoppen kommer frem, vil loading-vinduet blive blankt. Herefter vil et ondsindet miniprogram blive installeret, men det vil ifølge sikkerhedsfirmaet være svært for brugeren at vurdere, om de er blevet hacket.

Deep End Research anbefaler ikke, at man downloader en ældre version af Java, men at man i stedet deaktiverer programmet i sin browser, eller at man skifter over til Chrome.

Artiklen fortsætter efter annoncen

Se gennemgang af, hvordan Deep End Research har konstateret sikkerhedshullet her.

25 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
23
28. august 2012 kl. 14:59

http://www.exploit-db.com/exploits/20865/

"This module exploits a vulnerability in Java 7, which allows an attacker to run arbitrary Java code outside the sandbox. This flaw is also being exploited in the wild, and there is no patch from Oracle at this point. The exploit has been tested to work against: IE, Chrome and Firefox across different platforms."

13
27. august 2012 kl. 21:09

Nu hvor Chrome heller ikke beskytter en mod fejlen, så er det dog tydeligt at fejlen er rettet mod Windows. Man kan derfor anbefale folk at bruge Java på en ikke-Windows maskine i mellemtiden.

Stakkels Tante Olga, men jeg var nu meget klog i sin tid, og gav min farmor Ubuntu i stedet for Windows 7.

16
27. august 2012 kl. 22:56

Det var sgu da en underlig konklusion David Rechnagel Udsen!? Fordi Chrome ikke beskytter mod en 0day i Java, så må det være Windows' skyld? For at citere Rapid7's blog (MSF):

We have also (successfully) tested the module against the following environments:

  • Mozilla Firefox on Ubuntu Linux 10.04
  • Internet Explorer / Mozilla Firefox / Chrome on Windows XP
  • Internet Explorer / Mozilla Firefox on Windows Vista
  • Internet Explorer / Mozilla Firefox on Windows 7
  • Safar[i] on OS X 10.7.4

Så om systemet hedder OSX, Linux eller Windows gør altså ikke meget forskel (alle systemer, i deres nyeste udgave, giver "kun" exploitet brugeradgang, hvilket dog stadig er enormt farligt).

Det er dog interessant at se hvor hurtig Apple er til at rette hullet (i deres særskilte udgave). De har tidligere været måneder bagefter (selvom Java huller tit virker crossplatfrom), men gad vide om de ikke har lært deres lektie efter Flashback?

18
27. august 2012 kl. 23:17

Det var sgu da en underlig konklusion David Rechnagel Udsen!? Fordi Chrome ikke beskytter mod en 0day i Java, så må det være Windows' skyld? For at citere Rapid7's blog (MSF):

Det er lidt af en fejltolkning af hvad jeg skriver; det er Oracle Javas skyld. Men de eksempler hvor det aktivt blev misbrugt henviste sig mod Windows-systemer, var min pointe. Så selvom at din Linux Oracle Java maskine faldt i fælden, så ville det næppe betyde noget.

15
27. august 2012 kl. 22:44

Man kan derfor anbefale folk at bruge Java på en ikke-Windows maskine i mellemtiden.

Hjælper ikke voldsomt meget her, sikkerhedshullet rammer også Oracle Java 7 på Linuxhttp://threatpost.com/en_us/blogs/new-java-zero-day-being-used-targeted-attacks-082712

Et bedre råd er

  1. De-aktiver Java plugin i din primære (normale) browser
  2. Brug en særskilt browser [med Java plugin aktiveret] til NemID stuff og kun til det, gerne i en virtual machine

Jeg gør selv dette. Det er meget længe siden at jeg har set en Java applet, undtagen selvfølgelig på NemID og netbank sider.

20
28. august 2012 kl. 00:23

@Henning: Ved man, at OpenJDK/IcedTea ikke er udsat i forhold til dette?

21
28. august 2012 kl. 01:01

Efter hvad alle oplyser, virker det som en Java7 only fejl. Mig bekendt findes OpenJDK for alle linux distributioner i både version 6 og 7, og version 6 er den, der bliver installeret, såfremt der ikke eksplicit vælges version 7. For Oracle gælder, at version 7 installeres, med mindre man eksplicit vælger version 6 - det ved jeg af erfaring, da langt hovedparten af Oracles egne applikationsstakke ikke virker med version 7, så vi måtte installere en policy på alle Windows 7 maskiner på arbejdet, således at medarbejderne kunne forsætte deres arbejde:-(

12
27. august 2012 kl. 21:04

Hvis man følger linket i artiklen kan man se at "brug chrome" nu er streget ud. Den oprindelige exploit virkede tilsyneladende ikke på chrome, men det er nu blevet fikset :-(

25
11. januar 2013 kl. 12:19

Jeg ved der er en del som mener at nemid ikke virker med openjdk, men jeg har bruger nu openjdk/icedtea uden de store problemer, og det er også det jeg installerer rundt omkring.

Det kommer lidt an på versioner (både af ojdk/icedtea såvel som browsere) - det har f.eks. været fuldstændigt broken på firefox. Den versions-kombination jeg har på min VM lige pt. virker (kan ikke huske versionsnumrene), dog crasher appletten i ny og næ på Nordeas netbank, og man må så starte forfra.

Før jeg installerer updates på min VM sørger jeg for at lave et snapshot først, så jeg kan lave rollback hvis opdateringen smadrer NemID kompatibilitet... det er desværre sket et par gange, så jeg ville ikke anbefale openjdk til alle og enhver :)

Hvis man følger linket i artiklen kan man se at "brug chrome" nu er streget ud. Den oprindelige exploit virkede tilsyneladende ikke på chrome, men det er nu blevet fikset :-(

Til gengæld kan man enable "plugin click to play" i Chrome - selvom JRE pluginet til Chrome er vulnerable, så burde c2p vel stoppe drive-bys?

4
27. august 2012 kl. 17:20

Når jeg læser / hører om programmerings sprog og problemer, så er det tit og ofte Java som er i sigte. Hvorfor hører man aldrig noget om C++, Python, Ruby, PHP, C#, andet? Why just Java?

8
27. august 2012 kl. 17:59

Når jeg læser / hører om programmerings sprog og problemer, så er det tit og ofte Java som er i sigte. Hvorfor hører man aldrig noget om C++, Python, Ruby, PHP, C#, andet? Why just Java?

En af grundene er at Java har en virtuel maskine JVM og en sandkassemodel - som er designet til Internet og browsere. Hvor man ret præcist kan angive rettigheder til programmerne - medmindre de har en dårlig programmør der bare ber om fuld adgang.

Desværre har det vist sig igennem mange år at kreativiteten til at finde huller i implementeringen er voldsomt stor og der er fundet mange sådanne sikkerhedshuller i Java på browser/klient siden. De andre programmeringssprog du angiver bruges sjældent som client-applikation gennem browseren, hvor eksempelvis Javascript (som ikke har noget med Java at gøre) bruges oftere.

Så Java og Javascript bruges til client-applikationer på browseren, og har fejl ligesom alt andet aktiv kode.

Mange af de andre sprog anvendes derimod på serversiden hvor Java efter min mening er yderst stærk sikkerhedsmæssigt, meget let at indkapsle en Java WAR på Tomcat eller andre applikationsservere.

PHP og applikationer skrevet i PHP er på serversiden konstant under angreb og der kommer dagligt rapporter om nye sårbarheder i disse. Der er nogle store grimme ting i PHP, specielt de ældre versioner, eksempelvis "php hash collision denial of service vulnerability" som du kan læse meget om på internet, men som rent faktisk var et problem for flere andre sprog.

11
27. august 2012 kl. 18:52

En af grundene er at Java har en virtuel maskine JVM og en sandkassemodel - som er designet til Internet og browsere. Hvor man ret præcist kan angive rettigheder til programmerne - medmindre de har en dårlig programmør der bare ber om fuld adgang.

Så pænt er Java browser-plugin modellen desværre ikke implementeret.

Man kan signere appletten, hvorefter den kører udenfor sandboxen med fulde rettigheder, eller man kan undlade at signere appletten, hvorefter den kører med meget begrænsede rettigheder, og f.eks. ikke kan tilgå andre servere end den, som appletten er downloaded fra og ikke kan læse/skrive filer osv.

14
27. august 2012 kl. 21:09

Supplement til Rasmus Faber-Espensen: Jeps og en signeret applet kan derfor fungere som en slags boot-loader, dvs at den væsentlige del af koden først hentes, når brugeren har sagt ja til at køre appletten. (Det er en af de mange ting, jeg har imod NemID appletten.)

10
27. august 2012 kl. 18:40

PHP og applikationer skrevet i PHP er på serversiden konstant under angreb og der kommer dagligt rapporter om nye sårbarheder i disse.

Den eneste 2012 advisory om selve PHP, jeg umiddelbart kan finde hos CERT, er fra 16 maj 2012 og omhandler en svaghed når PHP afvikles som CGI. Man må vel tro, at det efterhånden kun er et fåtal der bruger CGI på noget, der kan nås udefra ;)

http://www.kb.cert.org/vuls/id/520827

Mvh, Palle

7
27. august 2012 kl. 17:56

Når jeg læser / hører om programmerings sprog og problemer, så er det tit og ofte Java som er i sigte. Hvorfor hører man aldrig noget om C++, Python, Ruby, PHP, C#, andet? Why just Java?

Som Lund korrekt skriver, så handler dette ikke om programmeringssproget Java, men Javas virtuelle maskine, som om muligt er kodet sammen i brandert. De andre sprog du nævner er enten oversat til maskinkode, kører på servere eller i en mindre brugt virtuel maskine (såsom Silverlight).

Selv .NET, som opnår mange daglige brugere hver dag, bruges næppe af fjerne internet-programmer som NemID, osv., hvilket gør at .NET også mere sjældent havner i rampelyset for potentielle ballademagere.

Det er derfor at Java og Flash er notoriske på dette område, fordi de begge er så anvendt, så fyldt med sikkerhedsfejl i deres implementering og normalt kører man hvem som helsts programmer.

5
27. august 2012 kl. 17:36

Grunden til at man ikke hører noget om C# kan opklares med et ord, Silverlight. Ingen bruger det ;-)

1
27. august 2012 kl. 16:49

Jamen hvordan kommer Tante Oda så på sin netbank? Eller ordner sine offentlige sager, som hun ikke længere kan gøre på kommunen? Hun er ikke sikker på, hvordan hun pludselig skal hente og installere Chrome?

Det bliver ikke nemt at overbevise de ældre om, at Det Digitale Danmark er et fremskridt ;)

3
27. august 2012 kl. 17:07

Jamen hvordan kommer Tante Oda så på sin netbank? Eller ordner sine offentlige sager, som hun ikke længere kan gøre på kommunen? Hun er ikke sikker på, hvordan hun pludselig skal hente og installere Chrome?

Og når Tante Oda har installeret Chrome for at kunne gå sikkert i netbank, opstår det næste problem med det digitale Danmark.

Chrome har, meget fornuftigt, sin egen PDF reader i stedet for at bruge Adobes plugin, som jo er en anden stor sikkerhedsrisiko (Adobe PDF plugin, Adobe Flash plugin og Oracle Java plugin udgør en meget stor andel af sikkerhedsproblemerne).

Det er meget smart (bedre IT-sikkerhed for Tante Oda), men på borger.dk skal man bruge Adobe til PDF. Tante Oda skal således i gang med tweaks af Chrome ala dettehttps://www.borgeronline.dk/help/Chrome.htm

Det er ikke alle kommuner som bruger disse tåbeligt designede PDF formularer på borger.dk, men nogle gør, bl.a. Frederiksberg Kommune.

2
27. august 2012 kl. 17:00

Hvor sandsynligt er det lige at tante olga læser denne nyhed og bliver klar over det ? Det ville nok realistisk set kræve at netbanken skrev det som nyhed, og så tager det trods alt ikke mange ord for at hjælpe med at installere chrome ..