Open source-patch blotlagde kritisk sårbarhed i Android

Illustration: Android Logo
Længe før opdateringer var klar til alverdens mobiltelefoner, fremgik det af den åbne kildekode bag Android, hvori en del af den såkaldte Stagefright 2.0-sårbarhed bestod.

Rettelser i den åbne kildekode bag Android afslørede en kritisk sårbarhed i styresystemet længe før, at informationer om den officielt blev offentliggjort. Og endnu længere inden, sikkerhedsopdateringer begynde at rulle ud til alverdens mobiltelefoner.

Som bekendt dukkede der tidligere på året flere kritiske sårbarheder op i Android-styresystemet, herunder den såkaldte Stagefight 2.0-sårbarhed. Den bevirker, at det blandt andet via en særligt udformet MP3-fil er muligt at kompromittere eksempelvis en telefon.

Det er Joshua Drake fra it-sikkerhedsvirksomheden Zimperium, der opdagede og rapporterede Stagefright 2.0-sårbarhederne, ligesom han også opdagede flere af de oprindelige Stagefright-sårbarheder, der i princippet gjorde det muligt at kompromittere en telefon med en særligt udformet MMS.

Af en tråd på Android-projektets issue-tracker fremgår det, at Drake rapporterede Stagefright 2.0-sårbarheden benævnt CVE-2015-6602 17. august 2015. Den konkrete sårbarhed rettede Google med en softwareopdatering til Nexus-enhederne i starten oktober.

Læs også: Kritiske opdateringer ignoreres: Millioner af Android-telefoner fyldt med sikkerhedshuller

Googles Android-partnere blev notificeret om sårbarhederne senest 10. september, altså omkring en måned før Nexus-udrulningen.

Poster Proof of Concept

En tråd som den under Android-projektets issue-tracker bliver startet via en særlig formular til rapportering af sikkerhedsproblemer i Nexus-enheder eller i Android. Sådan en tråd er ikke offentligt tilgængelig på rapporteringstidspunktet, men kan blive det senere, fremgår det af Googles beskrivelse på formularens hjemmeside.

I tråden kan man se, hvordan Google i første omgang vurderer sårbarheden til at være moderat. Herefter poster Drake et såkaldt Proof-of-Concept (PoC), der ikke alene består af en problematisk mp3-fil, men også et stump Python-kode, der kan bruges til at generere filen med.

I den forbindelse opfordrer Drake Google til at gå stille med dørene 'due to the sensitivity of this data'.

Umiddelbart efter han har postet PoC, ophøjer Google sårbarheden til 'kritisk'. Google har nogle retningslinjer, som denne kategorisering foregår efter.

Den 19. august bemærker Joshua Drake, at de rettelser, som han oprindeligt foreslog i Android-koden for at lukke sårbarheden, nu kan læses af enhver, da Google har sendt rettelserne til koden.

»Jeg er utilfreds med, at embargoen ikke blev honoreret, men sådan er livet,« konstaterer han og linker til den offentlige rettelse, der skal lukke Integer-overflowet i et metodekald i libutils/String8.cpp.

Google undskylder

Herefter undskylder Google:
»Hej Josh. Vi er virkeligt kede af, at fixet røg direkte ind i AOSP (Android Open Source Project, red.). Vi ønsker fortsat at behandle dette issue som fortroligt, hvis muligt,« skriver en person fra Google.

Herefter oplyser personen om, at Google planlægger at inkludere et fix og detaljer om sårbarheden i en bulletin til partnere omkring 8. september, og at (nyere) Nexus-enheder forventes at blive opdateret i oktober.

Og lidt længere nede i tråden kan man se, at Joshua Drake får en dusør for at have spottet sårbarheden på 4.000 dollars. Google har nogle faste takster, som sårbarheder takseres efter.

Læs også: Sådan belønner Google sårbarheder i Android

I princippet har det altså været muligt for folk med den rette knowhow at opsnuse rettelsen, da koderettelsen blev offentlig tilgængelig i midten af august - og altså længe inden producenter er begyndt at overveje at lukke hullet på de enheder, der er så priviligerede at modtage opdateringer i forhold til den slags sårbarheder.

Bitdefender: Google gjorde det rigtige

