ZeroDay i WiFi-chip gør det muligt at køre ondsindet kode på både iOS- og Android-enheder

Sikkerhedsopdateringer er tilgængelige, men ikke for alle.

Der er sjældent, at sårbarheder giver mulighed for fjernangreb mod smartphones. Endnu sjældnere er det med angreb, der virker mod både iOS- og Android-enheder. Og tilføjer man, at sårbarheden også åbner for malware, der spreder sig via netværk, altså netværksorme, så har man et temmelig enestående tilfælde.

Det er det som Nitay Artentein, en sikkerhedsforsker ved Exodus Intelligence skulle have fundet. Sårbarheden, der har fået øgenavnet Broadpwn, findes i WiFi-chipserien bcm43xx fra Broadcom.

Både Android og iOS-enheder

Ifølge Artenstein bruges disse chips blandt andet i alle Samsung Galaxy S modeller fra og med S3, Samsung Notes 3, de fleste Nexus-enheder fra og med Nexus 5, samt alle iPhone-modeller efter iPhone 5. Men mange andre enheder er sandsynligvis også berørt.

Det centrale problem synes at være, at disse WiFi-chips, i modsætning til smartphonens centrale processorer, ikke bruger ASLR.

ASLR (Address Space Layout Randomization) er en central sikkerhedsmekanisme i moderne processorer, som gør det sværere for angribere at udnytte sårbarheder i software, fordi den del af hukommelse, der bruges af både eksekverbar kode og data, er vilkårligt udvalgt og dermed varierer fra tid til anden.

I bcm43xx-chips skal al hukommelse desuden have RWX-tilladelse. Det vil sige at enhver proces kan læse, skrive og udføre kode overalt i hukommelsen.

Øgede privilegier

Når man først har formået at køre stabilt på Broadcom-chippen, som altså er ansvarlig for behandlingen af ​​al Wi-Fi-trafik, vil det næste skridt være at opnå rettigheder til at køre kode på applikations-processoren til enheden.

Artenstein beskriver flere tilgange til, hvordan dette kan gøres.

“Broadpwn er et komplet fjernangreb mod Broadcoms bcm43xx-familie med WiFi chipset, som tillader afvikling af kode i applikationsprocessoren i både Android og iOS. Det er baseret på en kraftfuld zero-day sårbarhed, der tillod os at udnytte den til pålideligt at køre en koden til et fjernangreb, skriver Artenstein.

Sikkerhedsopdateringer

Manglen på ASLR i WiFi-chips er det lidt sent at gøre noget ved, når det gælder eksisterende enheder.

Både Apple og Google har dog i løbet af juli kommet med sikkerhedsopdateringer til henholdsvis iOS og Android, der i alt fald skulle forhindre Broadpwn-angrebet.

Men Googles sikkerhedsfiks gælder imidlertid kun for selskabets Nexus og Pixel-enheder. Leverandører af andre enheder er selv ansvarlige for at implementere sikkerhedsopdateringer til de enheder, de leverer.

Fra det tidspunkt, hvor Google kommer med sikkerhedsopdatering til Android, kan det tage ganske lang tid, før andre leverandører ruller deres egne sikkerhedsopdateringer ud.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (9)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Ju Sa

"Sikkerhedsopdateringer er tilgængelige, men ikke for alle."

Derfor betegnes det stadigvæk som en zero-day. På de devices hvor der findes en opdatering er det korrekt at betegne det som en 1day men for de devices hvor patch ikke er tilgængeligt er det en zero-day indtil et patch kommer.

Michael Cederberg

Fejlen er rapporteret til at ramme BCM4354, BCM4358 og BCM4359. Fejlen ligger i firmwaren til Broadcoms chipset. Nu bliver jeg en smule bekymret, for når dette er en software fejl i noget kode der ikke specifikt er relateret til disse chips (det synes det ikke at være når man læser rapporterne), kunne andre broadcom wifi firmwares have samme fejl?

Routere bruger lignende chipsets og har lignende behov. Jeg tænker at samme fejl kunne findes i ældre routers der bruger Broadcoms wifi chipset, Og så er fanden løs, for rundt omkring i de små hjem står der store mængder routere som aldrig bliver opdateret og som lever meget længere end telefoner og tablets. Redningen for nogen kunne være at deres ISP holder routeren opdateret ... hvis ISP'en har ressourcer til det ...

