Ny unicode-sårbarhed kan ramme open source-projekter: Men ekspert frygter ikke storskala-angreb

Illustration: MediaWhalestock | Bigstock
En gruppe forskere fra Cambridge University advarede for nylig om en sårbarhed i kodningsstandarden Unicode, der gør det muligt at implementere en bred vifte af angreb.

Sårbarheden har fået navnet ‘Trojan source’, netop fordi den kan implementeres i sourcekoden igennem ‘bidi-funktionen’ i kodningsstandarden unicode, der dækker over 143.000 karakterer og 154 kodesprog.

Derfor kan den komme til at påvirke næsten alle compilere og mange softwaremiljøer. Sårbarheden findes i unicode-standarden, der tillader computere at udveksle information uanset sprog. Nærmere bestemt i ‘bi-directional’-algoritmen, også kaldet ‘bidi’, der kan vende læseretningen om, så kode både kan læses fra venstre mod højre og omvendt.

»Hvis du skriver noget ondsindet kode på en snedig måde, så kan du få det til at ligne en harmløs funktion,« fortæller Thomas Wong, der er teknisk direktør i det danske it-sikkerhedsfirma Improsec.

Læs også: Se de mest udnyttede sårbarheder i 2020

Han fortæller, at man ved at bruge bidi-funktionen kan gemme ondsindet kode som en harmløs funktion i ens kode, som compileren, fordi bidi-funktionen vil bytte om på tegn, vil læse anderledes end man vil ved at kigge på koden. Bidi-funktioner kan skrives ind som kommentarer eller strenge, hvorfor det ikke er sikkert, at man vil fange det i et manuelt review:

»Compileren læser koden på en anden måde end man selv ville læse den. Så hvis man udelukkende bruger manuelt review, så kan man reelt risikere at der bliver sneget ondsindet kode ind,« fortæller han.

Open-source projekter er det åbenlyse eksempel

Spurgt ind til hvor han kunne forestille sig, at sårbarheden ville kunne bruges, fortæller Thomas Wong, at han særligt ser ét åbenlyst eksempel:

»Et åbenlyst eksempel kunne være de mange open source projekter, hvor alle kan bidrage med kode, som manuelt bliver verificeret og så skudt ud til den mainstream kodebase. Det ville jo være ret uheldigt at få distribueret ondsindet kode på den måde.«

Læs også: Seneste meltdown-hul i cpu’er: Crosstalk kan lække data på tværs af kerner

Thomas Wong fremhæver Linux-kernen som eksempel på et open-source projekt, hvor sårbarheden ville kunne komme i spil.

Han fortæller, at i og med at man kan skrive sårbarheden ind i koden, så er der i teorien meget få begrænsninger for, hvad den potentielt kan bruges til:

»Det er nærmest kun fantasien, der sætter grænser for, hvordan man kunne udnytte den her sårbarhed. Det kan være bypass af autorisation, eksempelvis.«

Automatiserede værktøjer kan fange sårbarheden

Thomas Wong fortæller, man vil kunne undgå, at sårbarheden bliver implementeret, hvis man bruger et automatiseret review-værktøj:

»I et source code-review, som er baseret på automatiserede værktøjer, vil værktøjerne kunne spotte den rigtige eller ondsindede kode.«

De fleste automatiserede værktøjer vil nemlig læse koden ligesom compileren vil læse den, og den vil dermed kunne opdage eventuelle forsøg på at skrive en skjult sårbarhed ind ved hjælp af bidi-funktionen, ifølge Thomas Wong.

Læs også: Gode råd fra sikkerhedsekspert: »Det er muligt at beskytte sig mod angreb«

En mærkværdig sårbarhed

Thomas Wong mener, at det er en interessant sårbarhed, fordi den kan implementeres direkte i kodebasen. Men han tror ikke, at den kommer til at blive et omfattende problem:

»Det er lidt en 'curiosity', og så er den interessant, fordi den rammer næsten alle kodesprog,« fortæller han og fortsætter:

»Cambridge frigav deres information om sårbarheden sidste mandag, så det er svært at sige, om det nogensinde er sket. Var det sket på et ‘high profile’ projekt, så havde vi nok hørt om det tidligere.«

Grundet de forudsætninger, der skal være til stede, for at sårbarheden kan implementeres, så tror Thomas Wong ikke, at sårbarheden kommer til at blive brugt mod store projekter:

»Sårbarheden er interessant og den åbner helt sikkert op for nogle muligheder, men jeg forestiller mig ikke, at den kommer til at blive brugt til storskala-angreb, de nødvendige omstændigheder taget i betragtning.«

Thomas Wong fortæller, at problemet kan undgås ved at slå bidi-funktionen fra. Han mener desuden, at man hurtigt vil kunne indarbejde et forsvar mod sårbarheden i compilers.

Forud for Cambridge Universitys offentliggørelse af sårbarheden, havde forskerne advaret en række organisationer, hvor nogle allerede er på vej med patches.

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

Der er faktisk lige dukket endnu en op i samme familie: Et obskurt asiatisk blanktegn regnes som et bogstav og kan derfor være første (og eneste) tegn i en usynlig variabel i JavaScript:

https://certitude.consulting/blog/en/invisible-backdoor/

Den gode nyhed er at Github med en grep -r kan afgøre om det allerede er blevet udnyttet.

Den dårlige er at den USAnske automatreaktion er at gå tilbage til ren ASCII.

  • 9
  • 0
#2 Martin Dahl

Der er tilfælde hvor copy paste af URLer fra Slack har introduceret non-printable unicode characters.

Man skal lige være vågen for at fange den slags.

Jeg blev lidt trist over at finde ud af, at der ingen indstilling er i VS Code, som kan tvinge visning af disse tegn, på samme måde som visning af tvungent linieknæk.

Jeg er lidt ligeglad med hvad en Unicode standard mener og synes, jeg vil bare gerne have en default setting sat i min texteditor, som hedder Disable Insane Unicode Effects, så hver byte eller word fylder netop een fixed width character i editoren. Altid.

  • 6
  • 0
#4 Martin Dahl

Jeg er sikker på at der kommer en spændende og oplysende debat

Yes, det er nemlig vigtigt at supportere emojier både for en vandmelon og Storebæltsbroen.

Eller hvad med en character, som skal springes over også i en HEX editor?

Og her kommer en glyph, som kun korrekt renderes ved at installere en bitcoin miner direkte i MBR.

Held og lykke med at skrive regexs mod kildekode, det bliver en fest :)

  • 2
  • 1
#5 Ditlev Petersen

Der er tilfælde hvor copy paste af URLer fra Slack har introduceret non-printable unicode characters.

Man skal lige være vågen for at fange den slags.

I gamle dage, kunne man i nogle BASIC-versioner skrive backspace eller lignende, så man kunne skjule dele af programmet for andre (læste jeg dengang - min maskine kunne ikke). Om det blev brugt seriøst, ved jeg ikke. Åbenbart er ideen stadig brugbar.

Jeg læste for nogen tid siden i det tyske C'T, at en fil med et usædvanligt blanktegn som navn, kunne får Windows til at loop'e, når den indekserede disken. Et blanktegn er ikke bare et blanktegn.

Jeg kan også forestille mig, at man med brug af kyrilliske bogstaver kan få et program til at køre en anden funktion, gemt i et fjernt bibliotek, i stedet for den, som man tror, der kaldes.

  • 3
  • 0
#10 Poul-Henning Kamp Blogger

Det havde vi da også allerede i ASCII MS DOS: codepage 850/865, tegnet med ASCII kode 250 var et blankt tegn som man kunne gemme som filnavn, f.eks som eksekverbar fil.

Det mest sjov jeg nogensinde har haft med en floppy, var da jeg uden at tænke over det havde skrevet en fil med navnet "read:me" i et FAT filsystem og givet den til en Windows-bruger :-)

(I FreeBSD er kolon ikke "magisk", heller ikke i msdosfs)

  • 2
  • 0
#11 Ditlev Petersen

og givet den til en Windows-bruger :-)

Og hvad skete der så? Gik maskinen i gang med at lede efter et drev, eller var filen bare umulig at røre?

Igen anekdotisk, så læste jeg engang om det trick, med Norton et-eller-andet at lave en fil med et navn med et mellemrum i i et FAT-system. Hvad formålet var, husker jeg ikke, men nok noget kopi-sikring, da filen næppe kan kopieres (eller slettes). Men godt læses fra et program, der ved, at den skal være der.

  • 0
  • 0
#12 Poul-Henning Kamp Blogger

Og hvad skete der så? Gik maskinen i gang med at lede efter et drev, eller var filen bare umulig at røre?

Skal vi bare sige at fejlbeskederne ikke var specielt hjælpsomme ?

Jeg kan ikke huske hvilken version af Windows det var, men det faktum at DIR gladeligt viste filnavnet med kolon mens alle forsøg på at få fat i filen blev mødt med varianter af File not found gav en del hovedbrud...

  • 2
  • 0
#13 Sune Marcher

Jeg er lidt ligeglad med hvad en Unicode standard mener og synes, jeg vil bare gerne have en default setting sat i min texteditor, som hedder Disable Insane Unicode Effects, så hver byte eller word fylder netop een fixed width character i editoren. Altid.

"Disable Insane Unicode Effects", lyder som en nice feature, men IMHO er "én byte én character" ikke den bedste løsning – jeg kan godt lide at mine editors har UTF-8 support og kan rendere både "international" tekst og emojis, så noget i stil med WordPerfects "vis koder" ville være at foretrække.

  • 1
  • 0
#14 Martin Dahl

jeg kan godt lide at mine editors har UTF-8 support

Helt enig, men i en editor skabt til kode er det alligevel vildt at non printable characters ikke kan ses.

Måske Insane Unicode Effects Settings skal være en drop down:

A) Enable Insane Unicode Effects ( Here be dragons ) B) Render non printable characters as square glyph X C) Render non printable characters as square glyph X and convert watermelons and other emojis to square glyph Y

Jeg ved godt at djævelsen ligger i detaljen, og at mange sprog benytter sammensætning af apostroffer og lignende ornamenter. Og selvfølgelig skal man kunne:

var min_var = "Ål, bête, oĩkoi";

Det er præcis den der "vis koder" oplevelse, når man skal identificere linieknæk, som mangler. I det mindste i VS Code. I det mindste for non printable chars.

  • 3
  • 0
#15 Morten Saxov

fil med et navn med et mellemrum i i et FAT-system

Det kunneman godt. Havde et tekstbehandlings program i start 90'erne, der også understøttet mellemrum i filnavne i FAT.

Jeg fik oprettet sådan et dokument. Den eneste måde jeg kunne kopiere/rename det dokument på, var vi at sikre jeg kunne fange det med wildcards, fx copy *.txt. Men det lykkes at både kopiere og rename det via MS-DOS 5 eller 6

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