Navorsers van die Universiteit van Cambridge het 'n tegniek gepubliseer om kwaadwillige kode stilweg in eweknie-geëvalueerde bronkode in te voeg. Die voorbereide aanvalmetode (CVE-2021-42574) word aangebied onder die naam Trojaanse Bron en is gebaseer op die vorming van teks wat anders lyk vir die samesteller/tolk en die persoon wat die kode bekyk. Voorbeelde van die metode word gedemonstreer vir verskeie samestellers en tolke wat verskaf word vir C, C++ (gcc en clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go en Python.
Die metode is gebaseer op die gebruik van spesiale Unicode-karakters in kodekommentaar wat die vertoonvolgorde van tweerigtingteks verander. Met die hulp van sulke beheerkarakters kan sommige dele van die teks van links na regs vertoon word, terwyl ander - van regs na links. In die alledaagse praktyk kan sulke beheerkarakters byvoorbeeld gebruik word om kodelyne in Hebreeus of Arabies in 'n lêer in te voeg. Maar as jy lyne met verskillende teksrigtings in een reël kombineer, deur die gespesifiseerde karakters te gebruik, kan teksgedeeltes wat van regs na links vertoon word, bestaande gewone teks wat van links na regs vertoon word, oorvleuel.
Deur hierdie metode te gebruik, kan jy 'n kwaadwillige konstruk by die kode voeg, maar dan die teks met hierdie konstruk onsigbaar maak wanneer jy die kode bekyk, deur die volgende opmerking by te voeg of binne die letterlike karakters wat van regs na links gewys word, wat sal lei tot heeltemal verskillende karakters wat op die kwaadwillige invoeging geplaas word. Sodanige kode sal semanties korrek bly, maar sal anders geïnterpreteer en vertoon word.
Terwyl die kode hersien word, sal 'n ontwikkelaar gekonfronteer word met die visuele volgorde van die karakters en sal 'n nie-verdagte opmerking in 'n moderne teksredigeerder, webkoppelvlak of IDE sien, maar die samesteller en tolk sal die logiese volgorde van die karakters gebruik en sal verwerk die kwaadwillige invoeging soos dit is, sonder om aandag te gee aan die tweerigtingteks in die kommentaar. Die probleem raak verskeie gewilde koderedigeerders (VS Code, Emacs, Atom), sowel as koppelvlakke om kode in bewaarplekke te bekyk (GitHub, Gitlab, BitBucket en alle Atlassian-produkte).
Daar is verskeie maniere om die metode te gebruik om kwaadwillige aksies te implementeer: die byvoeging van 'n versteekte "terugkeer" uitdrukking, wat lei tot die voltooiing van die funksie voor die tyd; kommentaar te lewer op uitdrukkings wat normaalweg sigbaar sal wees as geldige konstrukte (byvoorbeeld om belangrike kontroles uit te skakel); ander stringwaardes toe te ken wat lei tot stringvalideringsmislukkings.
Byvoorbeeld, 'n aanvaller kan 'n verandering voorstel wat die reël insluit: if access_level != "user{U+202E} {U+2066}// Kyk of admin{U+2069} {U+2066}" {
wat in die hersieningskoppelvlak vertoon sal word asof toegangsvlak != “gebruiker” {// Kyk of admin
Daarbenewens is 'n ander aanvalvariant voorgestel (CVE-2021-42694), wat verband hou met die gebruik van homogliewe, karakters wat soortgelyk is in voorkoms, maar verskil in betekenis en het verskillende unicode-kodes (byvoorbeeld, die karakter "ɑ" lyk soos " a", "ɡ" - "g", "ɩ" - "l"). Soortgelyke karakters kan in sommige tale in die name van funksies en veranderlikes gebruik word om ontwikkelaars te mislei. Byvoorbeeld, twee funksies met ononderskeibare name kan gedefinieer word wat verskillende aksies uitvoer. Sonder 'n gedetailleerde ontleding is dit nie onmiddellik duidelik watter van hierdie twee funksies op 'n spesifieke plek genoem word nie.
As 'n sekuriteitsmaatreël word dit aanbeveel dat samestellers, tolke en samestellingnutsmiddels wat Unicode-karakters ondersteun 'n fout of waarskuwing vertoon as daar ongepaarde beheerkarakters in opmerkings, stringletters of identifiseerders is wat die rigting van afvoer verander (U+202A, U+202B, U +202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E en U+200F). Sulke karakters moet ook uitdruklik in programmeertaalspesifikasies verbied word en moet in koderedigeerders en bewaarplekkoppelvlakke gerespekteer word.
Bylaag 1: Kwesbaarheidkolle is voorberei vir GCC, LLVM/Clang, Rust, Go, Python en binutils. GitHub, Bitbucket en Jira het ook die probleem opgelos. 'n Regstelling vir GitLab is aan die gang. Om problematiese kode te identifiseer, word dit aanbeveel om die opdrag te gebruik: grep -r $'[\u061C\u200E\u200E\u202A\u202B\u202C\u202D\u202C\u2066D\u2067E\u2068\u2069\uXNUMX\uXNUMX/' bron
Bylaag 2: Russ Cox, een van die ontwikkelaars van die Plan 9-bedryfstelsel en die Go-programmeertaal, het die oormatige aandag aan die beskryfde aanvalmetode gekritiseer, wat lank reeds bekend is (Go, Rust, C++, Ruby) en nie ernstig opgeneem is nie. . Volgens Cox gaan die probleem hoofsaaklik oor die korrekte vertoon van inligting in koderedigeerders en webkoppelvlakke, wat opgelos kan word deur die korrekte gereedskap en kode-ontleders tydens hersiening te gebruik. Daarom, in plaas daarvan om die aandag op spekulatiewe aanvalle te vestig, sal dit meer gepas wees om te fokus op die verbetering van kode- en afhanklikheidhersieningsprosesse.
Ras Cox glo ook dat samestellers nie die regte plek is om die probleem op te los nie, want deur gevaarlike simbole op samestellervlak te verbied, bly daar 'n groot laag gereedskap waarin die gebruik van hierdie simbole aanvaarbaar bly, soos boustelsels, samestellers, pakketbestuurders en verskeie konfigurasieontleders en data. As voorbeeld word die Rust-projek gegee, wat die verwerking van LTR/RTL-kode in die samesteller verbied het, maar nie 'n oplossing by die Cargo-pakketbestuurder gevoeg het nie, wat 'n soortgelyke aanval deur die Cargo.toml-lêer toelaat. Net so kan lêers soos BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml en requirements.txt bronne van aanvalle word.
Bron: opennet.ru