Rechercher dans ce blog

Tuesday, November 2, 2021

Trojan Source: Programmiersprachen lassen sich per Unicode trojanisieren - Golem.de - Golem.de

Ein Forschungsteam zeigt systematisch, wie sich mit Unicode-Tricks Code manipulieren lässt. Open-Source-Communitys und die IT-Industrie reagieren.

Ein Bericht von und
Wie dieser Sourcecode wohl für einen Compiler ausssieht?
Wie dieser Sourcecode wohl für einen Compiler ausssieht? (Bild: fancycrave1/Pixabay)

Praktisch alle großen Programmiersprachen lassen sich mit einem Trick trojanisieren. So lassen sich über Unicode-Befehle Sicherheitslücken in den Code einbringen, die von Menschen unter Umständen nur schwer erkannt werden, durch das Kompilieren jedoch zu Schadfunktionen werden können. Das beschreiben die Sicherheitsforscher Nicholas Boucher und Ross Anderson von der Cambridge Universität in einer aktuellen Untersuchung.

Hintergrund ist der digitale Textkodierungsstandard Unicode, der mehr als 143.000 Zeichen verschiedener Schriftsysteme enthält. Diese können wie etwa für Arabisch von rechts nach links oder wie für Deutsch und Englisch von links nach rechts gelesen werden. Die unterschiedliche Anzeigenreihenfolge von gemischten Texten kann mit dem bidirektionalen oder Bidi-Algorithmus gehandhabt werden.

"In einigen Szenarien kann die vom Bidi-Algorithmus vorgegebene Reihenfolge nicht ausreichend sein", schreiben Boucher und Anderson in dem Papier (PDF). "Für diese Fälle ermöglichen Bidi-Override-Steuerzeichen das Umschalten der Anzeigereihenfolge von Gruppen von Zeichen." Damit lassen sich einzelne Zeichen einer Zeichenkette in einer anderen Reihenfolge darstellen, etwa um ein Wort auf Arabisch im Original in einen Satz auf Deutsch einzufügen.

Zusammenfassung bestehender Ideen zu Unicode-Tricks

Das Problem ist, dass die meisten Programmiersprachen die Bidi-Overrides auch in Kommentaren oder Strings erlauben, die beim Kompilieren interpretiert werden und die Reihenfolge des programmierten Codes ändern. Dadurch lässt sich die Logik des Programmes syntaktisch korrekt ändern und Programm A wird in Programm B verwandelt. Entsprechend bezeichnen die Forscher die Sicherheitslücke (CVE-2021-42574, CVE-2021-42694) als Trojan Source.

Das von den Forschern beschriebene Vorgehen wurde in der Vergangenheit bereits ausgenutzt, um Dateiendungen von per E-Mail verbreiteter Schadsoftware zu verschleiern. Auch für Programmiersprachen ist es nicht völlig unbekannt. So finden sich derartige Überlegungen seit Jahren in Diskussionen etwa bei Eclipse, Go, Ruby oder der für Ethereum genutzten Sprache Solidity. Die Forscher beschreiben auch Homoglyph-Angriffe, die es so ähnlich auch beim DNS seit Jahrzehnten gibt.

Die beiden Forscher haben nun aber diese theoretischen Angriffe zusammengefasst, als grundlegendes Problem für die Mehrheit der Programmiersprachen beschrieben und sich um ein möglichst weitgehendes sogenanntes Coordinated Disclosure bemüht, also zahlreiche betroffenen Stellen informiert. Auch sorgt die Vergabe von CVE-Nummern in der Software-Industrie mitunter erst dafür, dass derartige Probleme wahrgenommen und weitgehend bearbeitet werden.

Aus der IT-Sicherheitscommunity kam teilweise Kritik an der Art der Veröffentlichung. So stellten die Autoren Angriffe als neu dar, die in ähnlicher Weise bereits vorher öffentlich bekannt waren. Filippo Valsorda vom Go-Sicherheitsteam zweifelte auf Twitter an der Sinnhaftigkeit zu versuchen, solche Angriffe in Compilern zu blockieren. Das sei eher die Aufgabe von Reviewtools und Editoren.

Der Forscher Anderson sagte dem Journalisten Brian Krebs bezüglich der praktischen Auswirkungen der Lücken: "Man kann sie also in Quellcode verwenden, der für einen menschlichen Prüfer harmlos erscheint und in Wirklichkeit etwas Böses anrichten kann." Weiter heißt es: "Das ist eine schlechte Nachricht für Projekte wie Linux und Webkit, die Beiträge von zufälligen Personen akzeptieren, sie einer manuellen Überprüfung unterziehen und sie dann in kritischen Code einbauen. Diese Schwachstelle ist, soweit ich weiß, die erste, die fast alles betrifft."

Für menschliche Codeprüfer ist es möglicherweise schwierig, einen solchen Angriff zu erkennen, weil der gerenderte Code je nach Editor und genutzter Kodierung völlig akzeptabel aussieht. Solchen Schadcode könnten sich Entwickler auch durch das Kopieren von Code-Beispielen auf Internetplattformen einfangen. "Jeder Entwickler, der Code aus einer nicht vertrauenswürdigen Quelle in eine geschützte Codebasis kopiert, kann versehentlich eine unsichtbare Schwachstelle einführen", sagte Anderson.

Dieser Ansicht widersprechen aber einige Entwickler vehement. So schreibt etwa die Vorsitzende des Security-Teams von Alpine Linux, Ariadne Conill, auf Twitter, dass derartige über Unicode umgesetzte Tricks schnell und leicht in Editoren erkannt werden könnten, wenn diese entsprechend eingestellt sind. Bei Conill geschieht dies etwa sogar standardmäßig mit GNU Nano.

Gegenmaßnahmen sollen Entwicklern bei der Fehlersuche helfen

Matthew Green, der an der Johns Hopkins Universität Kryptographie lehrt, überrascht es nicht, dass die meisten Compiler mit Unicode dazu gebracht werden können, Code anders zu verarbeiten. "Was mich jedoch überrascht, ist, wie viele Compiler Unicode ohne jegliche Abwehrmechanismen analysieren und wie effektiv ihre Rechts-nach-links-Kodierungstechnik ist, um Code in Codebasen einzuschleusen. Das ist ein wirklich cleverer Trick, von dem ich nicht einmal wusste, dass er möglich ist", sagte Green.

"Die schlechte Nachricht ist, dass es keine Abwehrmechanismen gab, und jetzt, wo die Leute davon wissen, könnten sie anfangen, es auszunutzen", sagte Green. "Hoffentlich patchen die Entwickler von Compilern und Code-Editoren das Problem schnell! Aber da einige Leute ihre Entwicklungswerkzeuge nicht regelmäßig aktualisieren, wird es zumindest für eine Weile ein gewisses Risiko geben."

Betroffen von den Unicode-Problemen sind theoretisch alle Programmiersprachen, deren Compiler oder Interpreter sich an den Standard halten. Die Forscher selbst haben entsprechende Beispiele für C, C++, C#, Javascript, Java, Rust, Go und Python auf Github veröffentlicht.

Als Gegenmaßnahmen stehen nun erste Patches für die Compiler-Sammlungen von GCC und LLVM bereit, die entsprechende Warnungen vor den Unicode-Zeichen umsetzen. Das Rust-Team schreibt in einer Sicherheitsnotiz darüber hinaus, dass es sich bei dem Verhalten um keinen Fehler in dem eigenen Compiler Rustc handele, das Team dennoch aktiv dagegen vorgehe.

Mit der aktuellen Version 1.56.1 stehen zwei Linter bereit, die entsprechende Zeichen erkennen. Das Rust-Team nennt außerdem weitere Unicode-Zeichen, deren Vorhandensein Entwickler in Code künftig einfach regelmäßig prüfen sollten. Letzteres umgesetzt haben bereits die Code-Hoster Github und Gitlab als Reaktion auf die wissenschaftliche Veröffentlichung. Auch Atlassian hat schon reagiert. Weitere Editoren und Werkzeuge dürften folgen.

Adblock test (Why?)


Trojan Source: Programmiersprachen lassen sich per Unicode trojanisieren - Golem.de - Golem.de
Read More

No comments:

Post a Comment

One UI 5.1: Samsung kündigt Update-Start für ältere Galaxy-Smartphones an, los geht es u.a. mit Galaxy S20, S21 und S22 - Notebookcheck.com

Nachdem es vor wenigen Tagen bereits inoffizielle Informationen zum Rollout von Samsungs One UI 5.1 für die ersten Modelle jenseits der ne...