Ifølge malware-analytiker Bogdan Botezatu fra rumænske Bitdefender har Google gjort det rigtige ved at sende en rettelse til den åbne kildekode omgående i stedet for at holde informationerne om sårbarheden fortrolig, indtil partnere og Google selv var klar med Android-images til telefonerne.

»Hvad Google angår, så gjorde de præcist, hvad der forventes af en softwareleverandør: integrerer en patch hurtigt. Dette er en af de første ting, en ingeniør vil gøre, konfronteret med en sårbarhed så alvorlig,« oplyser Bogdan Botezatu via mail.

Han peger på, at Android bliver anvendt i meget andet end mobiltelefoner. Eksempelvis i videoafspillere, diverse smart-enheder og selv biler.

»Og i modsætning til mobiltelefoner, så får Android-enheder der kører i embeddede miljøer ikke ofte opdateringer. Der er så mange modeller, der dukker op på en daglig basis, at Google sikkert har hastet patchen igennem for at sikre sig, at hvem der end måtte begynde på en ny model netop nu får en Stagefight-fri version af AOSP-koden,« fortæller Bogdan Botezatu.

Her sidder nogen måske og spekulerer på, om open source-projekter som Android så ikke risikerer at være en invitation til hackere, da det i projekternes natur er muligt for enhver af følge med i koderettelser, også i forhold til sårbarheder. Og altså rettelser der kan være relativt langsomme om at finde vej ind i eksempelvis en mobiltelefon.

Poul-Henning Kamp: Der er ikke en god løsning

Version2-blogger Poul-Henning Kamp er involveret i open source-projekterne cache-serveren Varnish og styresystemet FreeBSD.

»Open source er kun forskelligt fra closed source i den forstand, at det er hurtigere for folk at studere, hvad hullet kunne bruges til, hvis de ikke først skal disassemblere den binære kode,« skriver han i en mail.

Når det er sagt, mener Poul-Henning Kamp ikke, closed source forhindrer professionelle kriminelle i at skille koden ad og se, hvori eventuelle sårbarheder består.

I den forbindelse nævner han en konkurrence, hvor en gruppe med den rette know-how skilte koden til et program ad på 72 timer. Programmet var vel at mærke skrevet til en CPU, der ikke eksisterede nogen dokumentation til.

Overordnet set mener Poul-Henning Kamp ikke, der er forskel på at offentliggøre sårbarheder i forbindelse med patching af kode og så offentliggørelse af sårbarheder i al mulig anden - og potentielt udbredt - teknologi.

»Hvad ville Ruko gøre hvis de opdager, at alle kan købe en bestemt skruetrækker i Silvan og åbne alle deres låse-cylindre?,« skriver han i en mail og tilføjer:

»Der er ikke nogen ‘rigtig’ løsning, der er ikke engang nogen ‘god’ løsning, der er faktisk dårligt nok noget der er ‘en løsning’, når det kommer til stykket: Det er altid en ‘konkret vurdering’ af pro og contra, ofte i bedste Macbeth stil.«

I forhold til det konkrete tilfælde med CVE-2015-6602 peger Poul-Henning Kamp på, at Google eksempelvis kan have vidst, at en eller anden stor producent var lige ved at fryse Android-softwaren i deres næste store produkt. Og at en sådan viden kan have talt for at patche stort set omgående, så et givent produkt ikke bliver langet over disken til forbrugerne med en kendt og kritisk sårbarhed.

»Hvad vi kan sige med sikkerhed, er at vi meget sjældent får en kopi af det komplette beslutningsgrundlag, der er altid en masse af den slags ‘insider’ viden involveret,« skriver Poul-Henning Kamp.

Selvom Google de facto offentliggør sårbarheden og efterfølgende undskylder i debattråden og beder Joshua Drake om, at sårbarheden fortsat bliver holdt fortrolig, så vurderer Poul-Henning Kamp ikke, der er noget, der tyder på, at det skulle være en fejl, at Google laver et offentligt commit til AOSP og dermed potentielt afslører sårbarheden.

Version2 ville gerne have haft en kommentar fra Google i forhold til, at rettelser i forhold til sårbarheder åbenbart hurtigt bliver tilgængelige i den åbne Android-kode. Virksomheden har ikke reageret på vores henvendelse.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere