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

16 kommentarer.  Hop til debatten
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.
10. november 2021 kl. 12:45
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

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.

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:

Artiklen fortsætter efter annoncen

»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.«

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

Artiklen fortsætter efter annoncen

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.

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.

16 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
15
11. november 2021 kl. 12:03

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

14
11. november 2021 kl. 11:41

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.

13
11. november 2021 kl. 10:49

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.

11
10. november 2021 kl. 21:16

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.

5
10. november 2021 kl. 14:30

Der er tilfælde hvor copy paste af URLer fra Slack har introduceret non-printable unicode characters.</p>
<p>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.

4
10. november 2021 kl. 14:26

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 :)

3
10. november 2021 kl. 14:13

Disable Insane Unicode Effects

Jeg er sikker på at der kommer en spændende og oplysende debat om hvem det er der har hovedet under armen mht. et blankt tegn der er klassificeret som "bogstav" hhv. vælge at variabler kan starte med alt hvad nogen kan finde på at kalde et bogstav :-)

2
10. november 2021 kl. 13:30

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.

1
10. november 2021 kl. 12:49

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.