Forscher der Universität Cambridge haben eine Technik zur unsichtbaren Einschleusung von schädlichem Code in veröffentlichte Quelltexte präsentiert. Die entwickelte Angriffsmethode (CVE-2021-42574) trägt den Namen Trojan Source und basiert auf der Erzeugung von Texten, die für den Compiler/Interpreter und für den menschlichen Betrachter des Codes unterschiedlich aussehen. Anwendungsbeispiele der Methode wurden für verschiedene Compiler und Interpreter vorgeführt, 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 Code-Kommentaren, die die Anzeige von bidirektionalem Text beeinflussen. Mit solchen 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 Zeilen in Hebräisch oder Arabisch in eine Code-Datei einzufügen. Wenn jedoch Strings mit unterschiedlicher Textausrichtung in derselben Zeile kombiniert werden, können die Abschnitte, die von rechts nach links angezeigt werden, den normalen Text, der von links nach rechts angezeigt wird, überlagern.
Durch die Anwendung dieser Methode im Code kann eine schädliche Konstruktion hinzugefügt werden, die dann durch die Hinzufügung von Zeichen, die von rechts nach links angezeigt werden, in einem nachfolgenden Kommentar oder innerhalb eines Literals unsichtbar gemacht werden kann. Dies führt dazu, dass auf die schädliche Einfügung völlig andere Zeichen gelegt werden. Ein solcher Code bleibt semantisch korrekt, wird aber unterschiedlich interpretiert und angezeigt.
Während der Überprüfung des Codes wird der Entwickler auf die visuelle Anordnung der Zeichen stoßen und in einem modernen Texteditor, Web-Interface oder IDE einen unschuldigen Kommentar sehen. Doch der Compiler und Interpreter verwenden die logische Reihenfolge der Zeichen und verarbeiten die schadhafte Einfügung, ohne auf den bidirektionalen Text im Kommentar zu achten. Verschiedene beliebte Code-Editoren (VS Code, Emacs, Atom) sowie Interfaces zur Anzeige von Code in Repositories (GitHub, GitLab, Bitbucket und alle Produkte von Atlassian) sind von diesem Problem betroffen.
Es gibt mehrere Möglichkeiten, die Methode für böswillige Handlungen zu nutzen: Einfügen eines versteckten Ausdrucks „return“, der die Ausführung der Funktion vorzeitig beendet; das Kommentieren von Ausdrücken, die normalerweise als gültige Konstrukte sichtbar sind (zum Beispiel um wichtige Überprüfungen zu deaktivieren); Zuweisung anderer Zeichenfolgenwerte, die zu Fehlern bei der Zeichenfolgenüberprüfung führen.
Ein Angreifer könnte beispielsweise eine Änderung vorschlagen, die die 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, wenn access_level != "user" { \/\/ Überprüfen, ob Admin
Zusätzlich wurde eine weitere Angriffsmethode (CVE-2021-42694) vorgeschlagen, die mit der Verwendung von Homografen zusammenhängt, Zeichen, die äußerlich ähnlich aussehen, jedoch unterschiedliche Bedeutungen haben und unterschiedliche Unicode-Codes besitzen (zum Beispiel erinnert das Zeichen „ɑ“ an „a“, „ɡ“ an „g“, „ɩ“ an „l“). Solche Zeichen können in einigen Programmiersprachen in Funktions- und Variablennamen verwendet werden, um Entwickler zu täuschen. So könnten zwei Funktionen mit ununterscheidbaren Namen definiert werden, die unterschiedliche Aktionen ausführen. Ohne detaillierte Analyse ist nicht sofort ersichtlich, welche dieser beiden Funktionen an einem bestimmten Ort aufgerufen wird.
Um Schutzmaßnahmen zu ergreifen, wird empfohlen, in Compilern, Interpretern und Build-Tools, die Unicode-Zeichen unterstützen, Fehler- oder Warnmeldungen auszugeben, wenn ungerade Steuerzeichen, die die Ausgabe richten (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), in Kommentaren, Zeichenliteralen oder Identifikatoren vorhanden sind. Solche Zeichen sollten auch in den Spezifikationen von Programmiersprachen ausdrücklich verboten werden und in Code-Editoren sowie in Schnittstellen zur Arbeit mit Repositories berücksichtigt werden.
Ergänzung 1: Sicherheitsupdates wurden für GCC, LLVM/Clang, Rust, Go, Python und binutils bereitgestellt. Das Problem wurde auch von GitHub, Bitbucket und Jira behoben. Ein Fix für GitLab ist in Vorbereitung. Zur Identifizierung des problematischen Codes wird vorgeschlagen, den Befehl zu verwenden: 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 auf die beschriebene Angriffsart, die schon lange bekannt ist (Go, Rust, C++, Ruby) und nicht ernst genommen wurde. Cox ist der Meinung, dass das Problem vor allem die korrekte Darstellung von Informationen in Code-Editoren und Web-Oberflächen betrifft, welches durch die Anwendung angemessener Tools und Code-Analysatoren beim Review-Prozess gelöst werden kann. Daher wäre es sinnvoller, anstatt Aufmerksamkeit auf hypothetische Angriffe zu lenken, sich auf die Verbesserung der Code- und Abhängigkeits-Reviewprozesse zu konzentrieren.
Ras Cox ist ebenfalls der Ansicht, dass Compiler nicht der geeignete Ort sind, um das Problem zu beheben. Da durch das Verbot gefährlicher Symbole auf der Ebene des Compilers weiterhin eine Vielzahl von Tools existiert, in denen die Verwendung dieser Symbole zulässig bleibt – wie Build-Systeme, Assembler, Paketmanager und verschiedene Konfigurations- sowie Datenparser. Beispielsweise hat das Rust-Projekt die Verarbeitung von LTR/RTL-Code im Compiler verboten, aber keine Korrektur im Paketmanager Cargo hinzugefügt, was eine ähnliche Angriffsgelegenheit über die Datei Cargo.toml bietet. Ähnlich können auch Dateien wie BUILD.bazel, CMakefile, Cargo.toml, Dockerfile, GNUmakefile, Makefile, go.mod, package.json, pom.xml und requirements.txt Angriffsmöglichkeiten darstellen.
Quelle: opennet.ru
