Gammel TrojanSource sårbarhed truer sikkerheden med Malware i stort set alt kode og programudvikling

En stor ny sårbarhed er fundet i langt de fleste programmer som oversætter læsbar kode til maskinkode. Sårbarheden giver mulighed for at man uden at vide det flytter problemet til millioner af brugere.

På University of Cambridge har et Forskerteam fundet en alvorlig sårbarhed i en lang række af de såkaldte compilere. Det er programmer der oversætter den kode en prorammør har lavet til et program. Der kan være tale om mindst 32 platforma. F.eks. et program der laver C kode om til en exe-fil.

Problemet beskrives i indledningen af forskerrapporten, der kan downloades i slutningen af dette dokument.

We present a new type of attack in which source code is maliciously encoded so that it appears different to a compiler and to the human eye. This attack exploits subtleties in text-encoding standards such as Unicode to produce source code whose tokens are logically encoded in a different order from the one in which they are displayed, leading to vulnerabilities that cannot be perceived directly by human code reviewers. ‘Trojan Source’ attacks, as we call them, pose an immediate threat both to first-party software and of supply-chain compromise across the industry. We present working examples of Trojan-Source attacks in C, C++, C#, JavaScript, Java, Rust, Go, and Python. We propose definitive compiler-level defenses, and describe other mitigating controls that can be deployed in editors, repositories, and build pipelines while compilers are upgraded to block this attack.

Sårbarheden betyder, at ondsindede hackere kan påvirke kode hos millionvis af udviklere og på den måde helt ubemærket vil kunne påvirke mange programmer. De var TrojanSource og dernæst Krebs on Security der først skrev om denne sårbarhed.

Unicode der startede i 1993 er en konventionel betegnelse for de almindeligt udbredte tegnsæt også for ISO-10646. Disse er kendtegnet ved at være helt eller delvist indeholdt i nuværende og historiske skriftsprog, IPA, node og algebra notationer. I 2015 var mere end 120.000 skrifttegn omfattet.

Kilde: ICARE.DK

Sårbarheden der er fundet ligger i kodestandarden Unicode. Unicode er et system der udveksler kode på tværs af de mange kodesprog til computerformat. Siden 2013 er der bevist løsninger der kan kompromitere bl.a. Windows Server. Så det er altså ikke helt sandt at problemet er nyt med UNICODE distribution.

Forskerne bag publikationen som du kan læse her, bemærker at udvikleren IKKE vil bemærke nogle fejl eller ændringer i den kode han ser på sin skærm foran sig, det er først når hans kode kompileres til et program at skaden sker.

“Hvis ændringen er logisk og subtil nok til at gå ubemærket igennem tests, så har en ondsindet hacker mulighed for at udnytte sårbarheden uden at blive opdaget,”

“Enhver udvikler der kopierer kode fra en usikker kilde ind i beskyttet kode kan utilsigtet kopiere en usynlig sårbarhed.”

siger Ross Anderson, der er en af forskerne bag opdagelsen.

Udviklere kan også utilsigtede komme til at hente skadelig kode ind i programmer, hvis de ikke er forsigtige lyder advarslen.

Læs mere om denne sårbarhed her i dette PDF dokument:

Kilde: trojansource.codes

Nicholas Weaver, der er en lektor ved datalogi afdelingen ved University of California, Berkeley, sagde at Cambridge forskningen præsenterer:

“en meget enkel, elegant sæt af angreb, der kan gøre angreb på forsyningskæder meget, meget værre.” og “Det er allerede svært for mennesker at fortælle ‘det er OK’ fra ‘dette onde i kildekoden,” og “Med dette angreb kan du bruge skiftet i retningsbestemthed i f.eks. Arabisk til at ændre, indsmugle eller iværksætte scripts.

Man møder modstand når man vil indrapporte sikkerhedshuller, der er ikke en standard formular, hvilket gør det svært at fortælle alle om sikkerhedshuller

