Forscher der Universität Cambridge haben eine Technik zur unsichtbaren Einspritzung von Schadcode in begutachtete Quelltexte veröffentlicht. Die ausgearbeitete Angriffsmethode (CVE-2021-42574) wird als Trojan Source bezeichnet 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 wurden für verschiedene Compiler und Interpreter demonstriert, die für die Sprachen 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 den Code-Kommentaren, die die Reihenfolge der Darstellung von bidirektionalem Text ändern. Mit Hilfe solcher Steuerzeichen können Teile des Textes von links nach rechts und andere von rechts nach links angezeigt werden. In der Praxis können solche Steuerzeichen beispielsweise verwendet werden, um in eine Datei mit Code Zeilen in Hebräisch oder Arabisch einzufügen. Kombiniert man jedoch Text mit unterschiedlicher Richtung in einer Zeile mithilfe dieser Zeichen, können Teile des von rechts nach links angezeigten Textes den bereits vorhandenen normalen Text, der von links nach rechts angezeigt wird, überdecken.
Mit dieser Methode kann in den Code eine schadhafte Konstruktion eingefügt werden, aber der Text mit dieser Konstruktion kann durch das Hinzufügen von Symbolen, die von rechts nach links angezeigt werden, in einem nachfolgenden Kommentar oder innerhalb eines Literals verborgen werden. Dadurch wird die schadhafte Einspritzung durch ganz andere Zeichen überlagert. Solcher Code bleibt semantisch korrekt, wird jedoch unterschiedlich interpretiert und dargestellt.
Während der Überprüfung des Codes wird der Entwickler auf die visuelle Reihenfolge der Zeichenanzeige stoßen und in modernem Texteditor, Web-Interface oder IDE einen harmlosen Kommentar sehen, doch der Compiler und der Interpreter verwenden die logische Reihenfolge der Zeichen und verarbeiten die schadhafte Einspritzung, ohne auf den bidirektionalen Text im Kommentar zu achten. Verschiedene beliebte Code-Editoren (VS Code, Emacs, Atom) sowie die Schnittstellen zur Anzeige von Code in Repositories (GitHub, Gitlab, BitBucket und alle Produkte von Atlassian) sind anfällig für dieses Problem.
Es gibt mehrere Möglichkeiten, die Methode zu verwenden, um schädliche Aktionen durchzuführen: Hinzufügen eines versteckten Ausdrucks „return“, der dazu führt, dass die Funktion vorzeitig endet; Einschluss in einen Kommentar von Ausdrücken, die normalerweise als funktionale Konstrukte sichtbar sind (zum Beispiel um wichtige Überprüfungen zu deaktivieren); Zuweisung anderer Zeichenfolgenwerte, die zu fehlerhaften Überprüfungen führen.
Zum Beispiel könnte ein Angreifer die Änderung vorschlagen, die folgende Zeile enthält: if access_level != „user{U+202E} {U+2066}// Check if admin{U+2069} {U+2066}“ {
die im Interface zur Überprüfung angezeigt wird als if access_level != „user“ { // Check if admin
Zusätzlich wurde eine weitere Angriffsmöglichkeit vorgeschlagen (CVE-2021-42694), die mit der Verwendung von Homoglyphen zusammenhängt, Zeichen, die äußerlich ähnlich aussehen, aber unterschiedliche Bedeutungen haben und unterschiedliche Unicode-Codes besitzen (zum Beispiel ähnelt das Zeichen „ɑ“ dem „a“, „ɡ“ dem „g“, „ɩ“ dem „l“). Solche Zeichen können in einigen Programmiersprachen in Funktions- und Variablennamen verwendet werden, um Entwickler in die Irre zu führen. Zum Beispiel können zwei Funktionen mit nicht unterscheidbaren Namen definiert werden, die unterschiedliche Aktionen ausführen. Ohne eine detaillierte Analyse ist nicht sofort ersichtlich, welche dieser beiden Funktionen an einer bestimmten Stelle aufgerufen wird.
Als Schutzmaßnahme wird empfohlen, dass Compiler, Interpreter und Build-Tools, die Unicode-Zeichen unterstützen, einen Fehler oder eine Warnung ausgeben, wenn in Kommentaren, Zeichenliteralen oder Bezeichnern ungerade Steuerzeichen vorhanden sind, die die Ausgaberichtung ändern (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 den Spezifikationen von Programmiersprachen ausdrücklich verboten werden und sollten in Code-Editoren und Benutzeroberflächen für die Arbeit mit Repositories berücksichtigt werden.
Ergänzung 1: Patches zur Behebung der Sicherheitsanfälligkeit wurden 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 wird vorbereitet. Zur Identifizierung des problematischen Codes wird die folgende Befehlszeile vorgeschlagen: grep -r $'[\u061C\u200E\u200F\u202A\u202B\u202C\u202D\u202E\u2066\u2067\u2068\u2069]’ /path/to/source
Ergänzung 2: Russ Cox, einer der Entwickler des Betriebssystems Plan 9 und der Programmiersprache Go, kritisierte die übermäßige Aufmerksamkeit für die beschriebene Angriffsmethode, die schon lange bekannt ist (Go, Rust, C++, Ruby) und nicht ernst genommen wurde. Laut Cox betrifft das Problem hauptsächlich die Korrektheit der Anzeige von Informationen in Code-Editoren und Web-Oberflächen, und es wird durch die Anwendung geeigneter Werkzeuge und Code-Analysatoren bei der Überprüfung gelöst. Daher wäre es sinnvoller, den Fokus auf die Verbesserung der Überprüfungsprozesse von Code und Abhängigkeiten zu legen, anstatt die Aufmerksamkeit auf hypothetische Angriffe zu lenken.
Russ Cox ist ebenfalls der Meinung, dass Compiler nicht der richtige Ort sind, um das Problem zu lösen, da es eine Vielzahl von Werkzeugen gibt, in denen die Verwendung gefährlicher Zeichen weiterhin zulässig ist, selbst wenn sie auf Compiler-Ebene verboten werden, wie z.B. Build-Systeme, Assembler, Paketmanager und verschiedene Parser für Konfigurationen und Daten. Zum Beispiel hat das Projekt Rust die Verarbeitung von LTR/RTL-Code im Compiler verboten, aber keine Korrektur im Paketmanager Cargo vorgenommen, was einen ähnlichen Angriff über die Datei Cargo.toml ermöglicht. Ebenso können Quellen für Angriffe Dateien wie BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml und requirements.txt sein.
Quelle: opennet.ru