Robert Winther

Derfor betegnes det stadigvæk som en zero-day. På de devices hvor der findes en opdatering er det korrekt at betegne det som en 1day men for de devices hvor patch ikke er tilgængeligt er det en zero-day indtil et patch kommer.

Udtrykket 'zero-day' er en reference til, hvor længe leverandørerne/producenterne har haft til at komme med en opdatering: Så længe de ikke kender til exploit har de haft 'nul dage'.

Når exploit er offentlig kendt, så har producenterne også mulighed for at lave en opdatering og derfor er det per definition ikke længere en 'zero day'.

Vi kan så diskutere om det stadig er en zero-day de første timer efter en exploit er offentliggjort, men det faktum at nogle leverandører/producenter har haft tid til at lave en patch må endeliggyldigt afgøre at den ikke længere kan betegnes som zero-day.

Jakob Damkjær

Der er påvirket af dette issue kan opdateres til en sikker version af styresystemet. Så det er kun Android dimser der muligvis ikke har sikkerhedsopdateringer ude.

Et resultat af den forfejlede sikkerhedsopdaterings politik google har kørt med i alle år som forsat vil udsætte Android brugere for unødvendig risiko...

Jacob Larsen

når dette er en software fejl i noget kode der ikke specifikt er relateret til disse chips (det synes det ikke at være når man læser rapporterne), kunne andre broadcom wifi firmwares have samme fejl?

Sikkert. Den slags firmware vil typisk blive lavet på en fælles kodebase med hardware-specifikke dele abstraheret ud. Kun Broadcom vil vide hvilke chips der er ramt, de må have fundet sårbarheden og lavet ny firmware for at der kunne distribueres fixes ud.

Jacob Larsen

Et resultat af den forfejlede sikkerhedsopdaterings politik google har kørt med i alle år som forsat vil udsætte Android brugere for unødvendig risiko...

Har i dette tilfælde intet med google at gøre. Fejlen ligger i firmwaren til hardware, det kan kun være producenterne der har ansvaret her. Eller reelt ikke, siden det eneste ansvar de har er i forhold til garanti/reklamationsret. Du kan regne med at de telefoner der stadig er dækket af garanti/reklamationsret vil få updates, og resten bliver ignoreret. Desværre er der ikke noget krav om hvor hurtigt sådanne updates skal distribueres ud.

Så ikke et google problem, men er mere et udslag i at forbrugerbeskyttelsen ved sikerhedshuller i embedded software er ikke-eksisterende. Som Michael Cederberg skriver ovenfor, så er der en kæmpe ubekendt i hvilke WiFi routere der er berørt af dette problem, siden de kan dele store dele af kode basen for deres firmware, og Broadcom chips er ret udbredt indenfor routere, især pga deres 1024 QAM proprietære extensions til WiFi standarderne.

Jacob Larsen

Fra det tidspunkt, hvor Google kommer med sikkerhedsopdatering til Android, kan det tage ganske lang tid, før andre leverandører ruller deres egne sikkerhedsopdateringer ud.

Artiklen laver en forkert antagelse her. Linux kernen (med drivere) og tilhørende firmware blobs til diverse peripherals er ikke en del af Android kode basen. De er en del af den platform som Android kører på, og som holdes opdateret (eller ikke) af de enkelte producenter. Så hvis google opdaterer disse dele på Nexus modellerne, så vil det ikke komme med i den Android pakke som de andre producenter laver opdateringer ud fra. Det vil til gengæld være noget de hver især skal få direkte fra Broadcom.

Nu har jeg ikke studeret fikset i detaljer, men den eneste ting der kan gøre det til googles ansvar at fikse kunne være hvis de har implementeret et workaround i wpa supplikanten eller Android framework koden.

Benny Lyne Amorsen

Google kunne have valgt en distributionsmodel ligesom PC-styresystemer, hvor alle telefoner kunne installeres fra samme medie. Ligesom Windows eller Ubuntu kan installeres på stort set alle PC'er, fra samme USB-stick.

Det gjorde de så desværre ikke, og dermed har vi den absurde situation i dag med Androids manglende sikkerhed.

Log ind eller Opret konto for at kommentere