11
Sicherheitsrisiko: Die Krux mit 7-Zip
Bei vielen Anwendern ist das Tool 7-Zip zum Entpacken von Archivdateien im Einsatz. Die Software ist kostenlos und steht auch in einer portablen Version für Windows zur Verfügung. Zudem wird 7-Zip in diversen Produkten mit verwendet. Alles eitel Sonnenschein? Leider gibt es eine dunkle Seite von 7-Zip, denn das Tool ist potentiell eine wandelnde Sicherheitslücke. Hier einige Hinweise, was man wissen sollte - und ein abschließender Ratschlag.
Kernfunktion eines Programms wie 7-Zip ist das Entpacken von Archivdateien, wobei diverse Formate unterstützt werden sollen. Das macht 7-Zip auch ganz gut. Nachfolgende Abbildung zeigt die unterstützten Formate, die sich mit 7-Zip verknüpfen lassen.
Leider gibt es bei dieser Kernfunktion ein Problem: Der Inhalt der zu entpackenden Archivdateien (sprich: Malware) könnte Sicherheitslücken in 7-Zip & Co. ausnutzen, um Schadcode zu extahieren und auszuführen. Dazu sind beim Entpacken Speicherüberläufe zu provozieren, die u.U. zur Codeausführung missbraucht werden können. Oder direkt ausgedrückt: Der Anwender entpackst nichtsahnend eine Datei, und dabei wird ein in der Datei enthaltener Schädling aktiv und manipuliert die unter dem Benutzerkonto erreichbaren Dateien. Das ist etwas, was kein Benutzer bei 7-Zip erwartet, was aber nicht unrealistisch ist.
Das Programm 7-Zip wird von Igor Pavlov entwickelt und kostenlos zur Verfügung gestellt. Eigentlich darf man da nicht maulen - einem geschenkten Gaul schaut man nicht ins Maul. Wenn das Viech aber zum Sicherheitsrisiko wird, schaut die Sachlage möglicherweise anders aus.
Leider werden immer wieder Sicherheitslücken in 7-Zip und den unterlagerten Bibliotheken mit den Funktionen zum Packen gefunden. Ich hatte kürzlich in meinem Blog im Beitrag 7-Zip mit Sicherheitslücken – updaten! über Sicherheitslücken in diesem Tool berichtet und ein Update auf die Version 18.0 und höher empfohlen. Igor Pavlov hatte nach der Entdeckung der Sicherheitslücken schnell reagiert und die Version 18.01 von 7-Zip bereitgestellt. So weit so gut.
Allerdings gibt es wohl Szenarien, wo noch ältere Versionen von 7-Zip zum Einsatz gelangen. Und auch Drittanbieter verwenden mitunter 7-Zip (oder Teilfunktionen) in ihren Programmen. Dort könnten dann ältere Versionen der Bibliotheken oder des Programms bei Installation oder Update auf das System kommen. Das wäre der 'erste Dorn' in Punkto Sicherheit, wobei viele Anwender dort, zugegebenermaßen, überhaupt nichts von dem Dilemma '7-Zip-Variante mit Sicherheitslücken arbeitet auf meinem System' mitbekommen oder wenig bis keinen Einfluss auf diesen Sachverhalt haben.
Für den Fall, dass man ältere, angreifbare 7-Zip-Varianten (warum auch immer) auf seinem System einsetzen muss, gäbe es die Möglichkeit, die Sicherheitslücken CVE-2017-17969 und CVE-2018-5996 durch Micro-Patches von 0patch.com zu beheben. Auf diesen Ansatz hatte ich in meinem Blog-Beitrag hier kurz hingewiesen. In der nachfolgenden Betrachtung schließe ich dieses Szenario aber wegen seiner Komplexität aus.
Kommen wir nun zum Aufhänger für diesen Beitrag - oder anders ausgedrückt: Zum Kern der Sache. Wer mich fragt, erhält den Ratschlag, aus Sicherheitsgründen bis auf weiteres auf 7-Zip zu verzichten. Warum? Der Grund: Das Tool ist ein wandelndes Sicherheitsrisiko, weil dessen Entwickler bewusst auf eine Härtung gegen unbekannte Sicherheitslücken verzichtet. Dazu muss man etwas ausholen. Um Software im Hinblick auf die Ausnutzbarkeit von unbekannten Sicherheitslücken zu härten, können Entwickler verschieden Optionen beim Binden (Linken) der Module zu einer ausführbaren Binärdatei angeben. In diesem Microsoft-Dokument werden zwei solcher Optionen zur Verbesserung der Anwendungssicherheit vorgestellt. Es gibt weitere Techniken dieser Art, die teilweise seit vielen Jahren bekannt sind.
Das Problem: Der Entwickler von 7-Zip verzichtet seit Jahren auf den Einsatz dieser oben erwähnten Optionen. Die 7-Zip Binärdateien für Windows werden ohne die Linker-Optionen /NXCOMPAT und /DYNAMICBASE gebunden. Das bedeutet, dass 7-Zip auf allen Windows-Systemen ohne ASLR läuft. Und DEP ist nur unter 64-Bit-Windows-Systemen sowie in der 32-Bit-Version von Windows 10 aktiviert.
(Quelle: landave.io)
In obigem Bild ist zu sehen, dass DEP permanent deaktiviert wurde. Darüber hinaus wird 7-Zip ohne das /GS-Flag kompiliert, so dass es keine Stack-Überwachung gibt. Das geschieht nicht aus Unwissen. Mir sind zwei (glaubhafte) Quellen bekannt, wo Sicherheitsforscher, nach Entdeckung von Sicherheitslücken, Igor Pavlov auf das Manko hingewiesen haben. Im Hinblick auf 'aus dem Nähkästchen geplaudert': Pavlov weigert sich, /DYNAMICBASE zu aktivieren, um Binärdateien ohne Relocation-Tabelle zu erstellen und so eine minimale Binärgröße zu erreichen. Außerdem verzichtet er auf die Aktivierung des /GS-Flags im Compilter, da der generierte Prüfcode die Laufzeit und die Binärgröße beeinflussen könnte. Es gibt die Information, dass Pavlov versuchen will, zumindest das Flag /NXCOMPAT für die nächste Version von 7-Zip zu aktivieren. Der Hintergrund ist schon abenteuerlich: Anscheinend ist die Option derzeit nicht aktiviert, da 7-Zip mit einem veralteten Linker verknüpft ist, der das Flag nicht unterstützt.
Und damit gibt es ein Problem: 7-Zip ist zwar kostenlos, aber dessen Autor setzt veraltete Entwicklungstools ein und will ein paar Bytes in der Programmdatei auf Kosten der Sicherheit sparen. Angesichts der von mir in den vorhergehenden Absätzen skizzierten Problemstellung bleibt momentan (in meinen Augen) nur, von der Verwendung des Tools abzusehen.
Das Problem der Packprogramme wie 7-Zip
Kernfunktion eines Programms wie 7-Zip ist das Entpacken von Archivdateien, wobei diverse Formate unterstützt werden sollen. Das macht 7-Zip auch ganz gut. Nachfolgende Abbildung zeigt die unterstützten Formate, die sich mit 7-Zip verknüpfen lassen.Leider gibt es bei dieser Kernfunktion ein Problem: Der Inhalt der zu entpackenden Archivdateien (sprich: Malware) könnte Sicherheitslücken in 7-Zip & Co. ausnutzen, um Schadcode zu extahieren und auszuführen. Dazu sind beim Entpacken Speicherüberläufe zu provozieren, die u.U. zur Codeausführung missbraucht werden können. Oder direkt ausgedrückt: Der Anwender entpackst nichtsahnend eine Datei, und dabei wird ein in der Datei enthaltener Schädling aktiv und manipuliert die unter dem Benutzerkonto erreichbaren Dateien. Das ist etwas, was kein Benutzer bei 7-Zip erwartet, was aber nicht unrealistisch ist.
7-Zip und die Sicherheitslücken
Das Programm 7-Zip wird von Igor Pavlov entwickelt und kostenlos zur Verfügung gestellt. Eigentlich darf man da nicht maulen - einem geschenkten Gaul schaut man nicht ins Maul. Wenn das Viech aber zum Sicherheitsrisiko wird, schaut die Sachlage möglicherweise anders aus.Leider werden immer wieder Sicherheitslücken in 7-Zip und den unterlagerten Bibliotheken mit den Funktionen zum Packen gefunden. Ich hatte kürzlich in meinem Blog im Beitrag 7-Zip mit Sicherheitslücken – updaten! über Sicherheitslücken in diesem Tool berichtet und ein Update auf die Version 18.0 und höher empfohlen. Igor Pavlov hatte nach der Entdeckung der Sicherheitslücken schnell reagiert und die Version 18.01 von 7-Zip bereitgestellt. So weit so gut.
Allerdings gibt es wohl Szenarien, wo noch ältere Versionen von 7-Zip zum Einsatz gelangen. Und auch Drittanbieter verwenden mitunter 7-Zip (oder Teilfunktionen) in ihren Programmen. Dort könnten dann ältere Versionen der Bibliotheken oder des Programms bei Installation oder Update auf das System kommen. Das wäre der 'erste Dorn' in Punkto Sicherheit, wobei viele Anwender dort, zugegebenermaßen, überhaupt nichts von dem Dilemma '7-Zip-Variante mit Sicherheitslücken arbeitet auf meinem System' mitbekommen oder wenig bis keinen Einfluss auf diesen Sachverhalt haben.
Für den Fall, dass man ältere, angreifbare 7-Zip-Varianten (warum auch immer) auf seinem System einsetzen muss, gäbe es die Möglichkeit, die Sicherheitslücken CVE-2017-17969 und CVE-2018-5996 durch Micro-Patches von 0patch.com zu beheben. Auf diesen Ansatz hatte ich in meinem Blog-Beitrag hier kurz hingewiesen. In der nachfolgenden Betrachtung schließe ich dieses Szenario aber wegen seiner Komplexität aus.
Warum ich auf 7-Zip im Interesse der Sicherheit verzichten würde
Kommen wir nun zum Aufhänger für diesen Beitrag - oder anders ausgedrückt: Zum Kern der Sache. Wer mich fragt, erhält den Ratschlag, aus Sicherheitsgründen bis auf weiteres auf 7-Zip zu verzichten. Warum? Der Grund: Das Tool ist ein wandelndes Sicherheitsrisiko, weil dessen Entwickler bewusst auf eine Härtung gegen unbekannte Sicherheitslücken verzichtet. Dazu muss man etwas ausholen. Um Software im Hinblick auf die Ausnutzbarkeit von unbekannten Sicherheitslücken zu härten, können Entwickler verschieden Optionen beim Binden (Linken) der Module zu einer ausführbaren Binärdatei angeben. In diesem Microsoft-Dokument werden zwei solcher Optionen zur Verbesserung der Anwendungssicherheit vorgestellt. Es gibt weitere Techniken dieser Art, die teilweise seit vielen Jahren bekannt sind.Das Problem: Der Entwickler von 7-Zip verzichtet seit Jahren auf den Einsatz dieser oben erwähnten Optionen. Die 7-Zip Binärdateien für Windows werden ohne die Linker-Optionen /NXCOMPAT und /DYNAMICBASE gebunden. Das bedeutet, dass 7-Zip auf allen Windows-Systemen ohne ASLR läuft. Und DEP ist nur unter 64-Bit-Windows-Systemen sowie in der 32-Bit-Version von Windows 10 aktiviert.
In obigem Bild ist zu sehen, dass DEP permanent deaktiviert wurde. Darüber hinaus wird 7-Zip ohne das /GS-Flag kompiliert, so dass es keine Stack-Überwachung gibt. Das geschieht nicht aus Unwissen. Mir sind zwei (glaubhafte) Quellen bekannt, wo Sicherheitsforscher, nach Entdeckung von Sicherheitslücken, Igor Pavlov auf das Manko hingewiesen haben. Im Hinblick auf 'aus dem Nähkästchen geplaudert': Pavlov weigert sich, /DYNAMICBASE zu aktivieren, um Binärdateien ohne Relocation-Tabelle zu erstellen und so eine minimale Binärgröße zu erreichen. Außerdem verzichtet er auf die Aktivierung des /GS-Flags im Compilter, da der generierte Prüfcode die Laufzeit und die Binärgröße beeinflussen könnte. Es gibt die Information, dass Pavlov versuchen will, zumindest das Flag /NXCOMPAT für die nächste Version von 7-Zip zu aktivieren. Der Hintergrund ist schon abenteuerlich: Anscheinend ist die Option derzeit nicht aktiviert, da 7-Zip mit einem veralteten Linker verknüpft ist, der das Flag nicht unterstützt.
Und damit gibt es ein Problem: 7-Zip ist zwar kostenlos, aber dessen Autor setzt veraltete Entwicklungstools ein und will ein paar Bytes in der Programmdatei auf Kosten der Sicherheit sparen. Angesichts der von mir in den vorhergehenden Absätzen skizzierten Problemstellung bleibt momentan (in meinen Augen) nur, von der Verwendung des Tools abzusehen.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 365378
Url: https://administrator.de/contentid/365378
Printed on: April 23, 2024 at 08:04 o'clock
11 Comments
Latest comment
Danke für Deinen Beitrag. Der ist sehr informativ.
Der Autor stellt aber auch den Source-Code zu seinem Programm bereit.
Verbessern wollte es wohl keiner, oder sehe ich das falsch?
Der Autor stellt aber auch den Source-Code zu seinem Programm bereit.
Verbessern wollte es wohl keiner, oder sehe ich das falsch?
Das Problem ist nicht der Source-Code (in meinem eigenen Blog gehen die Wogen in der Diskussion hoch her). Das Problem ist, dass der Autor die seit vielen Jahren gängigen Linker-Optionen und Compiler-Flag nicht einsetzt. Rein durch Inspektion des Quellcodes wird man imho nie die potentiellen Sicherheitslücken aufdecken können - es wäre ein Sicherheits-Auditing mit formalen Beweisen gefordert (und dann dürfte nichts mehr verändert werden). Das ist aber bei 7-Zip nicht leistbar.
Ergo muss ich davon ausgehen, dass in der Software (wie auch in anderen Tools) Schwachstellen wie Pufferüberläufe existieren, die durch Malware beim Entpacken ausgenutzt werden könnte. Seit vielen Jahren sind Techniken bekannt, um zumindest die praktische Ausnutzbarkeit zu erschweren. Wenn jemand dann argumentiert: Aber dadurch wird mein Programm größer und langsamer, daher lasse ich das weg, wird es übel. Und da setzt mein obiger Beitrag an. Aber alleine durch den Blog-Beitrag bei mir sowie den Artikel hier bei administrator.de (die verfasse ich in Absprache mit dem Hausmeister Frank) ist das Thema zumindest bei einigen Leuten ins Bewusstsein gerückt.
Entscheiden, wie er verfährt, muss jeder selbst.
Ergo muss ich davon ausgehen, dass in der Software (wie auch in anderen Tools) Schwachstellen wie Pufferüberläufe existieren, die durch Malware beim Entpacken ausgenutzt werden könnte. Seit vielen Jahren sind Techniken bekannt, um zumindest die praktische Ausnutzbarkeit zu erschweren. Wenn jemand dann argumentiert: Aber dadurch wird mein Programm größer und langsamer, daher lasse ich das weg, wird es übel. Und da setzt mein obiger Beitrag an. Aber alleine durch den Blog-Beitrag bei mir sowie den Artikel hier bei administrator.de (die verfasse ich in Absprache mit dem Hausmeister Frank) ist das Thema zumindest bei einigen Leuten ins Bewusstsein gerückt.
Entscheiden, wie er verfährt, muss jeder selbst.
Hallo zusammen,
da der Source Code ja veröffentlicht ist: Kann das nicht einer meiner Entwickler für meine Firma zum internen Einsatz neu kompilieren?
Oder fehlen da noch irgendwelche DLLs?
Grüße
Jörg
da der Source Code ja veröffentlicht ist: Kann das nicht einer meiner Entwickler für meine Firma zum internen Einsatz neu kompilieren?
Oder fehlen da noch irgendwelche DLLs?
Grüße
Jörg
Welche (sicheren) Alternativen gibt es denn? Wie sieht es bspw mit WinRar aus?
Zu "da der Source Code ja veröffentlicht ist: Kann das nicht einer meiner Entwickler für meine Firma zum internen Einsatz neu kompilieren?"
Kann ich nicht beurteilen bzw. beantworten - da ich mich seit mindestens 10 Jahren aus der Thematik Entwicklung zurückgezogen habe (damals sind meine letzten Bücher zu dem Thema entstanden) und meine aktiven Zeiten als Entwickler in der Industrie so zwischen 1981 und 1985 waren (bis 1993 habe ich dann nur noch geschaut, dass meine Leute das Zeugs zum Laufen brachten). Und ich werde in meinem hohen Alter auch nicht mehr auf diesen 'Schlitten' und in das compilieren eines solchen Pakets einsteigen
.
Kann ich nicht beurteilen bzw. beantworten - da ich mich seit mindestens 10 Jahren aus der Thematik Entwicklung zurückgezogen habe (damals sind meine letzten Bücher zu dem Thema entstanden) und meine aktiven Zeiten als Entwickler in der Industrie so zwischen 1981 und 1985 waren (bis 1993 habe ich dann nur noch geschaut, dass meine Leute das Zeugs zum Laufen brachten). Und ich werde in meinem hohen Alter auch nicht mehr auf diesen 'Schlitten' und in das compilieren eines solchen Pakets einsteigen
.
@122501: Welche (sicheren) Alternativen gibt es denn?
Ich plane im Hinterkopf einen Artikel (vorerst nur in meinem Blog - vermutlich werde ich das hier auf administrator.de auch einstellen - muss ich mit Frank absprechen), der Lösungen mit Bordmitteln vorstellt. Dazu brauche ich a) etwas Zeit und würde b) das Ganze dann mit den Leuten, die sich professionell mit Sicherheit beschäftigen nochmals abstimmen.
Denkbar wäre auch, das Ganze mit EMET zu härten. Dazu findet sich dieser Kommentar in meinem Blog. EMET hinterlässt aber ggf. Kollateralschäden (und wird im Sommer eingestellt).
Aktuell ist mir wichtig, dass das Thema überhaupt bekannt ist und jeder bewusst damit umgeht.
Ich plane im Hinterkopf einen Artikel (vorerst nur in meinem Blog - vermutlich werde ich das hier auf administrator.de auch einstellen - muss ich mit Frank absprechen), der Lösungen mit Bordmitteln vorstellt. Dazu brauche ich a) etwas Zeit und würde b) das Ganze dann mit den Leuten, die sich professionell mit Sicherheit beschäftigen nochmals abstimmen.
Denkbar wäre auch, das Ganze mit EMET zu härten. Dazu findet sich dieser Kommentar in meinem Blog. EMET hinterlässt aber ggf. Kollateralschäden (und wird im Sommer eingestellt).
Aktuell ist mir wichtig, dass das Thema überhaupt bekannt ist und jeder bewusst damit umgeht.
Als ich mich zuletzt mit WinRAR befasst habe, war es nicht multisprachenfähig - ich brauche deutsch, englisch, polnisch, spanisch und chinesisch - und es hatte den Makel, dass man in einem SFX-Archiv automatisch startende Skripte bestimmen konnte.
Aber das mag sich inzwischen geändert haben.
Aber das mag sich inzwischen geändert haben.
Hallo,
danke für den Beitrag! Finde ich schade, dass bei so einem Programm, solche Sicherheitstechniken nicht benutzt werden, obwohl es ja anscheinend recht trivial ist, die einzusetzen.
Spricht was dagegen, den Source Code von 7zip zu nehmen und selbst mit den Linker und Compiler Optionen zu kompilieren?
danke für den Beitrag! Finde ich schade, dass bei so einem Programm, solche Sicherheitstechniken nicht benutzt werden, obwohl es ja anscheinend recht trivial ist, die einzusetzen.
Spricht was dagegen, den Source Code von 7zip zu nehmen und selbst mit den Linker und Compiler Optionen zu kompilieren?
Imho nein - wer die Tools hat, kann es versuchen.
Vielen Dank für den Beitrag.
Ich kann zu dem Sicherheitsproblem noch etwas hinzufügen, das Du oben noch nicht genannt hast.
Situation:
Windows RDS-/Terminalserver, viele Admins konfigurieren eine GPO, die Laufwerke/Laufwerksbuchstaben ausblendet, vor allem das Start- und Systemlaufwerk C:\, damit die Terminalservernutzer es erst gar nicht zu sehen bekommen, was ich sinnvoll finde, bevor die auf dumme Gedanken kommen und Tipps aus der Computerbild auf irgendetwas unterhalb von C:\ anwenden wollen.
7-Zip hält sich nicht an solche GPOs, sondern erlaubt in/aus seinen Speichern- und Öffnen-Dialogen das Browsen in allen Laufwerken, eben auch in denjenigen, die gar nicht zu sehen sein sollen.
Als ich das mal mit anderen Programmen auf einem Test-TS gegengeprüft habe, hatte ich zunächst vermutet, daß die GPO dann vielleicht Microsoft-/Windows-Explorer-"Only" ist und deshalb bei Programmen von Drittherstellern nicht wirkt. Ich konnte dabei zwar nicht alle Programme der Welt ausprobieren, jedoch fand ich sonst keines, das sich in seinen Speichern-/Öffnen-Dialogen nicht daran hielt, ausgeblendete Laufwerke nicht anzuzeigen, 7-Zip war das einzige. Auch Dritthersteller-Dateimanager wie Total- oder Speedcommander hielten sich an das "Anzeigeverbot". Letztlich entschieden wir uns (das war bei einem ehem. AG) gegen 7-Zip auf TS, es wurde dann stattdessen dieser hier, mit dem ich bis heute hochzufrieden bin, verwendet: http://www.izarc.org.
Viele Grüße
von
departure69
Ich kann zu dem Sicherheitsproblem noch etwas hinzufügen, das Du oben noch nicht genannt hast.
Situation:
Windows RDS-/Terminalserver, viele Admins konfigurieren eine GPO, die Laufwerke/Laufwerksbuchstaben ausblendet, vor allem das Start- und Systemlaufwerk C:\, damit die Terminalservernutzer es erst gar nicht zu sehen bekommen, was ich sinnvoll finde, bevor die auf dumme Gedanken kommen und Tipps aus der Computerbild auf irgendetwas unterhalb von C:\ anwenden wollen
.7-Zip hält sich nicht an solche GPOs, sondern erlaubt in/aus seinen Speichern- und Öffnen-Dialogen das Browsen in allen Laufwerken, eben auch in denjenigen, die gar nicht zu sehen sein sollen.
Als ich das mal mit anderen Programmen auf einem Test-TS gegengeprüft habe, hatte ich zunächst vermutet, daß die GPO dann vielleicht Microsoft-/Windows-Explorer-"Only" ist und deshalb bei Programmen von Drittherstellern nicht wirkt. Ich konnte dabei zwar nicht alle Programme der Welt ausprobieren, jedoch fand ich sonst keines, das sich in seinen Speichern-/Öffnen-Dialogen nicht daran hielt, ausgeblendete Laufwerke nicht anzuzeigen, 7-Zip war das einzige. Auch Dritthersteller-Dateimanager wie Total- oder Speedcommander hielten sich an das "Anzeigeverbot". Letztlich entschieden wir uns (das war bei einem ehem. AG) gegen 7-Zip auf TS, es wurde dann stattdessen dieser hier, mit dem ich bis heute hochzufrieden bin, verwendet: http://www.izarc.org.
Viele Grüße
von
departure69
1
Zum http://www.izarc.org - Bezüglich der von mir oben angesprochenen Problematik kommst Du mit dem Tool vom Regen in die Traufe. Keine Signatur, InnoSetup, keine Prüfsumme des Install-Programms, Installationsprogramm ohne /GS, ohne /NXCOMPAT und ohne /DYNAMICBASE compiliert/gelinkt ...