Den sidste halvdel af Cambridge papiret er en fascinerende studie om kompleksiteten i at orkestrere sårbarhed offentliggørelse med så mange berørte programmeringssprog og software virksomheder. Forskerne sagde, at de tilbød en 99-dages embargo periode efter deres første offentliggørelse for at tillade berørte produkter, der skal repareres med softwareopdateringer.

“Vi mødte en række svar lige fra lappe forpligtelser og bug dusører til hurtig afskedigelse og henvisninger til retspolitikker,” forskerne skrev. “Af de nitten softwareleverandører, som vi engagerede os med, brugte syv en outsourcet platform til at modtage sårbarhedsoplysninger, seks havde dedikerede webportaler til sårbarhedsoplysninger, fire accepterede afsløringer via en PGP-krypteret e-mail og to accepterede oplysninger kun via ikke-PGP-e-mail. De bekræftede alle modtagelsen af vores afsløring, og i sidste ende forpligtede ni af dem sig til at frigive et patch.”

“For os i ICARE lyder det som om, at disse virksomheder, ikke på en brugervenlig og ensartet måde modtager underretninger fra de samfund der beskæftiger sig med at finde sikkerhedshuller. Sagt på en anden måde, det er overordentligt svært at rapportere et sikkerhedshul så stort og gennemgribende som dette til alle. Derfor er hullet stadigt muligt at udnytte, på trods af 99 dages hensynsfuldhed fra forskerne. Det lader heller ikke til, at modtagere af denne information ved hvad det kan betyde og hvad det betyder for hele verdens IT og Net sikkerhed ELLER hvordan man skal forsvare sig.

Siger Michael Rasmussen, direktør i ICARE.DK, der er en leverandør af sikkerhedsløsninger, kryptering og malware/ransomware beskyttelse.

Elleve af modtagerne havde bug bounty programmer, der tilbyder betaling for sårbarhed afsløringer. Men af disse, betalte kun fem dusører, med en gennemsnitlig betaling på $2,246 og en række $4,475, skriver forskerne.

Anderson skriver dog at omkring halvdelen af de organisationer, der opretholder de berørte computer programmeringssprog har lovet patches. Andre trækker tiden ud.

“Vi vil overvåge deres indsættelse i løbet af de næste par dage,” Anderson sagde. “Vi forventer også handling fra Github, Gitlab og Atlassian, så deres værktøjer bør opdage angreb på kode på sprog, der stadig mangler bidi karakter filtrering.”

Illustration: Jeff Wright (C) 2021 med tilladelse

Med hensyn til, hvad der skal gøres ved Trojan Source, opfordre forskerne at regeringer og virksomheder, der er afhængige af kritisk software, skal lægge pres på dem for at gennemføre passende forsvar, og sikre, at eventuelle huller er dækket af kontrol alle steder i organisationer og i Open Source miljøerne.

“Det faktum, at den trojanske kilde sårbarhed påvirker næsten alle computersprog gør det til en sjælden mulighed for et system-dækkende og økologisk gyldig cross-platform og cross-vendor sammenligning af svar,” papiret konkluderer. “Da kraftfulde forsyningskædeangreb nemt kan iværksættes ved hjælp af disse teknikker, er det vigtigt for organisationer, der deltager i en softwareforsyningskæde, at implementere forsvar.”

Weaver kaldte forskningen “rigtig godt arbejde med at stoppe noget, før det bliver et problem.”

“Den koordinerede offentliggørelse er en lektion er en glimrende efterforskning i, hvad det kræves at løse disse problemer,” sagde han. “Sårbarheden er reel, men fremhæver også den endnu større sårbarhed af skiftende stand af afhængigheder og pakker, at vores moderne kode er afhængig af.”

Rust har imidlertid udgivet en sikkerhedsmeddelelse  for denne sikkerhedssvaghed, som spores som CVE-2021-42574 og CVE-2021-42694. Yderligere sikkerhedsmeddelelser fra andre berørte sprog vil blive tilføjet som opdateringer her.