Hvordan får man et konventionelt sprænghoved til at se ud som et atomsprænghoved, når det bliver scannet? Det var opgaven i årets udgave af konkurrencen Underhanded C, og den blev vundet på et typecasting-trick, skriver The Register.
Underhanded C går ud på at snige skjulte funktioner ind i et program og på den måde udforske, hvordan man kan bygge bedre sikkerhed ind i software.
I dette tilfælde var oplægget en fiktiv atomnedrustningsaftale, hvor to nationer var blevet enige om at skrotte et antal atomare sprænghoveder.
Ingen af nationerne var imidlertid interesseret i at give den anden direkte adgang til at se indmaden i sprænghovederne, men ville alligevel verificere, at modparten skrottede det aftalte antal.
Derfor skulle en scanner måle mængden af fissionsmateriale i sprænghovedet og ved hjælp af software skulle det vurderes, om der var tale om et atomart sprænghoved, der skulle skrottes. Scanneren skulle blot returnere et ja eller nej.
Opgaven lød på, at hvis en part var interesseret i at snyde og skrotte et konventionelt sprænghoved i stedet for et atomart, hvordan kunne det så gøres, uden modparten opdagede det?
Løsningen fra Linus Åkesson gik ud på at lave en typecasting mellem de to typer kommatalsvariable double og float. De lagres som henholdsvis otte bytes og fire byte, når programmet køres på 64-bit x86 og 32-bit ARM.
Ved kun at lave typecastingen i én del af programmet kunne et array af double-kommatal blive sendt til en funktion, der forventede et array af float-kommatal. Dermed ville data blive læst forkert, fordi en otte bytes double ville blive læst som to fire bytes floats.
Dermed ville det være muligt at få et konventionelt sprænghoved til at ligne et atomart sprænghoved ved blot at inkludere en lille mængde fissionsmateriale på en måde, der ville give en falsk positiv.
Løsningen er simpelthen fantastisk godt fundet på, og efter min mening den bedste i de år konkurrencen har kørt.
Fejlen vil være meget vanskelig at opdage, og selv hvis den bliver fundet, så vil den ligne en tanketorsk -- og man vil kunne slå det hen med at omstændighederne for at fejlen får betydning stort set aldrig vil være der i praksis.
Med mindre altså nogen kender fejlen og udnytter den bevidst...
En af kriterierne er "... writing a program that would pass a code review ...".
Hvor jeg arbejder laver vi kode review på alt, og da jeg læste kildekoden var noget af det første, jeg tænkte "øøøh float_t er da ca. verdens dårligste navn til en intern type".
Det ville jeg med garanti have krævet omskrevet. Ikke fordi jeg indså, at det var exploiten (jeg kunne ærlig talt ikke finde den... havde så heller ikke læst artiklen til ende), men fordi navnet er forvirrende, når nu int64_t, uint8_t wchar_t, osv osv, er defineret i C++ standarden og "rimer" på det.
Version2 er en del af Jobfinder - Danmarks største job- og karrieresite for ingeniører og it-professionelle.
Seneste debat / 24 timer