Hundrevis av Java-baserte produkter rammet av samme sårbarhet

Alle må oppdateres hver for seg.

Sårbarheten som nå rammer en mengde Java-baserte produkter, finnes ikke i selve Java-installasjonen, men i et mye brukt tredjepartsbibliotek fra Apache.
Sårbarheten som nå rammer en mengde Java-baserte produkter, finnes ikke i selve Java-installasjonen, men i et mye brukt tredjepartsbibliotek fra Apache. Bilde: PantherMedia/Sergey Nivens
Harald BrombachHarald BrombachNyhetsleder
9. nov. 2015 - 11:33

Svært mange, kanskje over tusen, ulike Java-baserte programvareprodukter må nå oppdateres for å fjerne en alvorlig sårbarhet. Det inkluderer velkjente produkter som WebLogic, WebSphere, JBoss, Jenkins og OpenNMS.

Apache Commons

Dette skyldes at sårbarheten finnes i Apache Commons, et Java-bibliotek som åpner for enkel gjenbruk av mye brukte Java-komponenter.

Dessverre er det ofte slik at produkter som benytter for eksempel Apache Commons, har sin egen kopi av biblioteket, i stedet for å bruke en sentral og felles kopi på datamaskinen. Dette gjør at hvert produkt må oppdateres for seg.

Nå er det ikke heller ikke slik at den aktuelle sårbarheten er ny og fullstendig ukjent for alle. Ifølge Steve Breen i Foxglove Security ble det demonstrert et konseptbevis for utnyttelse av sårbarheten allerede i januar i år.

Men dette har tydeligvis gått de fleste hus forbi – også Apache Commons-prosjektet som først i går kunngjorde en plan om å løse problemet. Dette skal tilsynelatende gjøres ved at den sårbare funksjonaliteten, deserialisering av data i klassen InvokerTransformer, blir deaktivert som standard.

Også andre tilfeller: Mange berørt av bibliotek-sårbarhet 

Eksempelkode offentliggjort

I blogginnlegget presenterer Breen eksempelkode for hvordan alle de navngitte produktene kan angripes, slik at en angriper kan fjernkjøre vilkårlig kode.

Utviklere som bruker Apache Commons i sine applikasjoner, kan ifølge Breen allerede nå sørge for å fjerne sårbarheten ved rett og slett å slette InvokerTransformer.class-filen i jar-filen til biblioteket. Dette forutsetter dog at applikasjonen ikke bruker denne klassen til noe.

Ifølge ZDNet har Foxglove fått kritikk for å gå åpent ut med både sårbarheten og eksempelkoden, i stedet for å varsle i alle fall leverandørene av de navngitte produktene. I en Twitter-diskusjon med Jeff Gehlbach i OpenNMS Group, skriver Justin Kennedy hos Foxglove at selskapet ikke anså sårbarheten for å være en nulldagssårbarhet.

Les også: Derfor er sårbarheter i antivirus ekstra ille 

Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.