English Bei vielen Anwendern ist das Tool 7-Zip im Einsatz. Nachdem ich mich mit dem Thema beschäftigt habe, bin ich zur Erkenntnis gelangt, dass das Programm ein wandelndes Sicherheitsrisiko darstellt. Daher mein Ratschlag an Nutzer das Tools 7-Zip: Vermeidet die Verwendung des kostenlosen Tools 7-Zip und verbannt es von euren Systemen. Ergänzung: Beachtet die Ergänzungen am Artikelende – das Tool wurde in einigen Kritikpunkten überarbeitet.
Anzeige
7-Zip, was ist das?
Das kostenlose Tool 7-Zip ist ein Archivmanager, der neben .zip-Archiven auch weitere unter Windows gebräuchliche Packer-Formate wie .rar, .arj oder .lzh unterstützt.
Ich gestehe, ich nutzte hier gelegentlich die portable Variante (diese muss nicht installiert werden), weil ich damit direkt den Inhalt einer .iso-Datei (Abbild einer CD oder DVD) oder einer .vhd-Datei (virtuelles Laufwerk ohne mounten) anzeigen kann. Auch das Entpacken von Microsofts Update-Paketen ist mit 7-Zip schnell erledigt. Und es unterstützt die vom kostenpflichtigen WinRAR erzeugten Archive im rar-Format.
Igor Pavlov stellt 7-Zip kostenlos zur Verfügung und in einer idealen Welt könnte das Tool eine super Sache sein. Dummerweise leben wir nicht in einer idealen Welt, sondern in einer Welt, in der auch Schadsoftware existiert.
Anzeige
7-Zip als wandelnde Sicherheitslücke
Und in der realen Welt stellt 7-Zip leider so etwas wie ein wandelndes Sicherheitsrisiko dar. Wer 7-Zip zum Entpacken von Archiven aus unbekannten Quellen verwendet, lebt riskant und handelt im Grunde grob fahrlässig! Auf das Risiko bzw. weshalb beim Entpacken eine Gefahr lauert, gehe ich ein paar Abschnitte weiter unten noch gesondert ein.
Aber ist ist bekannt, dass 7-Zip immer wieder Sicherheitslücken aufweist. Ich hatte kürzlich im Blog-Beitrag 7-Zip mit Sicherheitslücken – updaten! über Sicherheitslücken in diesem Tool berichtet und ein Update empfohlen. Leider ist das nicht das Ende, denn es geht noch weiter. Blog-Leser Info weist in diesem Kommentar auf ein grundlegenderes Problem hin. Zitat:
Es gibt Programm-Pakete die 7-Zip als zusätzliches Tool verwenden. Beispielsweise im Verlauf der Produktaktualisierung(automatisches Update).
Auch wenn das aktuellste Z-Zip installiert ist, besteht die Gefahr das veraltete Versionen dieses Tools, in den Programmverzeichnissen des Rechners, vorhanden sind.
Da haben wir also ein gewaltiges Problem. Möglicherweise – ich habe es nicht im Detail analysiert und durchdacht – gibt es da einen Workaround. Denn gestern erreichte mich eine Mail von Across Security zu 7-Zip. Die verfolgen meinen Blog und schlagen immer mal wieder hier mit Mails ein, wenn von denen wieder einmal eine Sicherheitslücke in einem Produkt mittels 0patch geschlossen wurde.
Micro-Patch für CVE-2017-17969 und CVE-2018-5996
In der konkreten Mail bezogen die sich auf die von mir in dem im oben erwähnten Blog Beitrag behandelten Sicherheitslücken CVE-2017-17969 und CVE-2018-5996, die in älteren 7-Zip-Versionen existieren. Hier ein Auszug aus der Mail:
I read your coverage of the two 7-Zip vulnerabilities (CVE-2017-17969 and CVE-2018-5996) in BornCity, and thought you'd be interested in knowing that our company has created 3rd-party micropatches for these issues in an attempt to improve the way vulnerabilities are being fixed today.
Basierend auf dem Blog-Beitrag hier, hat 0patch zwei Fixes für die oben genannten Sicherheitslücken entwickelt und hier beschrieben. In der neuen 7-Zip-Version 18.01 sind beide Lücken geschlossen – aber 0patch stellt mit den Micropatches auf ältere Software-Versionen ab. Möglicherweise härten diese 0patches mit Software installierte ältere 7-Zip-Versionen (aber diese Information ist von meiner Seite nicht valide! – mir fehlt schlicht die Zeit, da zu graben, ob und in welcher Konstellation die Micropatches wirksam werden, wenn alte Versionen mit anderer Software auf's System gelangt – den Staffelstab gebe ich mal an Interessierte weiter).
Das Kernproblem bei 7-Zip
Kommen wir nun zum Kernproblem von 7-Zip und meiner Empfehlung, auf dieses Tool zu verzichten. In den Kommentaren hier im Blog wird das Ganze angerissen, ohne dass vielleicht jedem klar wird, warum es mit 7-Zip ein (Sicherheits-)Problem gibt.
Ich gestehe, als ich den Blog-Beitrag 7-Zip mit Sicherheitslücken – updaten! schrieb, hätte bei mir eigentlich was klingeln müssen. Aber der Groschen ist beim Schreiben auch bei mir nicht gefallen – obwohl eigentlich alle Informationen im Blog-Beitrag stecken. Ein Hinweis aus Kreisen von Leuten, die sich mit Sicherheit befassen und der oben verlinkte Kommentar haben mich veranlasst, diesen Text hier zu schreiben.
Schauen wir ein wenig unter den Teppich. Originäres Ziel beim Einsatz von 7-Zip ist das Entpacken von Archivdateien. Problem ist, dass Sicherheitslücken in 7-Zip dazu ausgenutzt werden können, Schadcode in Archive zu stecken. Beim Entpacken kommt es dann zu Speicherüberläufen, die u.U. zur Codeausführung missbraucht werden können – etwas, was kein Benutzer bei 7-Zip erwartet. Platt ausgedrückt: Du entpackst nichtsahnend eine Datei, um deren Inhalt zu analysieren (und ggf. auf Malware zu untersuchen). Aber bereits beim Entpacken wird der Schädling aktiv und manipuliert die unter deinem Benutzerkonto erreichbaren Dateien – keine sehr angenehme Vorstellung.
Aber das Problem hat noch einen zweiten Namen: Ignoranz seitens des Entwicklers von 7-Zip. Im oben erwähnten Blog-Beitrag 7-Zip mit Sicherheitslücken – updaten! ging es zwar primär um Schwachstellen im Produkt (die behoben sind). Aber der Knackpunkt findet sich nebenbei im Text in folgenden Sätzen:
Im Blog-Beitrag führt Dave aus, dass die 7-Zip Binärdateien für Windows ohne die Compiler-Flags /NXCOMPAT und /DYNAMICBASE übersetzt wurden (Anmerkung: Genau genommen handelt es sich um Optionen des Linkers, mit dem die Binärdatei gebunden wird). 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)Dort ist zu sehen, dass DEP permanent deaktiviert wurde. Darüber hinaus wird 7-Zip ohne /GS-Flag kompiliert, so dass es keine Stack-Überwachung gibt.
Für Blog-Leser-/Innen, die nicht ganz so in der Thematik drin sind: Seit vielen Jahren sind Techniken bekannt, um Software bei der Entwicklung durch Compiler-/Linker-Optionen gegen Schwachstellen zu härten. Der Compiler/Linker kann zwar eine im Code enthaltene Schwachstelle nicht beseitigen. Über Optionen kann man aber als Entwickler dafür sorgen, dass sich diese Schwachstelle nicht oder nur sehr schwierig durch Malware über Speicherüberläufe etc. ausnutzen lässt.
Der Entwickler von 7-Zip verzichtet seit Jahren auf den Einsatz dieser oben erwähnten Optionen. Der Entdecker der oben erwähnten Sicherheitslücken hat diese Thematik mit Igor Pavlov (dem Entwickler von 7-Zip) diskutiert. Er versuchte, Pavlov davon zu überzeugen, die erwähnten Flags zu aktivieren. Dies sollte in aktuellen Software-Produkten gängige Praxis sein, da es dadurch schwerer für Angreifer wird, Sicherheitslücken auszunutzen.
Pavlov weigerte sich jedoch, /DYNAMICBASE zu aktivieren. Hintergrund: Er zieht es, nach Aussagen des Entdeckers der oben genannten Sicherheitslücken, vor, die Binärdateien ohne Relocation-Tabelle zu erstellen, um eine minimale Binärgröße zu erreichen. Außerdem will er /GS nicht aktivieren, da es die Laufzeit und die Binärgröße beeinflussen könnte. Und es findet sich die Information, dass Pavlov versuchen will, zumindest das Flag /NXCOMPAT für die nächste Version von 7-Zip zu aktivieren. Anscheinend ist es derzeit nicht aktiviert, da 7-Zip mit einem veralteten Linker verknüpft ist, der das Flag nicht unterstützt.
Sprich: Der Autor des Werkzeugs setzt irgendwelche veralteten Entwicklungstools ein und will ein paar Bytes im Tool auf Kosten der Sicherheit sparen. Mir liegt noch eine andere Information aus Sicherheitskreisen vor, die ich nicht veröffentlichen kann. Danach wurde Pavlov bereits seit 2015 erfolglos auf die Folgen seines Handelns und mögliche Lösungen hingewiesen – was aber fruchtlos blieb. Man kann es unter Beratungsresistenz verorten. Unter diesen Gesichtspunkten kann man nur raten: Finger weg von diesem Tool, solange dessen Entwicklung auf diese Weise, quasi 'mit der Kneifzange' betrieben wird.
Ergänzung: Da es nachgefragt wurde, mal schauen, wie die Zeit ausschaut – vielleicht ergänze ich das Ganze. Man kann vieles mit Bordmitteln durchführen – und mit Kontextmenübefehlen und Scripten geht es sogar mit Komfort.
Nachtrag: Unkonventionelles Verhalten bei Netzlaufwerken
Gelegentlich blogge ich auch bei administrator.de. Zu meinem Beitrag Sicherheitsrisiko: Die Krux mit 7-Zip kam noch eine interessante Rückmeldung für Administratoren. Per GPO kann man in Windows für Windows RDS-/Terminalserver festlegen, welche Laufwerke die Benutzer sehen dürfen. 7-Zip hält sich nicht an solche GPOs, sondern erlaubt in den Speichern– und Öffnen-Dialogfelder das Browsen in allen Laufwerken (auch in den per GPO ausgeblendeten).
Nachtrag 2: Aktuelle Versionen verwenden
Der Artikel stammt von Anfang 2018. Inzwischen wurden neuere 7-Zip-Versionen wohl mit modernen Compilern und entsprechenden Compiler-Optionen erstellt, so dass die oben beschriebenen Risiken durch Verzicht auf DEP und ASLR in aktuellen 7-Zip-Versionen nicht mehr bestehen sollten. Allerdings sollte man darauf achten, dass 7-Zip aktuell ist. Und noch ein Tipp: Um beim Installer nicht Opfer eines DLL-Hijacking-Angriffs zu werden, empfehle ich, auf die .exe-Installer zu verzichten und stattdessen die .msi-Installer zu verwenden.
Ähnliche Artikel:
7-Zip mit Sicherheitslücken – updaten!
Universalwerkzeug 7-Zip portable
Anzeige
Wäre denn z. B. "PeaZip" eine gute Alternative?
http://winfuture.de/downloadvorschalt,2794.html
https://de.wikipedia.org/wiki/PeaZip
PeaZip nutzt für .7zip auch das Programm 7Zip (Version 18.1.0.0) zum (ent-)Packen, also denke ich ist es keine echte Alternative …
Vielen Dank für diesen und weitere Artikel, Vielen Dank für deine tolle Arbeit.
Welches (kostenlose) Datenkompressionsprogramm kannst du dann (bedenkenlos) für den privaten und / oder kommerziellen Einsatz ("userfreundlich") empfehlen?
Über ein paar Tipps wäre ich dir sehr dankbar!
Natürlich die mit dem jeweiligen Betriebssystem bereits gelieferten!
Microsoft liefert seit 20 (!) Jahren eine "shell extension" für den Windows Explorer, die Aus- und Einpacken von ZIP-Archiven implementiert.
Die ist gut genug, insbesondere für Otto Normalverbraucher.
Microsoft selbst verwendet seit Windows 95 durchgängig das deutlich besser komprimierende CAB, u.a. in .MSI und .MSP, für (Treiber- sowie Update-) Pakete, für Windows-Updates .MSU, vor Vista die Dateien *.??_ der Installationsmedien, …
.CAB können (wie auch .MSI und .MSP) digital signiert werden.
Das mit Windows 95 eingeführte SetupAPI (die offizielle Schnittstelle zur Installation von Treibern und Diensten) kann auf die Inhalte von .CAB direkt zugreifen, ebenso der mit Office 2000 eingeführte Windows Installer und das mit Vista eingeführte "component based servicing".
Zum Auspacken genügt die im Windows Explorer vorhandene "shell extension"; Einpacken per MAKECAB.exe.
In diese Richtung gehen meine Gedanken für einen Folgeartikel – garniert mit einem Kontextmenübefehl. Muss ich mir aber etwas in Ruhe zu Gemüte führen und mit dem Tippgeber und Spiritus-Rektor diskutieren.
Gibt noch viele Themen in Richtung Sicherheit – aber das will sortiert und aufbereitet werden, damit Dritte das auch verstehen. Und Sicherheitsthemen sind nicht so wirklich meine Baustelle – bin nur der Bote der schlechten Nachricht, der dann geköpft wird ;-).
Erzeugen von .CAB funktioniert genau wie .ZIP:
– leg Dir ein Windows NT5.x zu: dort liefert Microsoft das skriptbare COM-Objekt MakeCab.MakeCab;
– schreib Dir ein [VB,J,WSH]Script, das MakeCab.MakeCab verwendet;
– erstelle eine Verküpfung
WScript.exe "[VB,J,WSH]Script" %1
im SendTo-Verzeichnis.
In neueren Versionen von Windows erstellst Du per .CMD oder .VBS eine .DDF (diamond description file) und rufst dann MAKECAB.exe /F "*.ddf" auf.
Zum Komprimieren nur einer Datei genügt
MAKECAB.exe "datei"
Das war ja einfach.
Für die Umkehrung, d.h. Aus- und Einpacken von .ZIP auf der Windows-Kommandozeile, verwendest Du doch das skriptbare Shell.Application COM-Objekt?
.CAB ist in der Anwendung für einen Normalbenutzer einfach nur zum heulen.
das in Windows integrierte ZIP hat einige Einschränkungen, die es letztlich außer für primitive Dinge unbrauchbar machen. Ist halt letztlich ein ZIP auf dem Stand der 1990er – und konnte schon damals nicht alles, was möglich war. Auch wenn seit Vista z.B. endlich ZIP64 umgesetzt wurde (4GByte-Limit!) kann es beispielsweise mit "illegalen" (auf Windows) Zeichen nicht richtig umgehen.
Wir hatten von einem Grafiker mal eine ZIP bekommen, die auf einem Mac komprimiert wurde – und auf einem Mac legale Dateinamen enthielt (IIRC mit einem * beginnend). Der in den Explorer integrierte Entpacker weigerte sich, diese Datei zu entpacken – 7Zip funktionierte dann.
Das erinnert mich doch sehr an meine Probleme, siehe unten.
Ich nehme an dass Programme die auf 7zip basieren auch betroffen sind?
Problem sollte allerdings mit Microsoft eingebauten EMET im Defender behebbar Seiten
Und welches Tool sollte man stattdessen verwenden? Wer sagt mir als unwissendem Anwender denn, dass andere Packer nicht ähnliche Probleme haben?
Wäre es nicht einfacher, auf Download aus unsicheren Quellen soweit als möglich zu verzichten? Dann kommt 7-Zip erst gar nicht in Kontakt mit problematischen Archiven.
Gut und ausführlich geschrieben, wie immer mein Respekt Mr. Born!
Ich würde auch gerne was zum Alternativen sehen, aber auch extreme Bsp wer davon betroffen sein könnte bzw. in welcher Konstellation alles OK wäre ;-)
Tja, und welchen Packer dann verwenden?
Das dumme ist, es gibt ein paar Punkte die in den Augen der meisten FÜR 7-Zip sprechen.
Kostet nix, geht funktional tadellos, gute Kompression, ziemlich schnell.
Nehm ich jetzt z.B. Peazip, woher weiss ich das dies nicht ebenso hemdsärmlig programiert wird?
Wie können wir sicher sein, dass das kommerzielle WinZIP sicherer ist?
Deren Entwickler dürften erst recht keine Auskünfte (closed source) geben.
PEAZIP.ORG: "PeaZip is free file archiver utility, based on Open Source technologies of 7-Zip, …"
mehr noch: peazip (free pascal) verwendet ausfuehrbare dateien vom 7-zip-projekt (c++), nicht bloss quellcode.
Das erscheint mir ein recht theoretisches Problem zu sein. Der Anwendungsfall hiesse ja, dass man bedenkenlos irgendwelche ZIPs von Versendern öffnet, die man nicht kennt und das File noch dazu passwortgeschützt ist. Denn zum Zeitpunkt des Öffnens war ansonsten schon der Virenscanner aktiv.
Sehe ich genauso wie Tom.
Ich benutze den 7-Zip eigentlich nur um Treiber-Daten aus immensgrossen HP-exes zu exportieren und um Windows-ISO's zu öffnen (ab Windows 10 ist das auch nicht mehr nötig!). Bei diesen beiden Datei-Arten gehe ich mal davon aus, dass sie nicht Malware-verseucht sind wenn ich sie von den offiziellen Hersteller Seiten lade.
Ich habe noch nie ein Archiv damit erstellt und auch Standard ZIP-Dateien werden in Windows "automatisch" geöffnet.
RAR und sonstige Archive brauche ich im geschäftlichen Umfeld auch nicht.
Bitte Alternativen angeben; oder lieber die portable Version nutzen. Bei Heise https://www.heise.de/download/blog/7-Zip-besser-als-WinRAR-WinZip-und-Co-3294118 kommt 7-Zip gut an (allerdings von 2016)!?
Kann ich leider so nicht stehen lassen. Werde da auch noch einen Blog-Beitrag zu machen. Das Thema portable Anwendungen hat eine eigene Schwachstelle, auf die ich in einer Diskussion mit einem Sicherheitsspezialisten gekommen bin. Die Krux: Portable Anwendungen liegen in Ordnern, auf die der Benutzer Schreibrechte hat. Malware kann also die Anwendung beliebig manipulieren – man muss also Schreibrechte auf die Programmordner der portable-Version entziehen.
Zu den Alternativen: Ihr verlangt einfach zu viel. Wie soll ich als kleiner Blogger zig Packer auf Schwachstellen testen? Und dann noch belastbare Informationen liefern, die auch noch für künftige Updates gelten?
Was ich plane: Einen Artikel, der zeigt, wie man bestimmte Sachen mit Bordmitteln oder Tools wie Orca erledigen könnte. Aber ich habe so viele Themen (brandheißer Scheiß auf meiner Agenda), dass es ein paar Tage dauern kann. Ziel des Artikels hier war, auf das bestehende Problem hinzuweisen, damit es überhaupt mal breiter bekannt wird.
weil, ohne Alternative steht da ne Aussage einfach nur so im Raum, dann eher Richtung weitgehend wertlos.
Und der Verweis auf den älteren Artikel "Universalwerkzeug 7-Zip portable" ist vlt in diesem Kontext ebenfalls nicht so wirklich zielführend?
Aber das wesentliche ist, es gibt paar Dateien/Pakete, die leider nur mit 7zip korrekt entpackt werden. Vor allem auch das Format 7z. WinRAR ist da meist hilfreich, und so bzw. dann eine Alternative. Aber eben nicht immer. Dann braucht es doch 7zip-portable.
Günter Born: "Das Thema portable Anwendungen hat eine eigene Schwachstelle… Die Krux: Portable Anwendungen liegen in Ordnern, auf die der Benutzer Schreibrechte hat. Malware kann also die Anwendung beliebig manipulieren"
in meinen augen keine allzu grosse krux: wenn malware bereits auf dem rechner ausgefuehrt wird, hat man eh bereits verloren.
Genau @ralf, wer schon malware auf dem Rechner hat braucht sich auch vor noch mehr Malware zu fürchten meine heißt Windows 10.
Ne Spaß beiseite das sind mir schon zu viele wenns und aber, nun gut ich verwende schon seit Jahren Winrar das ist für mich sehr Praktisch da ich oft viele kleine Ordner Komprimiere und dazu gleich Verschlüssele, ich weiß auch das dass Ding in der Vergangenheit diverse Macken hatte, ob das Tool sicher ist Weiß ich auch nicht.
Ich öffne damit auch nicht jedes Anhängsel einer Email von unbekannten Absendern habe ich noch nie gemacht!
Für exe und Cab und andere Dateien benutze ich noch den Universal Extractor. Die Gefahr besteht immer sich irgendeine Schadsoftware einzufangen momentan halte ich aber zip Dateien für das geringste übel.
Ich schätze mal so viele unbedarfte Anwender haben auch kein 7zip als portables Werkzeug in der Hosentasche um zip Dateien von unbekannten Absendern damit zu öffnen.
…"benutze ich noch den Universal Extractor. "…
ich auch, in der UniExtract2 v 2.0.0b4 ist noch 7-Zip 16.04 drin
wenn die UE Bioruebe schläft, wird der 7-zip anteil darin gelöscht und der andere 7z Kram komplett vom Rechner verbannt.
@Günter
Danke für diesen interessanten Hinweis auf die Schwachstelle bei portablen Anwendungen: „Portable Anwendungen liegen in Ordnern, auf die der Benutzer Schreibrechte hat. Malware kann also die Anwendung beliebig manipulieren …" Ich denke, dass das tatsächlich eine konzeptionelle Schwachstelle ist und dass man Einsatz bzw. Konfiguration von portablen Programmen wohl überdenken muss. Gilt meiner Meinung nach besonders für portable Systemtools, die sinnvoll nur mit Admin-Rechten eingesetzt werden können. Bei solchen Tools entsteht die etwas merkwürdige Situation, dass sie einerseits stets mit Admin-Rechten ausgeführt werden, andererseits aber in Ordnern gespeichert sind, die ohne Admin-Rechte verändert werden können. Das könnte sie als Angriffsziel interessant machen …, hier stehen sozusagen die Sicherheitstore zum Rechner sperrangelweit offen.
Mein aktueller Ansatz ist inzwischen folgender: Tool-Sammlung einmal komplett in eine ISO packen (z.B. mit Imgburn) und diese dann vom USB-Stick auf jedem beliebigen Win10 Rechner einbinden.
Hat zwar den Nachteil, dass keine Einstellungen in den portablen Apps gespeichert werden, dafür kann mir Malware zumindest nicht ganz so schnell in die Verzeichnisse reinfunken. Und solange die ISO intakt ist, kann ich mir recht sicher sein, dass die Verzeichnisse malwarefrei sind, und ich nicht noch zehn weitere Clients mit meinen Tools infiziere.
Das verhindert zwar keinen Befall über Malware, die sich an der Firmware des Sticks vergreift, oder den Verlust der ISO durch Verschlüsselungstrojaner, aber es ist m.E. ein kleiner Schritt, um portable Tools ein wenig sicherer zu machen.
Das eigentliche Problem sehe ich aber bei Programmen die eine interne 7Zip Routine benutzen. Als User weiß ich davon nichts und merke auch nichts bis es zu spät ist. Ob ich da selbst einen anderen Packer benutze ist dabei ziemlich egal.
Oder habe ich da:
"Es gibt Programm-Pakete die 7-Zip als zusätzliches Tool verwenden. Beispielsweise im Verlauf der Produktaktualisierung(automatisches Update).
Auch wenn das aktuellste Z-Zip installiert ist, besteht die Gefahr das veraltete Versionen dieses Tools, in den Programmverzeichnissen des Rechners, vorhanden sind."
was falsch verstanden? Denn das wäre dann das eigentliche Problem.
offenbar gibt es viele "eigentliche Probleme" die mit gepackten Dateien und deren Entpackern zusammen hängen. Nicht zuletzt stecken in praktisch jedem Virusscanner diverse Entpackungsroutinen ;) .
Herr Born hat oben aufgezeigt das man mit dem Processexplorer von sysinternals anzeigen lassen kann ob ein Programm zur Laufzeit die Flags DEP (Datenausführungsschutz) und ASLR ( Adress Randomisation) gesetzt hat.
Seit mindestens 2016 ist allerdings bekannt das ASLR über Intel "TSX" geknackt werden kann (Betriebssystem unabhängig) und dass eine effiziente Gegenmassnahme fehlt:
https://www.blackhat.com/docs/us-16/materials/us-16-Jang-Breaking-Kernel-Address-Space-Layout-Randomization-KASLR-With-Intel-TSX.pdf
Die Lösung über "Coarse-grained timer" ( grobkörniger Timer) wird bis in die Gegenwart diskutiert, aber der Verzicht auf den Präzisionstimer bereitet offenbar Kopfschmerzen.
Die Technologie "DEP" kann man übrigens auch manuell setzen, zum Beispiel beim Start von Windows über den BCDEdit Befehl.
(Kommandozeile als Administrator starten > Eingabe: bcdedit /set nx AlwaysOn )
http://www.itprotoday.com/management-mobility/q-how-do-i-use-bcdedit-set-data-execution-prevention-dep-mode
http://www.thewindowsclub.com/disable-data-execution-prevention
Es wird dort auch eine Methode beschrieben "DEP" manuell für jedes Programm einzuschalten oder auszuschalten.
Weiterhin gibt es von Microsoft ein Tool mit dem man ASLR, DEP und weitere Risiko Einstellungen bei Windows unabhängig von den Compiler Optionen der Programme konfigurieren kann, es nennt sich EMET.
Leider will Microsoft das Tool per Mitte dieses Jahres nicht mehr unterstützen:
https://technet.microsoft.com/en-us/security/jj653751
Mit den Kommentaren hier hat der Blog-Beitrag ja schon sein Ziel erreicht ;-).
Mir spukte auch EMET im Hinterkopf herum, um das Ganze eventuell zu härten. Mal schauen, ob und was ich zusammen bekomme.
Im "EMET 5.52" wird 7-zip bei geladenem "Popular Software.xml" Profile mit folgenden Einstellungen konfiguriert.
Mitigation Name="DEP" Enabled="true"
Mitigation Name="SEHOP" Enabled="true"
Mitigation Name="NullPage" Enabled="true"
Mitigation Name="HeapSpray" Enabled="true"
Mitigation Name="EAF" Enabled="false"
Mitigation Name="EAF+" Enabled="false"
Mitigation Name="MandatoryASLR" Enabled="true"
Mitigation Name="BottomUpASLR" Enabled="true"
Mitigation Name="LoadLib" Enabled="true"
Mitigation Name="MemProt" Enabled="true"
Mitigation Name="Caller" Enabled="true"
Mitigation Name="SimExecFlow" Enabled="true"
Mitigation Name="StackPivot" Enabled="true"
Mitigation Name="ASR" Enabled="false"
Als Wildcard auf den Programmpfad.
(Anwendungsspezifisch wird "EAF" zur Kompatibilität deaktiviert, abweichend zu den Standard aktivierten Optionen.)
vendor Name="7-Zip"
Suite Name="7-Zip"
App Name="Console command line" Path="*\7-Zip\7z.exe"
Mitigation Name="EAF" Enabled="false"
App Name="GUI command line" Path="*\7-Zip\7zG.exe"
Mitigation Name="EAF" Enabled="false"
App Name="File manager" Path="*\7-Zip\7zFM.exe"
Mitigation Name="EAF" Enabled="false"
Die Standalone-Console "7za.exe" (benötigt keine zusätzliche .DLL) ist in diesem Programmprofil nicht erfasst!
Kann sich, wie bereits erwähnt, überall befinden und wird in verschiedenen Programmpaketen verwendet. Der Programmpfad muss manuell konfiguriert werden!
————————————————-
Vorsicht – mit "EMET" und inkompatibel gesetzten Optionen kann man ein System schnell destabilisieren! Auch wenn EMET keine Inkompatibilität moniert.
um dieses Thema mit EMET und Co. zu vertiefen sei noch dieser Artikel im MS Blog empfohlen zu lesen (english):
Memory Protection Features bei Windows 10
Es wird gezeigt wie man mangelhafte Einstellungen mit dem Prozessexplorer anzeigen kann und ob Windows das "CFG"(Post Compiler) Feature verwenden kann. Es wird zudem gezeigt wie man per setzen einer Police einen bessern Schutz
erreichen kann.
https://blogs.technet.microsoft.com/askpfeplat/2017/04/24/windows-10-memory-protection-features/
Ich vermute jetzt mal dass uns der Daten-Speicher-Schutz auch wegen den neuen Gefahren wie Spectre, Meltdown weiter beschäftigen wird.
Für alle die sich fragen warum ASLR im Microsoft "Process Explorer", für in Microsoft "EMET" konfigurierte Prozesse, nicht angezeigt wird!
Es ist aber in Funktion, der "Process Explorer" zeigt es auf die Weise nur nicht an.
Auszug:
"EMET does not take advantage of the OS implementation of ASLR. It will not show up in Process Explorer even when it is turned on because Process Explorer only queries the OS implementation of ASLR."
https://social.technet.microsoft.com/Forums/security/en-US/c3d19865-f569-4cce-807f-9ff9a8131eea/difference-between-native-system-aslr-and-emet-imposed-system-aslr?forum=emet
Zum Erzwingen von ASLR braucht niemand EMET! Ab Windows 7 kann das System das ganz alleine:
https://support.microsoft.com/en-us/kb/2639308
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"MoveImages"=dword:ffffffff
Windows 10 hat an dieser Stelle eine Macke. Details dazu gibt's bei Matt Miller von Microsoft, früher als "skape" bekannt.
zu "Nicht zuletzt stecken in praktisch jedem Virusscanner diverse Entpackungsroutinen"
wobei dann noch zusaetzlich zu befuerchten ist, dass die dort mit admin-rechten werkeln duerfen.
Obige Adresse ist ungueltig, man landet @ https://www.microsoft.com/en-us/msrc?rtc=1
Sucht man aber @ https://docs.microsoft.com/de-de/ in dem dortigen Suchfenster nach EMET, landet man @
https://docs.microsoft.com/de-de/search/?search=EMET&category=All
Dort findet man
https://docs.microsoft.com/de-de/windows/security/threat-protection/microsoft-defender-atp/emet-exploit-protection
Darin ist enthalten:
"Der Exploit-Schutz in Microsoft Defender ATP ist unser Nachfolger von Emet und bietet einen stärkeren Schutz, mehr Anpassung, eine einfachere Benutzeroberfläche und bessere Konfigurations-und Verwaltungsoptionen.
Emet ist ein eigenständiges Produkt für frühere Versionen von Windows und bietet einige Eindämmungsmaßnahmen gegen ältere bekannte Exploit-Techniken.
Nach dem 31. Juli 2018 wird es nicht unterstützt."
Lösungsvergleich
Die in Emet verfügbaren Schadens Behebungen sind in Windows Defender unter dem Feature "Exploit Protection" enthalten.
Kann man Herrn Pavlov nicht mal gezielt darauf ansprechen?
Er müsste ja auch ein entsprechendes Interesse daran haben, wenn er möchte, dass seine Software weiterhin den Erfolg hat, den sie jetzt genießt…
Herr Pavolv ist von mindestens zwei Sicherheitsforschern gezielt darauf angesprochen worden. Einen Fall hatte ich in den betreffenden Blog-Beiträgen erwähnt – den zweiten Fall werde ich hier nicht offen legen.
Da es in jedem Packprogramm ab und an Sicherheitslücken gibt, dachte ich erst: warum das Programm generell meiden?
Inzwischen stimme ich der Empfehlung zu, da es den Anschein hat, dass der Anbieter Sicherheit generell nicht in den Fokus rückt. Auf der Webseite wird einfach nur die neue Version angeboten – bar jeden Hinweises, warum man die auch verwenden sollte. Selbst im Changelog steht nur "Some bugs fixed", aber kein Hinweis auf Sicherheitslücken. Ebensowenig auf der Downloadseite, die parallel zur neuen auch uralte Versionen anbietet (http://www.7-zip.org/download.html).
Bei Programmen, die 7ZIP für das Entpacken ihrer Updates nutzen, ist das Problem m. E. eher gering. Denn hier müßte der Angreifer auf dem Updateserver des Softwareherstellers ein kompromittiertes ZIP-Archiv anstelle des Updates einfügen. Wenn er das kann, stünde ihm jedoch auch offen, das Update selbst mit Spyware, etc. auszustatten.
Auch andere Packer wie etwa WinRAR nutzen die 7zxa.dll. Allerdings betreffen die 7Zip-Lücken generell nur das Entpacken von RAR- und ZIP-Archiven. Für beide Dateitypen verwendet WinRAR sicherlich seine eigenen Bibliotheken und die 7zxa.dll nur, um 7Zip-Archive zu entpacken. WinRAR braucht daher kein Update wegen der aktuellen Lücken.
https://www.cvedetails.com/vulnerability-list/vendor_id-9220/7-zip.html
Danke für die Information. Auf 7-ZIP verzichten muss man deshalb ja nicht gerade. Ich verzichte ja schon seit xx Jahren darauf, Setup- oder Exe-Dateien aus nicht vertrauenswürdigen Quellen (wobei die Beurteilung schon das eigentliche Problem ist) ohne Kondom auszuführen. Dann gehört das Entpacken eben jetzt auch dazu.
Hallo Herr Born,
vielen Dank für Ihren Blog, der für mich immer eine wertvolle Informationsquelle ist.
Wenn Sie Missstände benennen kann ich dem häufig vorbehaltlos zustimmen, in diesem Fall jedoch nicht, wie nachstehend erläutert:
1) Wenn Dritte alte verwundbare Versionen von 7-Zip in ihrer Software verwenden kann man das meines Erachtens nicht dem Programmierer von 7-Zip anlasten.
2) 7-Zip wird vom Autor kostenlos und werbefrei der Allgemeinheit zur Verfügung gestellt. Sicherlich kann und darf man Kritik äußern, dass nicht alle vom Compiler zur Verfügung gestellten Sicherheitsmechanismen genutzt werden, solange der Entwickler jedoch den Programmcode selbst auf Sicherheitslücken prüft und falls zutreffend beseitigt stört mich persönlich dieses nicht. Da ich selber zu einer Zeit mit Programmieren angefangen habe, in der man um jedes Byte gerungen hat sehe ich die Einstellung des Entwicklers eher von der sportlichen, wenn auch in der heutigen Zeit antiquiert anmutenden Seite.
3) Wenn man Ihren Denkansatz überspitzt weiterführt müsste man aufgrund der vielen Sicherheitslücken eigentlich konsequenterweise vor der Verwendung von sämtlichen aktuellen Betriebssystemen, Officepaketen und Internetbrowsern warnen … und die gute alte Schreibmaschine wieder vom Dachboden holen ;-)
Aus diesem Grund finde ich den Hinweis auf die Problematik richtig, die Warnung vor der Verwendung von 7-Zip (in der jeweils aktuellsten Version!) aber als über das Ziel hinausgehend.
Gruß,
Volko
Nun ja, jeder entscheidet über sein System und die Verwendung der Software. Ich habe einen Hinweis gegeben – kann man befolgen oder auch nicht. Auf jeden Fall hefte ich mir auf die Fahnen, dass jetzt zumindest drüber diskutiert wird und die potentielle Gefahrenstelle bekannt ist. Ich postuliere mal, dass vorher die wenigsten der Kommentatoren sich über die Thematik bewusst waren – mag mich da aber irren.
Hallo Herr Born,
der Hinweis auf die Problematik ist in jedem Fall sehr hilfreich und hat ja bereits zu einer lebhaften Kommentar-Diskussion hier im Blog geführt … also, Ziel erreicht!
Meiner Meinung nach ist lediglich die Warnung auf 7-Zip vollständig zu verzichten etwas überzogen, da man dann auch vor der Nutzung vieler anderer Programme mit bekannten theoretischen Sicherheitslücken warnen müsste.
Allerdings befürworte ich explizit die Diskussion über die möglichen Sicherheitsanfälligkeiten von 7-Zip (und anderen Packern), da diese zu einem bewussteren Umgang mit unbekannten Dateien gleich welchen Typs beiträgt … unabhängig davon, dass die Kommentatoren hier im Blog sich dessen ohnehin alle bewusst sein werden.
In diesem Sinne: Danke für den Denkanstoß!
Gruß,
Volko
ASLR ist auch keine sichere bank.
WIKIPEDIA:
"ASLR lässt sich durch sogenanntes Spraying umgehen. Dabei wird der Schadcode über hunderte Megabyte im Speicher dupliziert (großflächiges 'Sprayen'). Dadurch steigt die Wahrscheinlichkeit, dass trotzdem (irgendwann) ein Bibliotheksaufruf Schadcode ausführt."
Was ist mit diesem hier?
https://www.bandisoft.com/bandizip/de/
Auch kostenlos, Portable oder zum Installieren
Ob die Programmierung so schlecht ist wie das Deutsch auf der Seite? ;)
Das Programm ist doch Opensource und der Quellcode wird unter GPL oder LGPL zur Verfügung gestellt. Somit wäre also zumindest ein Code-Review problemlos möglich, um Sicherheitslücken zu finden. Macht wohl nur keiner – oder wenn, dann niemand aus der "Whitehat" Ecke.
Dass alle möglichen Programme teils uralte Versionen von Entpack-Routinen verschiedenster Packer nutzen, ist leider ein generelles Problem und nicht auf 7-Zip bezogen.
Dummerweise geht's gerade NICHT um den Quelltext, sondern um die vom (einzigen) Autor bereitgestellten ausführbaren Dateien, die Abermüllionen von Lemmingen herunterladen und frisch-fromm-fröhlich-frei ausführen … u.a. in der "Shell" ihres Spielzeux.
Dieser frickelt das Zeux mit der 20 (!) Jahren URALTEN Version 6.0 von Microsofts C-Compiler/Linker/Runtime zusammen, die seit über 15 Jahren aus der Wartung ist, und keine der seit damals in diese Werkzeuge eingebauten Abwehrmassnahmen generiert.
Der Typ signiert noch nicht einmal die zu installierenden Dateien!
Das klingt ja gerade so, als ob 7-Zip für Millionen von mit Malware verseuchten Rechnern verantwortlich sei … und das hat mit berechtigter sachlicher Kritik nichts zu tun! Man kann den Entwickler von 7-Zip nicht für die Dummheit von Anwendern verantwortlich machen, die ohne nachzudenken jeglichen Dateianhang öffnen.
zu "Dummerweise geht's gerade NICHT um den Quelltext, sondern um die vom (einzigen) Autor bereitgestellten ausführbaren Dateien…"
dann stellen sie sich doch ihre eigenen ausfuehrbaren dateien her, denn gluecklicherweise kann man gerade quelltext kompilieren.
zu "Der Typ signiert noch nicht einmal die zu installierenden Dateien":
es bezahlt ihn auch niemand dafuer.
https://www.borncity.com/blog/2018/01/30/7-zip-mit-sicherheitslcken-updaten/#comment-53523
Wie kompiliert der mit der "URALTEN Version 6.0" eine 64bit-Datei?
Microsoft C 6.0 was released in 1989. As a 16-bit version.
zu "Wie kompiliert der mit der 'URALTEN Version 6.0' eine 64bit-Datei?"
gar nicht.
gemeint war sicherlich auch nicht der methusalem "C 6.0" sondern "Visual C++ 6.0" (WIKIPEDIA: "Visual C++ 6.0 is still quite popular and often used to maintain legacy projects") von 1998: vc6 kann als reiner 32-bit compiler aber auch keinen 64-bit code erzeugt haben.
im "Developer FAQ" von 7-zip steht auch nicht, dass vc6 verwendet wurde:
"To compile sources you will need Visual C++ 6.0 or a later version. Some files also require a new Platform SDK".
Alfred E. Neumann hat aber nicht Visual C++ 6.0 geschrieben.
Da sollte mit dem Begriff "URALT" eine negative Assoziation erweckt werden.
Weil Win10 etc. ist ja so schön modern…
Ich finde den Denkansatz des Artikel noch nicht konsequent genug (soll kein Angriff sein, Günter). Wer seinen PC nur zum Spielen oder Internet-Surfen nutzt und ihn ohne großen Datenverlust in einer Stunde wieder aufsetzen kann, kann sich eher zurücklehnen. Aber wer im Studium seine Arbeiten darauf schreibt oder später im Leben seine finanziellen Angelegenheiten und die Steuererklärungen darüber abwickelt, wichtige Daten darauf speichert und diese vielleicht für den ersten Kredit zum Hauskauf benötigt, oder das unwiderbringliche Video von seiner/ihrer Hochzeit darauf speichert oder die Bilder der heranwachsenden Kinder (die man nicht unbedingt auf Facebook o.ä. veröffentlichen will), muss viel weiter denken.
Jedes Programm stellt heute ein potentielles wandelndes Sicherheitsrisiko dar. Und dann sollte man Sätze wie :Wer 7-Zip zum Entpacken von Archiven aus unbekannten Quellen verwendet, lebt riskant: abändern in :Wer Archive aus unbekannten Quellen verwendet, lebt riskant.
Oder Sätze wie :Du entpackst nichtsahnend eine Datei, um deren Inhalt zu analysieren (und ggf. auf Malware zu untersuchen).: ganz streichen und stattdessen die Maxime verwenden, dass überlassen wir Profis mit isolierten Systemen und löschen stattdessen lieber jede Datei, die uns nicht ganz geheuer vorkommt. Wirklich wichtige Schreiben, die man auf keinen Fall ignorieren darf, bringt eh heute noch die Post per Einschreiben mit persönlicher Zustellung oder gleich der Gerichtsvollzieher vorbei.
Wer seinen PC und die Dokumente darauf wirklich braucht, der braucht eine gute Datensicherung, einen zweiten PC für das Internetsurfen und die eigene unüberwindliche Neugier. Und schmeisst alles von Haupt-PC, was dort nicht wirklich benötigt wird. Und das betrifft auch alle Programme, die von Programmierern und Firmen veröffentlicht werden, die sich ihrer Verantwortung für die Nutzung ihrer Programme und ihrer (ganz natürlich begrenzten) Kenntnisse in Sicherheitsfragen nicht bewusst sind.
Oder lernt halt irgendwann schmerzlich. Manch einer steht ja auf Horrorfilme.
Danke für den Bericht.
Gesehen, gelesen, gelöscht!
Danke und Gruß J.M
Hi, als nicht besonders gewiefter Amateur verstehe ich nur teilweise, was hier alles dazu geschrieben wurde – leider.
Eins ist mir aber aufgefallen: der Hinweis auf EMET……
Das hatte ich mal installiert und genutzt – musste es aber nach Problemen ( ich glaub ua der IE wollte gar nicht mehr laufen) dann entfernen.
Und ich hab einfach keine Lust mehr auf immer mal wieder probieren, ob das nun behoben ist.
Na ja- den IE nutzich sowieso fast nie. Dafür Firefox – und ich glaube, der entpackt auch selbst bei Installation mit 7zip – bin mir aber da nicht sicher.
Entschuldigung!!!!!!!, wenn ich hier als kleines Laienwürstchen meinen Senf noch dazugebe – man möge mir bitte verzeihen – bitte!!!!!!!!
Hallo,
also nur weil zwei Compiler Flags nicht gesetzt sind hier so nen Drama machen?
Da gibt es noch genug andere Anwendungen die genauso zusammen geflickt sind. Mal TrueCrypt angeschaut?
Wenn es einem wirklich so wichtig ist, selber compilieren. Anleitungen gibt es dazu im Netz.
http://www.ski-epic.com/2012_compiling_7zip_on_windows_with_visual_studio_10/index.html
Was heißt hier Lemminge, da gibt es weit aus schlimmere Software was sich die Leute auf den Rechner laden. Ich sage nur Youtube MP3 Download etc. Ist es da wichtig das die Software auch mit den richtigen Flags compiliert sind bevor die Malware aufs System gepumpt wird.
Wenn ich schon so etwas lese wie "Malware zu untersuchen" auf nem Produktiven Windows System und dann noch im Windows Netzwerk. Also davon würde ich abraten und da ist es auch egal ob das Packprogramm nen Compiler Flak jetzt hat oder nicht.
Zum Thema Code Signing das bietet auch keine 100% Zuverläsigkeit und es gibt noch viel Software da draußen die es nicht dabei hat. VLC war auch so ein Kanditat der es lange nicht hatte.
ALRS ist auch nicht der heilsbringer, es wurde schon zu oft umgangen.
Da sind die Lücken die in den Intel und anderen CPU´s aktuell stecken viel gravierender. Hier sollten Sie mal wind machen
Da das Sie im letzten Satz groß geschrieben ist, muss ich diesen auf mich beziehen. Habe gerade zwei Stricknadeln in eine Voodoo-Puppe gesteckt und gemurmelt 'verflucht sollst Du sein und krepieren, wenn Du es wagst, per Spectre und Meltdown auf meine CPU – und die CPU meines nächsten und meiner Facebook-Freunde und deren Freunde – zuzugreifen`. Ob das wohl reicht, mit dem Wind machen ;-).
Zu Spectre und Meldown gab es so einige Artikel im Blog. Wurde mir als Panikmache vorgehalten – aber ich kann mir leben. Glücklicherweise muss ich mir nicht meinen Kopf zu euren Problemen zerbrechen :-).
7-Zip ist Open Source – sogar auf Github gibt es ein Repository dazu (https://github.com/kornelski/7z). Daher verstehe ich nicht ganz, wieso nicht einfach eine entsprechend sicherere Version davon erstellt wird. Statt dessen zeigen nur die "Experten" auf den vermeintlich inkompeteten Entwickler und tun ansonsten nichts.
Dann stelle dir mal die Frage, wie viele Endnutzer genau dies tun.
Ich rede auch nicht von "Endnutzer" sondern Leuten, die wissen, was Linker-Flags sind und einen Compiler bedienen können. Diese Leute äußern nämlich auch die Kritik an der Ignoranz von Igor Pavlov und dessen veralteter Buildchain, nutzen aber auch nicht die Chance, aus den Quellen eine Version zu erstellen, die die gewünschten Linker-Optionen benutzt. Dabei wäre das doch eine gute Gelegenheit, Igor Pavlov zu zeigen, dass die vermuteten Performance-Einbrüche mit ASLR (das übrigens keinesfalls so sicher ist, wie behauptet) nicht so groß sind und die Dateigröße auch nicht so extrem steigt, wie befürchtet.
Der Ansatz ist interessant.
Vielleicht könnte das ja mal eine vertrauenswürdige Institution (hallo liebe Heise-Redaktion ;-) ) umsetzen?
Sind informiert.
Ich verstehe das Ganze nicht so richtig und wo die Angriffbarkeit liegen sollte. Es ist generell ein Problem mit zip-Dateien oder anderen gepackten. Die Problemeroierung kann nicht darin bestehen, dass andere Softwareanbieter in ihren Installer-Programmen alte 7-zip-Versionen verwenden ode generell 7-zip verwenden.
Liegt das Problem nun
# am Programm selbst?
# an den Installer von Softwareanbietern?
# oder sonst was?
# telefoniert es irgendwo hin?
# und was überhaupt macht das Programm wenn ich eine ZIP-Dateien damit entpacke oder ZIP-Dateien erstelle?
Ist Intel sicher? Ist Microsoft sicher? Wo liegt das Risiko? Krieg ich damit Trojaner oder sonst was? Welches AV-Programm bekämpft das? Was macht die Intel-Geschichte?
Geht ziemlich kreuz und quer mit den Fragen. Ich versuche mal einen roten Faden zu ziehen, worum es mir im Blog-Beitrag ging.
– generell wird bei Archivprogrammen mit trickreichen Kompromierungsalgorithmen beim Packen/Entpacken gearbeitet
– bei der Verarbeitung solcher Datensätze besteht die Möglichkeit, dass es zu Pufferüberläufen im Speicher oder auf dem Stack kommt
– Diese lassen sich durch Malware ggf. gezielt ausnutzen, um Schadcode auszuführen (das erwartet man von einem Packer nicht)
– Die Ausnutzbarkeit solcher Schwachstellen lässt sich durch Compiler- und Linker-Optionen erschweren.
– Genau diese Härtungsmaßnahmen verwendet der Entwickler von 7-Zip, der auch die Bibliotheksroutinen wohl teilweise geschrieben hat, leider nicht.
Daraus habe ich den Schluss gezogen, dass man, solange sich dies nicht ändert, die Finger von dem Tool lassen oder zumindest sehr vorsichtig sein sollte.
Danke Günter für Deine schnelle Antwort auch das Du das Problem erstmals genannt hat.
Ich hatte mir mal Winzip gekauft (!) und da schlug MSE an und sgate, dass es nicht koscher ist.
Ich hatte mal ein Problem, wie man schnell was mit Winzip packen kann. Die Servicehotline hat mir das nicht erklären können. Das dauerte nicht Stunden, sonder dauert immer noch an – Jahre, somit.
Ich in dann auf 7-zip gekommen. Auch wohl deshalb, weil Du es hier mal als gut erwähnt hattest (kein Nachteil für Dich und auch kein Vorwurf). Generell kann ich mit 7-zip einfacher was entpacken. Ich gebe auch zu, dass ich mich nie mit den gesamten Möglichkeiten von 7-zip beschäftigt habe. Ich habe mal eine Pack-Datei erstellt und das funktionierte besser als mit Winzip.
Ich nutze es nach wie vor und muss mal schauen wo der Dieb dann kommt. Generell bin ich gegen diese Autoinstaller, also automatischen Updates. Ich habe diese nur beim Adobe-Flash-Player.
Man sollte es (7-zip) aber nicht löschen, wenn man keine sinnvolle Alternative hat und sich über die Gangster etwas bewußt ist. Das Problem liegt doch eigentlich bei MS, da es kein sinnvolles Entpack-und (!) Packprogramm bereit stellt. Das ist aber die Mindestanfoderung an ein gutes Betriebssystem.
ZIP selbst wird in Windows schon seit Windows XP direkt im Explorer unterstützt – auch das Erstellen neuer ZIP-Archive. Dafür braucht man also gar kein separates Programm.
Nur für Dateiformate wie RAR, GZ etc. sind Zusatzprogramme nötig.
danke, ja das stimmt. Ich hatte aber bei allen Rechnern mit Windows XP und dann vor allem bei Windows 7, dass es nicht mehr richtig funktionierte. Das war dann merkwürdig und bevor ich wieder viel Zeit vergeude, habe ich dann 7-zip zum packen genommen. Es war damals Termindruck.
Sehe keinen Grund jetzt 7-Zip den Rücken zu kehren.
Zumal man im Windows Defender Exploitschutz die Schutzmaßnahmen erzwingen kann
Aha. Und wie?
df
bei mir ist etwas von 7-Zip automatisch im slimjet-Verzeichnis!?
im Unterverzeichnis tools (7-Zip Standalone Console).
(screenshot ging leider nicht hier mitzusenden)
Man kann auch wirklich alles verteufeln. Diesmal ist es eben 7-zip.
Ich frage mich nur mit welchem Recht Sie Herrn Pavlov explizit angreifen. Wer bitte sind Sie? Der neue Messias des Internet? Haben Sie schon so eine gewaltige Software auf die Beine gestellt ? Sich hier hinstellen und ein Produkt welches dazu völlig kostenlos ist, schlecht zu reden kann meine Enkelkind, welches 6 jahre alt ist.
Wenn ich mir generell den Umgang mit Internet und Co anschaue, kann ich natürlich etwas nachvollziehen auf was Sie abzielen. Die Menschheit verbl…. im Sekunden Takt.
Ich sehe hier nur ein einziges Risiko und das stellen Sie dar!
Durch Leute wie Sie werden Millionen verunsichert und Menschen die Großartiges leisten schlecht geredet. Hören sie bitte auf zu bloggen und suchen sich eine etwas weniger intensive 'Arbeit', wie wäre es mit Garten Arbeit?
Also. Hier steht ja eine menge. Ich fange dann mal an.
Schade. 7zip war und ist für mich der packer überhaupt, weil er klein, schnell und einfach gehalten ist. Zudem open source, so kann jeder daran basteln und es gibt keine versteckte malware drin. Jetzt gibt es malware, die sich in den paketen verstecken und aktiv werden, wenn sie mit gerade dem packer entpackt werden, der mir das gefühl von sicherheit gegeben hat. Dazu sage ich vollgendes.
Herr pavlov, dass sie die compilierung ohne nötige flags ausführen, finde ich fahrlässig. Gerade weil 7zip neben winzip und winrar unter windows bekannt ist. Ich finde dann sollten sich profis dran mache und eine neue sichere, wenn auch langsamere version von 7zip entwickeln. Ein paar flags zu ergänzen ist nicht schwer. Hinzu kommt, dass es mir nicht mehr um geschwindigkeit und größe geht.
Kompression? Im terabyte gigabits zeitalter mit extra glasfaser per ftth? Etwas anderes außer dem standard zipformat? Ich verlange NUR mehrere dateien, können auch mal 1000 sein, in eine datei zu packen und zu verschicken. Gerade kompression kostet zeit und das resultat ist ein witz. Rar? Gz? 7z? Was sollen diese extraformate? Zip reicht doch, ich will keine kompression die eh nur winace kann. Wie um himmels willen soll ich kostenlos und opensource gz öffnen? Ich muss auch mal diese archive unter windows öffnen, warum soll ich dadurch von malware befallen sein.
Genauso wie ein betriebssystem wie linux mit gnome oder firefox brauche ich eine softwae, die das kann, was sie können muss, stabil und sicher, in dem fall wäre es viele dateien in eine ohne kompression, schnell öffnen schnell entpacken, dateien austauschen etc.
Der Beitrag von Andres Müller hat neben dem eigentlichen Artikel meine besondere Aufmerksamkeit.
Ich habe jetzt die DataExecutionPrevention geprüft
– wmic OS Get DataExecutionPrevention_SupportPolicy
und aus Windows heraus für alle Programme DEP aktiviert (hoffentlich machen alle apps mit).
7-Zip zeigt im Prozess-Explorer
– ASLR (ON)
– DEP (Enabled(permanent))
Zu EMET und den Windows-Versionen:
https://www.borncity.com/blog/2017/06/22/kommt-windows10-version-1709-mit-integriertem-emet/
Ich werde trotz allem weiterhin 7-Zip einsetzen und hoffen, dass wenigstens die Implementierung der AES-Verschlüsselung sorgfältig erfolgt.
Noch ein Nachtrag:
Zu EMET und W10:
"The old Enhanced Mitigation Experience Toolkit (EMET) add-on is not supported on Windows 10 v1709. Instead, we offer Windows Defender Exploit Guard's Exploit Protection, which is now a built-in, fully-configurable feature of Windows 10."
https://blogs.technet.microsoft.com/secguide/2017/09/27/security-baseline-for-windows-10-fall-creators-update-v1709-draft/
und
https://docs.microsoft.com/de-de/windows/security/threat-protection/windows-defender-exploit-guard/windows-defender-exploit-guard
– (EMET-"Ersatz") Exploit-Schutz. Ich habe unter "Einstellungen->Update und Sicherheit->Windows-Sicherheit->App- & Browserschutz->ganz unten->Einstellungen für Exploit -Schutz" geschaut, da war ASLR nicht aktiviert.
– Kontrollierter Ordnerzugriff ist eigentlich noch nicht allgemein zu gebrauchen, fehleranfällig, da viele apps erlaubt werden müssen, z.B. für iCloud, funktionierte einfach nicht mehr, OneNote kostete mich zunächst viel Zeit, um überhaupt zu erkennen, warum es nicht mehr ordentlich funktionierte … Dann habe ich diese Option wieder dektiviert.
– Attack Surface Reduction-Regeln
…
– Netzwerkschutz
…
Die letzten beiden muss ich mir erst noch genauer anschauen, GPO Optionen?
Das alles bedeutet, vieles ist nicht einfach aktiviert für ganz normale Anwender, da muss noch viel folgen von MS, viel zu unübersichtlich.
Und das EMET nicht mehr unterstützt wird, ist eigentlich eine logische Folge, ebenfalls für normale Anwender zu "kompliziert", was aber keinen von der Pflicht entbindet, sich mit der Computersicherheit zu beschäftigen.
Ich hoffe, das gilt jetzt nicht als Leichenschändung, auch wenn der letzte Beitrag schon etliche Monate her ist.
Aber einen Aspekt in der Betrachtung habe ich vermisst: Datenschutz.
Wenn ich Mails verschicke, packe ich Anhänge und versehe das Archiv mit Passwortschutz. Schließlich ist eine Mail offen wie eine Postkarte und ich möchte gewährleisten, dass nur der Empfänger den Inhalt lesen kann. Und genau an der Stelle steigt der in Windows integrierte Packer aus (der in der Diskussion als Alternative benannt wurde), da eine Passwortverschlüsselung dort nicht möglich ist. Somit muss man auf Fremd-Tools zurückgreifen.
Ich bin der Meinung, mit erhaltenen Archiven verhält es sich ebenso, wie mit Mailanhängen generell: Kenne ich den Absender nicht landet die Mail inkl. Anhang sofort im Müll.
Wenn ich also nicht völlig hirnlos jedes Archiv öffne, kann ich ohne Bedenken 7zip einsetzen. Die Gefährdung ist dann keine Deut größer, als die, die von Windows generell ausgeht.
Der Entwickler lässt sich durch Euch hier nicht wirklich entmutigen ;)
HISTORY of the 7-Zip
——————–
18.06 2018-12-30
————————-
– The speed for LZMA/LZMA2 compressing was increased by 3-10%,
and there are minor changes in compression ratio.
– Some bugs were fixed.
– The bug in 7-Zip 18.02-18.05 was fixed: there was memory leak in xz decoder.
– 7-Zip 18.02-18.05 used only one CPU thread for bz2 archive creation.
Hi,
ich schlage ein Update des Artikels vor. Die Informationen sind veraltet. In der derzeit aktuellen Version 18.06 sind ASLR und DEP aktiviert.
Gibt es für die erwänte Diskussion mit Igor Pavlov eine Quellenangabe?
Weiterhin würde es mich interessieren, ob es im Zusammenhang mit älteren 7-Zip-Versionen (immer bezogen auf die von Igor Pavlov auf http://www.7-zip.org bereitgestellten Binärdateien) irgendeinen dokumentierten Angriff gibt? Gibt es bezogen darauf eine Gegenüberstellung zu Alternativen, wie bspw. PeaZip, WinZip oder WinRAR?
Danke für den Hinweis, aber den Text möchte ich aus internen Gründen nicht ändern. Der Artikel hat einen Nachtrag, der auf die Thematik der Compiler-Flags und deren Verwendung in aktuellen 7-Zip-Versionen hinweist.
Die Quelle der Diskussion ließ über den oben verlinkten Blog-Beitrag 7-Zip mit Sicherheitslücken – updaten! abrufen. Es ist dieser Blog-Beitrag von landave.
Zur Frage 'dokumentierter Angriff': Das ist für den Artikel nicht relevant – in älteren 7-Zip-Versionen gab es immer wieder Schwachstellen, die möglicherweise mit ASLR und DEP nicht ausnutzbar wären.
Verzichtet auf Borns Blog;) 7-zip ist ein tolles Tool, und zudem eine kostenlose Alternative zu Winrar (das ist Shareware und kostet nach 30 Tagen Geld, wenn mans lizenzkonform machen will)
Ist süß wenn Leute die nichts mit Systemprogrammierung und Optimierung zu tun haben andere Entwickler wegen nicht-Verwendung vergleichsweise sinnfreier Linkerflags kritisieren.
Dynamicbase bringt keinerlei verbesserte Sicherheit und führt nur dazu, das Malware nun ein paar Byte größer wird. Die tolle Stackprüfung kann man ebenso aushebeln wenn man möchte. Bevor ihr euch weiter mit Schlangenöl einreibt, würde ich euch wirklich nahelegen die Funktionsweise solcher Features einmal im Detail anzuschauen und zu überlegen wie man sie umgehen kann.
NXCOMPAT hat eigentlich das selbe Problem, hier stört es aber häufig niemanden wenn man sagt, dass Datensegmente nicht als Code behandelt werden dürfen. Und sollte ein Entwickler das tatsächlich zur Performanceoptimierung nutzten, kann das gleiche Ergebnis auch anderweitig erzielt werden.
Ich bin es Leid zu sehen wie Leute im IT Umfeld immer mehr zu Lemmingen verkommen die einfach nur irgendwo gelesenes wie eine Gospel widerkäuen. Früher war zwar sicher nicht alles besser, aber immerhin wussten wir was wir taten.
Im Klartext heißt das, so lange ihr eure eigenen Archive packt + entpackt, kein Grund zur Panik (z.B. SQL Datenbanken etc.). Des Weiteren spielt es nur eine Rolle, wenn man ein Archiv aus fragwürdigen Quellen entpackt. Also bitte auf 7zip verzichten, wenn ihr das Archiv entpackt, in dem sich die .exe befindet, die ihr starten wollt…
Ich bin ja jetzt nur ein dummer User, kenne mich mit den Feinheiten von SourceForge und Co nicht aus, aber wird das jemals überprüft, ob eine bereitgestellte Binary auch mit dem Sourcecode compiliert wurde?
Ob die auf der HP des Anbieters zum D/L angebotenen Binaries jenen auf SourceForge entsprechen, ließe sich ja leicht überprüfen.
Aber der Rest ist eher eine Frage des Vertrauens, oder ?
Wer oder was hält den Programmierer davon ab, zusätzlichen Code mit zu compilieren, der nicht im öffentlichen Sourcecode auftaucht?