Ein Wort zu ImageTragick (CVE-2016-3714)
Heute früh am Morgen wurde ein kritischer Fehler in ImageMagick bekannt, der schnell den Spitznamen ImageTragick erhielt. Transloadit ist Sponsor und langjähriger Nutzer von ImageMagick, daher überrascht es nicht, dass sich viele Sorgen machen, Transloadit könnte von diesem Fehler betroffen sein. Ehrlich gesagt waren auch wir besorgt.
Bisher ist es uns nicht gelungen, unseren Service mit diesem Fehler auszunutzen, obwohl der Exploit-Code noch nicht veröffentlicht wurde. Die Untersuchung läuft noch, aber wir können mit einiger Sicherheit sagen, dass wir nicht betroffen sein dürften. Schon bevor dieser Fehler in ImageMagick bekannt wurde, hatten wir bereits ein System, das prüft, ob eine Datei, die als Bild deklariert wird, tatsächlich auch ein Bild ist. Dafür verwenden wir eine Software namens ExifTool, die ausreichenden Schutz vor Exploits bieten sollte, die diesen Fehler nutzen.
Wir haben inzwischen bei ihrem Autor Phil Harvey nachgefragt, und er versicherte uns Folgendes:
ExifTool analysiert den Anfang der Datei, um den Dateityp zu bestimmen. Bei den meisten Typen ist das, wie Sie erwähnt haben, lediglich eine Magic-Number-Prüfung, bei einigen Typen ohne Magic Number ist jedoch etwas Verarbeitung nötig. Exiftool verwendet die Dateiendung nur als Hinweis auf die jeweilige Dateivariante, wenn es mehrere Dateitypen mit demselben Format gibt (z. B. ASF/WMV/WMA/DIVX oder DOC/PPT/XLA).
Wird die Datei nicht erkannt, so wird kein MIMEType zurückgegeben und ExifTool gibt den Fehler „Unknown file type“ aus.
Abgesehen von den veröffentlichten Workarounds, schützt dieses Werkzeug Transloadit vorerst also ausreichend, und Sie können unseren Service bedenkenlos weiter nutzen.
Aber was, wenn in ein oder zwei Monaten schwerwiegendere Sicherheitslücken in ImageMagick entdeckt werden? Oder, was das betrifft, in ExifTool?
Das gibt durchaus Anlass zur Sorge. Jedes Werkzeug hat natürlich seinen Anteil an Fehlern, und viele davon lassen sich ausnutzen. Solche Fehler werden in der Regel schnell behoben, und Nutzer sollen so schnell wie möglich aktualisieren. Aber andererseits.. kann Transloadit nicht immer sofort aktualisieren, da wir die Abwärtskompatibilität für unsere Nutzer wahren müssen. Idealerweise halten wir jede Software aktuell, während wir ältere Versionen behutsam als veraltet markieren und sie längere Zeit weiter unterstützen, damit Kunden die Möglichkeit haben, neue Versionen zu prüfen und sich darauf einzustellen, statt plötzliche Aktualisierungen über Nacht vornehmen zu müssen.
Es ist klar, dass wir einschränken müssen, was unsere Werkzeuge (falsch) machen können, um Zeit zu gewinnen, falls uns die nächste Sicherheitslücke härter trifft.
Von Anfang an führen wir unsere Werkzeuge unter einem nicht privilegierten Systembenutzer aus, der keinen Zugriff auf geheime Schlüssel hat. Angreifer befänden sich jedoch weiterhin auf dem Hostsystem. Gäbe es also einen Zero-Day-Root-Exploit, hätten wir ein Problem. Weitere Sicherheitsebenen wären daher noch besser.
Deshalb haben parallel zur Bewertung dieser Sicherheitslücke und zu unseren Versuchen, einen Exploit zu entwickeln, verschiedene Teammitglieder damit begonnen, unsere Encoding-Werkzeuge zu containerisieren. So haben unsere Werkzeuge außer den Mediendateien, die sie verarbeiten müssen, keinen Zugriff auf irgendetwas auf dem Hostsystem. Das würde es uns sogar erlauben, angreifbare Werkzeuge in der Produktion zu betreiben, ohne Angreifern die Gelegenheit zu geben, andere auszuspähen oder auf andere Weise ernsthaften Schaden anzurichten.
Das wird natürlich einige Zeit in Anspruch nehmen, und wir werden die Unterstützung dafür schrittweise ausrollen.
Leider ist 100 % Sicherheit ein Mythos, doch wir hoffen, Sie können sich darauf verlassen, dass wir Transloadit so sicher halten, wie wir nur können. Wenn Sie weitere Fragen oder Bedenken zu diesem Thema haben, zögern Sie nicht, uns zu kontaktieren.
Update 2016-07-01: Wir haben festgestellt, dass wir für einen sicheren containerisierten Betrieb unserer Encoding-Werkzeuge warten möchten, bis wir einmalige Jobs ohne sudo-Rechte ausführen können. Daran wird gearbeitet. In der Zwischenzeit haben wir ein großes Update fertiggestellt und ausgerollt, sodass unsere Encoding-Maschinen (die für diese Art von Angriffen am anfälligsten wären) jetzt ohne jegliche Secrets laufen. Sie können Jobs per Read-only aus einer Queue entnehmen und sie per Append-only exportieren. Alle anderen Secrets und Berechtigungen wurden entfernt.
Update 2016-08-02: Wir arbeiten mit dem Sicherheitsforscher Florian Courtial zusammen, um zusätzliche Filter für schadhafte SVG-Bilder hinzuzufügen, für die wir in einigen Fällen noch anfällig waren (auch wenn seit der Abrüstung der Encoding-Maschinen kein echter Schaden mehr hätte entstehen können).