Sikker programudvikling med C++

Sikker programudvikling med C++

Share

I en verden af usikker software, guider vi dig til sikrere programmering i C og C++

I forrige nummer af Alt om DATA kiggede vi på, hvordan man kan bruge SQL-kode på en sikker måde. Denne gang ser vi på de udfordringer, der er for sikker programmering, når man bruger sprogene C/C++. Vi kiggede først på SQL, fordi mange af de tab af virksomhedsdata, vi ser for tiden i medierne, sker pga. af SQL-injections.

I dette nummer griber vi fat i sikker programmering med C/C++, fordi C/C++ sprogene kræver en ekstra indsats fra programmørens side, hvis ikke der skal være sårbarheder i koden. I Java eller C# vil de fejl, jeg beskriver i denne artikel, ikke kunne forekomme, for her er der hukommelseshåndtering fra den underliggende implementering af disse sprog.

Typiske fejl i koden

Lad os starte med at tage et kig på det klassiske eksempel på en fejl i et stykke C-kode. Kig på figur 1. I linje fire erklærer jeg et array af char-karakterer. I linje 5 skriver jeg en a-karak-ter til position nummer 150 i dette array.

Figur 1: Den forkerte måde at skrive til et array på.

Men jeg erklærede mit array til kun at være 100 karakterer langt, hvordan kan jeg det? Det kan jeg, fordi C som udgangspunkt ikke kommer med det, der kaldes for bounds checking. Det vil sige, at der ikke er noget tjek fra C’s side om, det data, jeg skriver til mit array, kan være i dette array. I princippet kunne jeg lave en streng af 200 karakterer og kopiere denne streng ind i min mem-variabel, og C ville glad og fro kompilere en exe-fil til mig uden nogen advarsler. 

Se også:  Hold øje med dit hjem fra din smartphone
Hvad vil der ske, hvis denne kode eksekverede på en maskine

Det kommer an på så meget, og er jeg ’heldig’, så vil de karakterer, jeg kopierer ind i mem, kun overskrive noget hukommelse, jeg selv allerede bruger. I værste fald vil karaktererne overskrive noget hukommelse, som andre programmer bruger, eller endnu værre, operativsystemet. Dette eksempel og diverse variationer af det, er en af grundene til de bufferfejl, som vi til stadighed ser i programmer fra de forskellige leverandører.

Fejrettelser

Der er heldigvis en løsning. Et eksempel kunne være det, du ser på figur 2. Her bruger jeg det samme char-array som før, men linje 5 har ændret sig. I linje 5 har jeg brugt funktionen fgets(). Fgets() i eksemplet læser, hvad en bruger skriver og putter det ind i min mem-variabel.

Figur 2: Her bliver der ikke skrevet mere til
arrayet, end det kan indeholde.

Fordelen ved fgets() er, at den ved, at mit mem-array kun er 100 karakterer langt, og derfor begrænser inputtet fra brugeren til kun at omfatte 100 karakterer. Brugeren kan skrive 200 karakterer, men fgets() vil kun putte de første 100 ind i mit mem-array. 

Se også:  Sandboxie: Kør dine nye programmer på den sikre måde

Både C og C++ kommer med diverse funktioner, der kan bruges i stedet for de metoder, der er sårbare overfor overskrivninger af f.eks. arrays, og flere kommer løbende til med de nye versioner af C og C++.

Hvorfor bliver disse funktioner så ikke brugt?

Det gør de også, men der findes et utal af kodelinjer i C/C++ i forskellige legacy systemer rundt omkring samt historiske linjer med kode, der ikke er blevet opdateret til de nyeste C/C++ kode standarder. Der er masser af gode grunde til, at denne kode ikke er blevet opdateret, det kan f.eks. være fordi, leverandøren ikke længere vedligeholder et kodebibliotek, eller fordi den kode, som leverandøren kommer med, ikke understøtter de nye standarder for C/C++, og vil kræve en større omskrivning for at virke med disse standarder.

I det sidste tilfælde kommer økonomi ind i billedet. Hvis ikke der er fundet sårbarheder eller fejl i et givet bibliotek, hvorfor så bruge ressourcer på at tilpasse dette de nye standarder?

Nu kan man naturligvis argumentere for og imod, om det er gode grunde, men uanset hvordan vi vender og drejer det, så er det økonomi, der er en styrende kraft i, hvordan en applikation bliver udviklet og vedligeholdt. Det samme gælder for et kode-bibliotek. Men tilbage til koden.

Del denne