Cambridgen yliopiston tutkijat ovat julkaisseet tekniikan haitallisen koodin lisäämiseksi hiljaa vertaisarvioituun lähdekoodiin. Valmisteltu hyökkäysmenetelmä (CVE-2021-42574) esitetään nimellä Trojan Source ja perustuu tekstin muodostukseen, joka näyttää erilaiselta kääntäjälle/tulkijalle ja koodia katsovalle henkilölle. Esimerkkejä menetelmästä on havainnollistettu erilaisille kääntäjille ja tulkeille, jotka toimitetaan C:lle, C++:lle (gcc ja clang), C#:lle, JavaScriptille (Node.js), Javalle (OpenJDK 16), Rustille, Golle ja Pythonille.
Menetelmä perustuu erityisten Unicode-merkkien käyttöön koodikommenteissa, jotka muuttavat kaksisuuntaisen tekstin näyttöjärjestystä. Tällaisten ohjausmerkkien avulla jotkut tekstin osat voidaan näyttää vasemmalta oikealle, kun taas toiset - oikealta vasemmalle. Arkikäytännössä tällaisia ohjausmerkkejä voidaan käyttää esimerkiksi heprean tai arabiankielisten koodirivien lisäämiseen tiedostoon. Mutta jos yhdistät yhdelle riville rivit, joilla on eri tekstisuunnat, käyttämällä määritettyjä merkkejä, oikealta vasemmalle näytettävät tekstin kohdat voivat olla päällekkäin olemassa olevan, vasemmalta oikealle näytettävän tavallisen tekstin kanssa.
Tällä menetelmällä voit lisätä koodiin haitallisen rakenteen, mutta sitten tehdä tällä rakenteella olevasta tekstistä näkymätöntä koodia katseltaessa lisäämällä seuraavaan kommenttiin tai oikealta vasemmalle näkyvien kirjaimellisten merkkien sisään, mikä johtaa kokonaan eri merkit päällekkäin haitallisen lisäyksen päälle. Tällainen koodi pysyy semanttisesti oikeana, mutta se tulkitaan ja näytetään eri tavalla.
Koodia tarkastellessaan kehittäjä kohtaa merkkien visuaalisen järjestyksen ja näkee ei-epäilyttävän kommentin nykyaikaisessa tekstieditorissa, verkkokäyttöliittymässä tai IDE:ssä, mutta kääntäjä ja tulkki käyttävät merkkien loogista järjestystä ja käsittele haitallinen lisäys sellaisenaan kiinnittämättä huomiota kommenteissa olevaan kaksisuuntaiseen tekstiin. Ongelma vaikuttaa useisiin suosittuihin koodieditoreihin (VS Code, Emacs, Atom) sekä arkistoissa olevan koodin katselun rajapintoihin (GitHub, Gitlab, BitBucket ja kaikki Atlassian-tuotteet).
On olemassa useita tapoja käyttää menetelmää haitallisten toimien toteuttamiseen: lisäämällä piilotettu "return"-lauseke, joka johtaa toiminnon valmistumiseen etuajassa; kommentoimalla lausekkeita, jotka normaalisti näkyisivät kelvollisina rakenteina (esimerkiksi tärkeiden tarkistusten poistamiseksi käytöstä); muiden merkkijonoarvojen määrittäminen, jotka johtavat merkkijonon validointivirheisiin.
Hyökkääjä saattaa esimerkiksi ehdottaa muutosta, joka sisältää rivin: if access_level != "user{U+202E} {U+2066}// Tarkista, onko admin{U+2069} {U+2066}" {
joka näytetään tarkistusliittymässä ikään kuin pääsy_taso != “user” { // Tarkista, onko admin
Lisäksi on ehdotettu toista hyökkäysversiota (CVE-2021-42694), joka liittyy homoglyfien käyttöön, jotka ovat ulkonäöltään samankaltaisia, mutta merkitykseltään erilaisia ja joilla on erilaiset unicode-koodit (esimerkiksi merkki "ɑ" muistuttaa " a", "ɡ" - "g", "ɩ" - "l"). Samanlaisia merkkejä voidaan käyttää joissakin kielissä funktioiden ja muuttujien nimissä kehittäjien harhaanjohtamiseksi. Voidaan esimerkiksi määrittää kaksi funktiota, joilla on erilainen nimi ja jotka suorittavat erilaisia toimintoja. Ilman yksityiskohtaista analyysiä ei ole heti selvää, kumpaa näistä kahdesta toiminnosta kutsutaan tietyssä paikassa.
Turvallisuussyistä on suositeltavaa, että Unicode-merkkejä tukevat kääntäjät, tulkit ja kokoonpanotyökalut näyttävät virheilmoituksen tai varoituksen, jos kommenteissa, merkkijono-literaaaleissa tai tunnisteissa on parittomia ohjausmerkkejä, jotka muuttavat tulostussuuntaa (U+202A, U+202B, U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E ja U+200F). Tällaiset merkit tulisi myös nimenomaisesti kieltää ohjelmointikielen määrittelyissä, ja niitä tulisi kunnioittaa koodieditoreissa ja arkiston liitännöissä.
Lisäys 1: GCC:lle, LLVM/Clangille, Rustille, Golle, Pythonille ja binutilsille on valmistettu haavoittuvuuskorjauksia. GitHub, Bitbucket ja Jira korjasivat myös ongelman. GitLabin korjaus on käynnissä. Ongelmallisen koodin tunnistamiseksi on suositeltavaa käyttää komentoa grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/]' lähde
Lisäys 2: Russ Cox, yksi Plan 9 OS:n ja Go-ohjelmointikielen kehittäjistä, kritisoi liiallista huomiota kuvattuun hyökkäysmenetelmään, joka on ollut jo pitkään tiedossa (Go, Rust, C++, Ruby) ja jota ei otettu vakavasti . Coxin mukaan ongelma liittyy lähinnä tiedon oikeaan näyttämiseen koodieditoreissa ja verkkorajapinnoissa, mikä voidaan ratkaista käyttämällä tarkistuksen aikana oikeita työkaluja ja koodianalysaattoreita. Siksi sen sijaan, että kiinnittäisi huomiota spekulatiivisiin hyökkäyksiin, olisi tarkoituksenmukaisempaa keskittyä koodin ja riippuvuuden tarkistusprosessien parantamiseen.
Ras Cox uskoo myös, että kääntäjät eivät ole oikea paikka korjata ongelmaa, koska vaarallisten symbolien kieltäminen kääntäjätasolla, jäljelle jää valtava työkalukerros, jossa näiden symbolien käyttö on edelleen hyväksyttävää, kuten rakennusjärjestelmät, kokoajat, paketinhallintaohjelmat ja erilaiset kokoonpanon jäsentimet ja tiedot. Esimerkkinä on annettu Rust-projekti, joka kielsi LTR/RTL-koodin käsittelyn kääntäjässä, mutta ei lisännyt korjausta Cargo-pakettienhallintaan, mikä mahdollistaa vastaavan hyökkäyksen Cargo.toml-tiedoston kautta. Samoin tiedostot, kuten BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml ja requirements.txt, voivat muodostua hyökkäysten lähteiksi.
Lähde: opennet.ru