Heartbleed logo is free to use, rights waived via CC0.

Hvordan oppsto Heartbleed problemet?

Hva er Heartbleed problemet, og hvordan oppsto det?

Heartbleed har vært mye diskutert de siste par ukene. En god forklaring på hva som skjer på en server som har heartbleed feilen er laget av nettsiden xkcd. Feilen oppstår på grunn av et problem i koden som har sine røtter i spesifikasjonen av SSL. I spesifikasjonen blir det definert hvordan en såkalt «heartbeat» skal foregå og hva slags data som skal sendes. Men i stede for å sende en request som er markert som en heartbeat request med et tilfeldig innhold av en gitt lengde sendes det en request som inneholder et tillegg til requesten, en såkalt «payload». Payloaden blir sendt som en tekst, hvor lengden blir lagret i en 2 byte Integer (16bit) som tillater maksimalt 65535 tegn.

Så lenge den som sender heartbeat requesten setter lengden av teksten  tilsvarede lengden av teksten som sendes er alt OK. Dersom requesten sender feil lengde skal requesten ikke besvares ifølge spesifikasjonen. Det er her feilen skjer i koden til biblioteket «openSSL». En tysk utvikler implementerte denne svar funksjonen i openSSL som del av sin doktor avhandling. I avhandlingen argumenterte han for at «payloaden» ikke trengs – men implementerte den allikevel ettersom spesifikasjonen definerer den.

«The format of the new messages can basically be arbitrary, because for keep-alive no further information than the message type is necessary. However, to make the extension as versatile as possible, an arbitrary payload and a random padding is preferred […]»

Han glemte imidlertid å sjekke om lengden av teksten tilsvarer den lengden som ble sendt med requesten. Etter at han var ferdig ble koden sjekket av en annen utvikler som heller ikke la merke til problemet.

Kodefeilen gjør at man kopierer det som ligger i minnet etter teksten – noe som endrer seg hver gang man gjør en ny request. Siden heartbeat kan sendes hele tiden, så lenge en annen heartbeat ikke prosesseres, kan man lese ut minnet fra maskinen i 64k byte biter. Siden minnet allokeres via operativsystemet kan stedet der teksten ligger variere veldig – og dermed også hva som er den påfølgende minnebiten. Det finnes heldigvis ingen kjent måte å bestemme hvilken del av minnet som leveres i svaret.

Fremtiden

Siden buggen tillater at man leser ut tilfeldige biter av minnet til maskinen må man gå ut ifra at all informasjon som har ligget i minnet til maskinen på et eller annet tidspunkt har blitt lekket og er dermed er kompromittert. Detter gjelder all login informasjon som brukerne har sendt, SSL nøkler som har blitt brukt osv. Det er derfor veldig viktig at:

  1. SSL nøkler som er brukt på kompromitterte maskiner tilbakekalles
  2. Maskinens programvare oppdateres til en versjon av openSSL som har rettet problemet
  3. Alle aktive påloggingssesjoner slettes/avsluttes ( cookies som inneholder påloggingsinformasjon kan også har lekket)
  4. Brukerne informeres om at tjenesten er rammet og at de bør bytte passord
  5. Brukerne bytter passord ved neste login dersom mulig

Perfect Forward Security som vei fremover

For alle som har satt opp serveren til å bruke «Perfect Forward Security (PFS)» som krypteringssystem er problemet mindre selv om maskinen har vært rammet. Grunnen er at selv om SSL nøkkelen har lekket, vil det ikke være nok informasjon til å de kryptere kommunikasjonen siden hver sesjon har sin egen nøkkel. PFS antas til å være svært sikkert – men er beklagelig vis lite brukt.

Er libreSSL løsningen?

Open BSD prosjektet har som reaksjon på problemet begynt en stor opprydningsaksjon som de har kaldt «LibreSSL». De har redusert størrelsen av kodebasen betydelig ved å kaste deler som ikke lenger er i bruk eller er unødvendige. En del av det er støtte for utdaterte hardware eller operativsystemer. Dessverre har de også kastet noen features som ga mulighet til å øke sikkerheten på – blant annet bruk av en ekstern RandomNumberGenerator(RNG). En slik RNG er sjelden i bruk – men sikkerhetsgevinsten kan være stort ifølge en tysk sikkerhetsekspert.

Uansett om dette er et problem eller ei – vil så store endringer kreve en god sikkerhetsreview og en lang stabiliseringstid før det kan brukes i applikasjoner som krever høy sikkerhet. Det kommer til å ta flere år før dette er klart. I mellomtiden vil sannsynligvis OpenSSL være ferdig med reviewen og grunnen til å ta i bruk LibreSSL vi ha blitt mye mindre.

Per jobber som senior konsultent hos Visma Consulting siden April 2012. Han har et sterkt interesse i it-sikkerhet. Dessuten er han opptatt av utviklingen innen konfigurasjonstyring.
Kontakt Per: