Nachdem ich das hochinteressante Paper Trojan Source: Invisible Vulnerabilities gelesen hatte kam ich durch einen Post auf Mastodon (leider nicht öffentlich einsehbar) auf Ideen... auf Ideen...

Der Mastodon-Post zeigte eine Tabelle in psql, die eine Spalte beinhaltete, deren Name ein Kätzchen war (Unicode-Emoji). Der sorgte dafür, dass sämtliche Projekte einen Platz auf meiner Liste nach unten rutschten, denn ich wollte nun wissen, ob das in dem Paper vorgestellte Verfahren auch dazu benutzt werden könnte, schadhaften SQL-Code vor einem Reviewer zu verstecken.

Dazu stellte ich mir zunächst eine einfache Aufgabe: Ich wollte einen Spaltennamen oder allgemeiner: Identifier mit solchen nicht sichtbaren Unicode-Zeichen versehen, sodass der Code in einem Editor, Terminal oder dem Datenbanktool des Vertrauens anders aussähe, als das, was die Datenbank verarbeitet. Dazu bereitete ich ein SQL-Statement vor, das einen zusammengesetzten Spaltennamen SpaltenName enthielt, der allerdings mit entsprechenden Bidi-Codes so ergänzt war, dass eine Software, die diese Codes interpretiert stattdessen NameSpalten anzeigen müsste.

Hier ein Beispiel dafür in Gedit 2.36.2 unter Ubuntu Focal Fossa:

SQL-Script in Gedit 2.36.2

Ich freue mich sagen zu können, dass auch die sQLshell sich hier nicht hereinlegen lässt (und damit auch den Anwender nicht hereinlegt) - sie zeigt an, dass im SQL weitere Zeichen enthalten sind:

SQL-Script in sQLshell

Intellij Idea stellt die Goldrandlösung dar: solche Codes werden nicht nur nicht interpretiiert, sondern stattdessen als Pseudo-Zeichen dargestellt:

SQL-Script in sQLshell

Nachdem ich mir also verschiedene Editoren und IDEs zum Umgang mit diesen speziallen UInicode-Characters angesehen hate, wollte ich herausbekommen, wie sich eine Datenbank verhält, wenn sie ein mit solchen Zeichen versehenes Statement vorgesetzt bekommt. Meine ersten Tests führte ich mit einer etwas veralteten Version Postgres durch:

Postgres Version im Test

Ich benutzte zur Interaktion damit zunächst psql in verschiedenen Terminals - darunter gnome-terminal und CoolRetroTerm. Interessant fand ich dabei zunächst, dass in diesen Terminals die Steuercodes im Statement nicht angezeigt und auch nicht interpretiert wurden - Man hätte meinen können, dass dieses Statement überhaupt keine Steuerzeichen enthielt:

SQL-Script in CoolRetroTerm

Jetzt wurde ich natürlich neugierig, ob sich das Statement absetzen lassen würde - es funktionierte. Und bei der Abfrage der Tabellenstruktur in psql mittels \d bidi erhielt ich daraufhin folgendes Ergebnis:

Tabellenstruktur mittels psql in CoolRetroTerm

Ein entsprechendes Select schlug aber fehl:

Select-Statement und Ergebnis mittels psql in CoolRetroTerm

Ein normaler Mensch wäre jetzt zunächst erst einmal verwirrt: Er sieht den Spaltennamen, aber wenn er ihn benutzen möchte, bekommt er als Fehlermeldung, dass exakt dieser - den erwomöglich auch noch aus der Antwort auf das vorhergehende Statement kopiert hat - nicht existiert? Was ist denn hier passiert? Die Erklärung wird offensichtlich, wenn man sich die Tabellenstruktur in anderen Datenbank-Werkzeugen ansieht - zum Beispiel in der sQLshell:

Tabellenstruktur in der sQLshell

Man erkennt, dass die Control-Characters einfach Teil des Identifiers geworden sind. Um die Anfrage korrekt zu formulieren, müssen diese also auch wieder im Namen auftauchen.

Postgres ist auch konsistent: Wenn die Tabelle mittels pg_dump exportiert wird, ist das Ergebnis eine Text-Datei in Unicode-Encoding, in dem - mit Gedit betrachtet - wieder der Name NameSpalten auftaucht, da alle Zeichen exportiert wurden und diese natürlich wieder interpretiert werden:

Ergebnis von pg_dump in Gedit 2.36.2

Leider (oder glücklicherweise - kommt ganz auf die Perspektive an) konnte ein tatsächlicher, ernstzunehmender Angriff auf Postgres nicht durchgeführt werden, weil alle Zeichen in einem Statement interpretiert werden und die Bidi-Codes in diesem Kontext keine gültigen Zeichen für Postgres darstellen. Das sind sie nur in Identifiern und mit dieser Einschränkung war es (zumindest mir) nicht möglich, klassische Szenarien wie sie beispielsweise aus SQL-Injection bekannt sind - etwa Tabellen löschen oder Datensätze ändern - umzusetzen.

Artikel, die hierher verlinken