MIT-program debugger med lånt kode

Forskere fra MIT har udviklet et program, der låner kode fra anden software og bruger det til at reparere bugs i et ramt program. Vi må prøve det i praksis, før vi jubler, mener ekspert.

Lån kode i 'donor-software' til at udbedre bugs i den software, du sidder med lige nu. Det er kort sagt princippet bag programmet CodePhage, som en række forskere fra det amerikanske teknologi-institut MIT har præsenteret.

Forskerne kalder de to stykker software, som programmet kræver, for henholdsvis ‘modtager’ og ‘donor’. Dernæst indskyder CodePhage det crash-sikre input i donor-softwaren og følger de operationer, som donor-softwaren foretager. Dette oversættes til de rene logiske operationer, som opføres i en symbolsk log over, hvordan logikken i donor-softwaren virker.

Det betyder altså, at CodePhage ved begyndelsen får to inputs: ét, der får det hullede software til at crashe, og ét, der ikke gør. Dernæst går CodePhage til et andet stykke software, der kan indeholde den funktionalitet, som ville udbedre problemet i det første stykke software.

Peter Toft, der er algoritme-designer hos Fingerprints Cards og som løbende har blogget om debugging på Version2, er ikke helt oppe i skyerne over MIT's CodePhage.

»Det er en interessant idé at afprøve. Jeg er dog lidt skeptisk, fordi man angiveligt patcher med kode, man reelt set ikke har og ikke kender, med kildekode, som man så hugger fra donor-softwaren,« siger Peter Toft og uddyber:

»Risikoen for, at de to programmer har vidt forskellig interface, er stor, og så vil jeg sige, at chancen for, at en tredjepart kan verificere den patchede kode, er tilsvarende lav.«

Læs også: Sikkerhedshul i iOS gør det muligt at lokke iCloud-kodeord fra iPhone-brugere

Debugging har brug for effektivisering

Offentliggørelsen af CodePhage fandt sted ved en programmeringskonference i USA i denne måned, hvor folkene bag også viste en række screendumps fra deres testfase. Oplægget finder du her. Peter Toft har bladret nogle af de slides igennem og beholder stadig sin skepsis.

»Vi kan se, at det stadig er meget tidligt i forløbet, og vi mangler stadig svar på, hvor meget de egentlig har testet, og hvor succesfuldt programmet har været. Men det er helt klart en interessant udvikling, vi skal følge,« fortæller Peter Toft.

Han pointerer, at debugging trækker rigtig mange ressourcer og tid ud af softwareudviklerne, som i sagens natur kunne bruges på netop udvikling og ikke oprydning. Derfor er det især potentialet i effektivisering, som på sigt kan gøre programmer som CodePhage interessante.

Hvis CodePhadge virker optimalt, så er en anden fordel også, at programmet vil fungere, også selvom modtager- og donor-software end ikke er skrevet i samme sprog. Dernæst køres det crash-inducerende input i donor-softwaren, som CodePhage følger, indtil det identificerer en afvigelse fra det ‘sikre’ input.

MIT-forskerne hævder derfor, at programmører med CodePhage vil kunne spare store mængder tid på at lave opslidende sikkerhedstjek i koden, og på endnu længere sigt, mener de, at det kan betyde, at man fremover ikke længere behøver at skrive kode, der dækker over en funktionalitet, der allerede er skrevet.

Læs også: Dvale-trick gør det muligt at skyde persistent malware ind i BIOS på Mac-computere

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Poul-Henning Kamp Blogger

Det er fint at vise at det her er en teoretisk mulighed, men der er ingen ende på antallet af måder det er en helt forkert tilgang til sikkerhed.

Jeg vil meget hellere have indført produktansvar for software, så skal forsikringsselskaberne hurtigt få kvaliteten hævet dramatisk.

  • 6
  • 0
Patrick Moog

Jeg kan slet ikke forestille mig hvor store sikkerhedsforanstaltninger der skal laves i CodePhage før det kommer i nærheden af at kunne bruges seriøst.

Det bliver da uden tvivl det nye hotte at forsøge at få noget "ondt" kode sneget ind i populært donor-software?

Og ved at rette en bug med erstattet kode finder man jo ikke ud af hvad fejlen var og i hvilket omfang buggen ellers kan have skabt ravage?

  • 1
  • 0
Peter Toft

Det er helt skævt at et team mener at de kan fikse kode ved at lappe kode ind fra andre projekter uden at ane en kæft hvordan de skal køre unit-, integrations- og produktionstest.

Det er interessant, men det virker på mig som et eksamensprojekt, der får lidt for meget opmærksomhed ...

  • 2
  • 0
Rasmus Kaae

Jeg er helt enig i at man skal tage ansvar. Omvendt så viser præsentationen et meget simpelt og basalt eksempel med buffer overrun. Den slags simple ting kan måske godt automatiseres hvis codephage kan skabe kontekst.

Der findes dog allerede gode værktøjer til den slags, fx Boehms Memory Model.

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