Klassisk C-smutter åbnede stort sikkerhedshul hos Cloudflare

Illustration: leowolfert/Bigstock
Sikkerhedshullet hos den gigantiske fordeler af webtrafik skyldes et manglende check af en pointer.

Det var et '==', som skulle rettes til et '>=', der er den helt korte forklaring på, hvad der skete hos Cloudflare, som i denne uge rettede et sikkerhedshul, der har ramt millioner af sider på nettet.

Den fulde forklaring er mere kompliceret, men er værd at dykke ned i, fordi Cloudflare er en vigtig men også usynlig del af det internet, som hundredvis af millioner af brugere benytter hver eneste dag.

Læs også: Over fem millioner hjemmesider ramt af datalæk-bug

Cloudflare håndterer nemlig enorme mængder af webtrafik. Selskabet sørger for at fordele belastning og kapacitet mellem servere for de tjenester, som har behov for det, og selskabet beskytter også websteder mod eksempelvis DDoS-angreb.

Det betyder, at der er tusindvis af tjenester og millioner af sider, som passerer gennem Cloudflares servere på vejen mellem brugeren og webserveren, og et sikkerhedshul hos Cloudflare rammer potentielt alle disse sider - og det er kun Cloudflare, der kan gøre noget ved det.

Hul i gammel parser

Det var Googles sikkerhedsfolk, som blev opmærksomme på, at der i særlige tilfælde dukkede uventede data op, når visse sider passerede gennem Cloudflare. Google-folkene undersøgte sagen og orienterede Cloudflare.

Hos Cloudflare fandt sikkerhedsfolkene hurtigt ud af, at problemet lå i et program, som fortolker eller parser webtrafik. De fandt også ud af, at fejlen potentielt var meget alvorlig, fordi den kunne lække indhold fra servernes hukommelse, som kunne omfatte eksempelvis kodeord eller andre fortrolige oplysninger.

Tre specifikke produkter hos Cloudflare var påvirket, og den første midlertidige løsning var at slå dem fra i den kode, der kørte på Cloudflares globale netværk. Det var let nok for to af funktionerne, hvor der kunne sættes et 'kill flag', der fortalte systemerne, at de to funktioner ikke skulle være aktive. Den tredje funktion stammede imidlertid fra før, Cloudflare havde indført sådanne feature-flag.

Og det var netop denne blanding af nyt og gammelt, som var årsagen til problemerne. Sikkerhedshullet havde nemlig ikke altid været et problem, skriver Cloudflare i udredningen af hændelsen.

Problemerne opstod først, efter en ny parser var rullet ud som erstatning for den gamle. Det kan lyde selvmodsigende, men de tre pågældende tjenester hos Cloudflare brugte i visse tilfælde både den gamle og den nye parser, og det betød, at der var en pointer til en buffer, som ikke blev tjekket, og derfor kunne lave et overløb.

Lig med skulle have været større end eller lig med

Fejlen lå i C-koden til den gamle parser, hvor pointeren blev tjekket med '==' for at se, om den havde nået enden af bufferen. Problemet er, at det ikke tager hensyn til, at pointeren kan have passeret grænseværdien på et tidspunkt, hvor den ikke er blevet tjekket. Det kan fikses ved at ændre det til et tjek af, om pointer-værdien er større end eller lig med, altså '>='.

Det er en oplagt fejl, så hvorfor opdagede Cloudflare-udviklerne den ikke, da de skrev parseren i første omgang?

Teknisk set skrev de ikke selv den problematiske linje i C. De skrev nemlig parseren i Ragel, som oversatte til C. Der var altså et ekstra led, hvor udviklerne skulle have fortalt Rage, at der skulle være et tjek, når det blev oversat til C.

Bufferen kunne løbe over, når parseren eksempelvis gennemløb en webside, hvor der var en uafsluttet HTML-tag - noget som ifølge Cloudflare findes på 0,06 procent af alle de sider, som løber gennem Cloudflares netværk.

Sådan et overløb ville få parseren til at læse videre i hukommelsen, indtil den nåede sin maksimale størrelse på 4 kilobyte. Dermed ville den læse hvad som helst, der lå i hukommelsen, også eksempelvis krypteringsnøgler. Og det er netop ét af de mest alvorlige problemer, som Cloudflare efterfølgende var nødt til at tage hånd om, efter fejlen var fundet og rettet.

Cloudflare krypterer nemlig kommunikationen mellem selskabets servere. Ifølge Cloudflare er der ikke lækket nøgler til HTTPS fra kundernes sider, men den private nøgle til kryptering af trafikken internt i Cloudflare kunne kompromitteres via sårbarheden.

Måtte rydde op på søgemaskiner

Det er for så vidt ikke så problematisk, når Cloudflare var blevet opmærksom på fejlen, og kunne stoppe fremtidige læk af data - og så alligevel, for nogle af de data, fejlen havde blotlagt, kunne være havnet i søgemaskinernes cache. Derfor måtte Cloudflare gennemtrawle systemerne for at finde frem til, hvad der var blevet cachet og samarbejde med søgemaskinefirmaerne for at få fjernet data.

Derfor gik der også en uge, før Googles sikkerhedsfolk og Cloudflare offentliggjorde detaljer om hændelsen. Der skulle være tid til at rydde op og sikre, at der ikke var flere sikkerhedshuller gemt i den gamle kode.

Men hvorfor havde Cloudflare så både en ny og en gammel parser?

Forklaringen fra Cloudflare er, at den nye parser var skrevet og taget i brug på de nyere tjenester, men en tjeneste, som ikke bliver brugt så ofte i dag, benyttede stadig den gamle. Det drejer sig om Server Side Excludes, som bruges til at skjule dele af en sides indhold for klienter, der sidder på en IP-adresse med 'et dårligt omdømme'.

I denne sammenhæng kan det eksempelvis være en IP-adresse, som er sat i forbindelse med en bot, der bruges af spammere til at høste e-mailadresser eller telefonnumre fra hjemmesider. Det kræver dog, at kunderne sætter et særligt 'tag' om det indhold, der skal skjules, og derfor skal siden parses. Det var én af de opgaver, som den gamle parser stadig tog sig af.

Ligner Heartbleed - men kun én er ramt

Cloudflare-sikkerhedshullet har visse ligheder med nogle af de andre store sikkerhedshuller, som har skabt opmærksomhed de sidste par år. Ligesom i eksempelvis Heartbleed er der tale om, at data, der ligger i serverens hukommelse, kan blive tilgået, selvom det burde være beskyttet.

Og ligesom Heartbleed er der ikke tale om et enkeltstående softwareprodukt, men om en tjeneste, som bruges af millioner af sider på nettet. Sikkerhedshullet har i princippet også eksisteret i ubemærkethed i lang tid, da det manglende pointer-tjek var i parseren fra begyndelsen, men for Cloudflares vedkommende har det kun været et egentligt problem, efter de to parsere skulle arbejde side om side.

I modsætning til Heartbleed i OpenSSL, så er der her ikke tale om, at hundredtusindvis af webservere skal opdateres. Det er blot en enkelt leverandør, som skal opdatere sit netværk. Til gengæld viser det altså også, at en komponent i en enkelt stor leverandørs infrastruktur kan udgøre et stort sikkerhedshul for millioner af kunder.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (2)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Baldur Norddahl

selskabet beskytter også websteder mod eksempelvis DDoS-angreb

CloudFlare beskytter også såkaldte Booter sites som sælger DDoS-angreb. Stort set samtlige booter sites har valgt at være kunde hos CloudFlare. Det er de fordi folk der sælger DDoS angreb ikke kan lide konkurrence, så de angriber hinanden.

Hvorfor er CloudFlare interesseret i at beskytte folk der laver angreb? Åbenlyst fordi CloudFlare ikke har en interesse i at angrebene forsvinder. En variant af "det vil være ærgerligt hvis der skete noget med din butik".

Den officielle forklaring fra CloudFlare er at de går ind for ytringsfrihed, så de vil ikke lukke for sites på baggrund af indhold.

  • 3
  • 3
#2 Rasmus nix

Jeg tror, at version2's læsere vil foretrække engelske termer, i sammenhænge som "pointer til en buffer, som ikke blev tjekket, og derfor kunne lave et overløb." F.eks.Buffer-overflow...

  • 1
  • 0
Log ind eller Opret konto for at kommentere