Forscher der Universität Cambridge haben eine Technik veröffentlicht, um heimlich Schadcode in von Experten geprüften Quellcode einzufügen. Die vorbereitete Angriffsmethode (CVE-2021-42574) wird unter dem Namen Trojan Source vorgestellt und basiert auf der Bildung von Text, der für den Compiler/Interpreter und den Betrachter des Codes unterschiedlich aussieht. Beispiele für die Anwendung der Methode werden für verschiedene Compiler und Interpreter demonstriert, die für C, C++ (gcc und clang), C#, JavaScript (Node.js), Java (OpenJDK 16), Rust, Go und Python bereitgestellt werden.
Die Methode basiert auf der Verwendung spezieller Unicode-Zeichen in Codekommentaren, die die Reihenfolge ändern, in der bidirektionaler Text angezeigt wird. Mit Hilfe solcher Steuerzeichen können einige Textteile von links nach rechts, andere von rechts nach links dargestellt werden. In der alltäglichen Praxis können solche Steuerzeichen beispielsweise verwendet werden, um Zeilen in Hebräisch oder Arabisch in eine Datei einzufügen. Wenn Sie jedoch Zeilen mit unterschiedlichen Textrichtungen in einer Zeile zusammenfassen und dabei die angegebenen Zeichen verwenden, kann es sein, dass Textpassagen, die von rechts nach links angezeigt werden, vorhandenen Klartext überlappen, der von links nach rechts angezeigt wird.
Mit dieser Methode können Sie dem Code ein bösartiges Konstrukt hinzufügen, den Text mit diesem Konstrukt dann jedoch beim Anzeigen des Codes unsichtbar machen, indem Sie im nächsten Kommentar oder innerhalb des Literals von rechts nach links angezeigte Zeichen hinzufügen, was zu vollständig führt Verschiedene Zeichen werden über die böswillige Einfügung gelegt. Ein solcher Code bleibt semantisch korrekt, wird jedoch anders interpretiert und angezeigt.
Während des Codeüberprüfungsprozesses wird ein Entwickler auf die visuelle Zeichenreihenfolge stoßen und einen unverdächtigen Kommentar in einem modernen Texteditor, einer Weboberfläche oder einer IDE sehen, aber der Compiler und Interpreter verwenden die logische Zeichenreihenfolge und verarbeiten die böswillige Einfügung unverändert und ignorieren sie bidirektionaler Text in den Kommentaren. Das Problem betrifft verschiedene gängige Code-Editoren (VS Code, Emacs, Atom) sowie Schnittstellen zum Anzeigen von Code in Repositories (GitHub, Gitlab, BitBucket und alle Atlassian-Produkte).
Es gibt mehrere Möglichkeiten, die Methode zum Implementieren böswilliger Aktionen zu verwenden: Hinzufügen eines versteckten „Return“-Ausdrucks, der dazu führt, dass die Funktionsausführung vorzeitig abgeschlossen wird; Auskommentieren von Ausdrücken, die normalerweise als gültige Konstrukte angesehen werden (z. B. um wichtige Prüfungen zu deaktivieren); Zuweisung anderer Zeichenfolgenwerte, was zu Fehlern bei der Zeichenfolgenvalidierung führt.
Beispielsweise könnte ein Angreifer eine Änderung vorschlagen, die die folgende Zeile enthält: if access_level != "user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}" {
Dies wird in der Überprüfungsoberfläche angezeigt, als ob access_level != "user" { // Überprüfen Sie, ob admin
Darüber hinaus wurde eine weitere Angriffsvariante vorgeschlagen (CVE-2021-42694), die mit der Verwendung von Homoglyphen verbunden ist, Zeichen, die äußerlich im Umriss ähnlich sind, sich aber in der Bedeutung unterscheiden und unterschiedliche Unicode-Codes haben (zum Beispiel ähnelt das Symbol „ɑ“ „ a“, „ɡ“ – „g“, „ɩ“ – „l“). Solche Zeichen können in einigen Sprachen in Funktions- und Variablennamen verwendet werden, um Entwickler zu verwirren. Beispielsweise können zwei Funktionen mit identischem Namen definiert werden, die unterschiedliche Aktionen ausführen. Ohne eine detaillierte Analyse ist nicht sofort klar, welche dieser beiden Funktionen an welcher Stelle aufgerufen wird.
Aus Sicherheitsgründen wird empfohlen, dass Compiler, Interpreter und Build-Tools, die Unicode-Zeichen unterstützen, einen Fehler oder eine Warnung ausgeben, wenn Kommentare, Zeichenfolgenliterale oder Bezeichner ungepaarte Steuerzeichen enthalten, die die Ausgaberichtung umkehren (U+202A, U+202B). , U+202C, U+202D, U+202E, U+2066, U+2067, U+2068, U+2069, U+061C, U+200E und U+200F). Solche Zeichen sollten auch in Programmiersprachenspezifikationen explizit verboten werden und in Code-Editoren und Schnittstellen für die Arbeit mit Repositories berücksichtigt werden.
Nachtrag 1: Schwachstellenkorrekturen für GCC, LLVM/Clang, Rust, Go, Python und Binutils vorbereitet. Das Problem wurde auch von GitHub, Bitbucket und Jira behoben. Ein Fix für GitLab ist in Vorbereitung. Um problematischen Code zu identifizieren, wird empfohlen, den folgenden Befehl zu verwenden: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]' /path/to/ Quelle
Nachtrag 2: Russ Cox, einer der Entwickler des Plan 9 OS und der Programmiersprache Go, kritisierte die übermäßige Aufmerksamkeit für die beschriebene Angriffsmethode, die seit langem bekannt ist (Go, Rust, C++, Ruby) und nicht Ernst genommen werden. Laut Cox betrifft das Problem vor allem die korrekte Darstellung von Informationen in Code-Editoren und Weboberflächen und wird durch den Einsatz der richtigen Tools und Code-Analysatoren bei der Überprüfung gelöst. Anstatt die Aufmerksamkeit auf spekulative Angriffe zu lenken, wäre es daher angemessener, sich auf die Verbesserung von Codeüberprüfungsprozessen und Abhängigkeiten zu konzentrieren.
Ras Cox glaubt auch, dass Compiler nicht der richtige Ort sind, um das Problem zu beheben, da die Deaktivierung gefährlicher Symbole auf Compiler-Ebene eine riesige Schicht von Tools hinterlässt, in denen die Verwendung dieser Symbole akzeptabel bleibt, wie z. B. Build-Systeme, Assembler, Paketmanager usw verschiedene Konfigurationsparser und Daten. Als Beispiel sei das Rust-Projekt genannt, das die Verarbeitung von LTR/RTL-Code im Compiler untersagte, aber keinen Fix zum Cargo-Paketmanager hinzufügte, der einen ähnlichen Angriff über die Datei Cargo.toml ermöglicht. Ebenso können Dateien wie BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml und require.txt zu Angriffsquellen werden.
Source: opennet.ru