Paar dagen geleden Onderzoekers van de Universiteit van Cambridge vrijgegeven de publicatie van een techniek om op subtiele wijze codes te vervangen kwaadaardige code in de broncode van de applicatie.
De aanvalsmethode bereidde dat voor Het staat al vermeld onder CVE-2021-42574 Het valt onder de naam Trojan Source en is gebaseerd op de vorming van tekst die er anders uitziet voor de compiler/interpreter en de persoon die de code bekijkt.
Over Trojaanse bron
De methode vertrouwt op het toepassen van speciale Unicode-tekens in codeopmerkingen, die de weergavevolgorde van bidirectionele tekst wijzigen. Met behulp van deze controlekarakters, sommige delen van de tekst kunnen van links naar rechts worden weergegeven, terwijl andere van rechts naar links.
In de dagelijkse praktijk kunnen deze controletekens bijvoorbeeld worden gebruikt om Hebreeuwse of Arabische tekenreeksen in een codebestand in te voegen. Als u deze tekens echter gebruikt om regels met verschillende tekstrichtingen op dezelfde regel te combineren, kunnen tekstpassages die van rechts naar links worden weergegeven, bestaande normale tekst die van links naar rechts wordt weergegeven, overlappen.
Met deze methode, een kwaadwillende constructie kan aan de code worden toegevoegd, maar maak dan de tekst met deze constructie onzichtbaar bij het bekijken van de code, door de karakters toe te voegen die van rechts naar links worden getoond in de volgende opmerking of in de letterlijke, wat zal resulteren in een resultaat van totaal verschillende karakters bovenop de kwaadaardige invoeging. Dergelijke code zal nog steeds semantisch correct zijn, maar zal anders worden geïnterpreteerd en weergegeven.
We hebben manieren ontdekt om de codering van broncodebestanden te manipuleren, zodat menselijke kijkers en compilers verschillende logica zien. Een bijzonder schadelijke methode maakt gebruik van Unicode-richtingsgebonden overschrijvingstekens om de code weer te geven als een anagram van zijn ware logica. We hebben geverifieerd dat deze aanval werkt tegen C, C ++, C #, JavaScript, Java, Rust, Go en Python, en we vermoeden dat deze ook zal werken tegen de meeste andere moderne talen.
Tijdens het bekijken van de code, de ontwikkelaar wordt geconfronteerd met de visuele volgorde van de personages en ziet een verdachte opmerking in een editor tekst, webinterface of IDE, maar de compiler en interpreter zullen de logische volgorde van de karakters gebruiken en de kwaadaardige code afhandelen zoals het is, ongeacht de bidirectionele tekst in de opmerking. Verschillende populaire code-editors (VS Code, Emacs, Atom), evenals interfaces voor het bekijken van code in repositories (GitHub, Gitlab, BitBucket en alle Atlassian-producten) zijn getroffen.
Er zijn verschillende manieren om de methode te gebruiken om kwaadaardige acties uit te voeren: voeg een verborgen "return"-expressie toe, die ertoe leidt dat de uitvoering van de functie voortijdig wordt beëindigd; de conclusie in de opmerking van uitdrukkingen die normaal gesproken als geldige constructies worden beschouwd (bijvoorbeeld om belangrijke controles uit te schakelen); Het toewijzen van andere tekenreekswaarden die leiden tot fouten in de tekenreeksvalidatie.
Bovendien heeft een andere aanvalsoptie werd voorgesteld (CVE-2021-42694), waarbij gebruik wordt gemaakt van homoglyfen, symbolen die er hetzelfde uitzien, maar verschillen in betekenis en verschillende Unicode-codes hebben. Deze karakters kunnen in sommige talen in functie- en variabelenamen worden gebruikt om ontwikkelaars te misleiden. U kunt bijvoorbeeld twee functies definiëren met niet te onderscheiden namen die verschillende acties uitvoeren. Zonder gedetailleerde analyse kun je niet meteen begrijpen welke van deze twee functies op een bepaalde plaats wordt aangeroepen.
Als beschermingsmaatregel, Het wordt aanbevolen om te implementeren in compilers, interpreters en assemblagetools die Unicode-tekens ondersteunen en een fout of waarschuwing weergeven of er ongepaarde controletekens zijn in opmerkingen, letterlijke tekenreeksen of identifiers die de uitvoerrichting veranderen. Deze karakters moeten ook expliciet worden verboden in de programmeertaalspecificaties en er moet rekening mee worden gehouden in code-editors en interfaces voor het werken met repositories.
Daarnaast kwetsbaarheden zijn al verholpen voorbereid voor GCC, LLVM / Clang, Rust, Go, Python en binutils. Ook GitHub, Bitbucket en Jira zijn samen met GitLab al bezig met een oplossing.
Eindelijk Als u er meer over wilt weten, u kunt raadplegen de details in de volgende link.