Behebung einer Remote-Codeausführungsschwachstelle in EJS

Diese Woche haben wir eine schwerwiegende Remote-Codeausführungsschwachstelle im Paket EJS in unsere Schwachstellendatenbank aufgenommen.

EJS (Embedded JavaScript Templates) ist eine schnelle, einfache und sehr beliebte JavaScript-Template-Engine. EJS bietet Ihnen verschiedene Möglichkeiten, ein Template zu rendern. Zwei davon, render und renderFile, sind sich recht ähnlich. Der einzige Unterschied besteht darin, dass render einen String als Template erwartet, während renderFile den Pfad zu einer Template-Datei erwartet. Beide Methoden akzeptieren außerdem Argumente für die Daten sowie eine optionale Konfiguration. Die Methode renderFile akzeptiert zusätzlich eine Callback-Funktion.

1ejs.render(str, data, options);
2
3ejs.renderFile(filename, data, options, callback)

Bei beiden Methoden können Sie Daten und Optionen auch zu einem einzigen Objekt zusammenfassen.

1ejs.render(str, dataAndOptions);
2
3ejs.renderFile(filename, dataAndOptions, callback)

Die Schwachstelle

Die Kurzform mag einfacher erscheinen, doch die Kombination von Daten und Optionen kann mit der Zeit zu Fehlern führen. Falls das noch kein überzeugender Grund ist, gibt es einen besseren: Die Verwendung der Kurzform kann Ihre Anwendung einer Remote-Codeausführungsschwachstelle aussetzen.

Die kompilierten EJS-Templates können mithilfe einer Include-Direktive weitere Dateien einbinden.

1<%- include('path/to/include'); %>

Standardmäßig sind diese Includes relativ zum Template. Liegt das Template im Ordner templates, sucht EJS in templates/path/to/include nach der einzubindenden Datei.

Eine der verfügbaren Konfigurationsoptionen ist root. Damit können Sie den Standardspeicherort ändern, aus dem diese Includes geladen werden.

Wenn Sie die Optionen als separates Argument übergeben, ist das kein Problem. Ein Problem entsteht jedoch, wenn Sie Optionen und Daten in einem einzigen Objekt zusammenfassen. Übermittelt die Methode eine Liste der vom Benutzer bereitgestellten Daten, könnte ein Angreifer auch eine root -Option einschleusen.

1ejs.renderFile('my-template', {root:'/bad/root/'}, callback);

Wird die root-Direktive wie in der obigen Zeile übergeben, werden alle Includes statt aus dem vorgesehenen Pfad aus /bad/root geladen. Das kann zur Remote-Codeausführung führen.

Die Möglichkeit, das Root-Verzeichnis zu konfigurieren, kann für Entwickler, die die EJS-Engine verwenden, nützlich sein. Wird diese Konfiguration jedoch in einem Objekt zusammen mit Benutzerdaten ermöglicht, entsteht ein erhebliches Sicherheitsrisiko. Entwickler könnten zwar Maßnahmen ergreifen, um die Eingaben zu bereinigen, doch die Engine selbst wäre standardmäßig unsicher.

Unser Sicherheitsteam entdeckte das Problem und meldete es am 27. November. Der Projektverantwortliche Matthew Eernisse entwickelte eine einfache Lösung, bei der die Option root auf eine Sperrliste gesetzt wird, sodass sie nicht zusammen mit Benutzerdaten übergeben werden kann.

Schwachstellen bleiben nach ihrer erstmaligen Offenlegung häufig lange Zeit ungepatcht. Vielleicht erinnern Sie sich an die XSS-Schwachstelle in Marked, deren Behebung über ein Jahr dauerte. Zum Glück war es diesmal anders. Dank einer bemerkenswert schnellen Veröffentlichung von Matthew wurde die Schwachstelle innerhalb eines Tages nach ihrer Offenlegung behoben. Version 2.5.3 von EJS, veröffentlicht am 28. November, enthält die Behebung.

So beheben Sie das Problem

Wenn Sie Snyk angewiesen haben, Ihr Projekt zu überwachen, und es EJS verwendet, haben Sie wahrscheinlich bereits eine Warnung zu diesem Problem erhalten. Sie können die Schwachstelle beheben, indem Sie entweder über die GitHub-Integration eine Pull-Request über Ihr Dashboard erstellen oder snyk wizard über die Befehlszeile ausführen. In beiden Fällen erkennt Snyk das Problem und fordert Sie auf, das EJS-Paket auf die neueste Version zu aktualisieren.

Wenn Sie Snyk nicht verwenden – das ist in Ordnung, wir mögen Sie trotzdem –, können Sie das Problem beheben, indem Sie EJS manuell auf die neueste Version aktualisieren. Achten Sie darauf, auch alle Abhängigkeiten zu prüfen. Wenn eine davon das EJS-Paket einbindet, wird es nicht in Ihrer Datei package.json angezeigt und die Aktualisierung kann deutlich aufwendiger sein.