Guten Morgen, das unzip 6.0 von Debian entpackt einen kompletten Verzeichnisbaum in das Zielverzeichnis -- auch, wenn absolute Pfade eingepackt wurden. Sehr gut, so muss das sein, so brauche ich das. Aber das war nur ein einziger Test mit einer dcf77.zip aus dem Forum. Welche Überraschungen könnten noch in einem zip versteckt sein? - wirklich absolute Pfade - symlinks, sockets, devices,... - UNICODE Tricks im Filenamen - direkte Angriffe auf unzip selbst - ...? Verschlüsselung sollte mir egal sein, dann packe ich es eben nicht aus. Der Scherz mit den 4'503'599'626'321'920 Nullen ist kein Problem, ich packe erstmal in einem 1GB kleinen tmpfs aus. Dann lösche ich alles, was kein regular file ist und alles, was laut file(1) kein pdf, png,... ist. Seltsame Zeichen im Filenamen werden auch bereinigt. Was könnte man noch machen? Kann man mit "unzip -v foo.zip" etwas anfangen?
Moin, unzip hat ggf. Palaver mit komischen Zeichen in Filenamen. Hier steht bisschen was: https://www.linuxfromscratch.org/blfs/view/git/general/unzip.html Gruss WK
Ist unabhängig von zip, betrifft alle archivformate unter Linux: Executables getarnt als pdf, bilder.... Je nach Dateinamanger wird die Datei in/aus einem Archiv bei einem Doppelklick ausgeführt oder die damit verknüpfte Anwendung gestartet. mc startet solche files, thunar startet die damit verknüpfte Anwendung. Archive die von Windowsanwendern erstellt wurden, haben meist alle Files das Executablebit gesetzt oder eben Files wo das keinen Sinn für die Erweiterung macht. Aus versehen mal in ein Archiv reingeschaut und die Readme, die executable gesetzt ist, angeklickt, schon läuft ein Script ab....
:
Bearbeitet durch User
UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.
1 | man unzip: |
2 | For security reasons, unzip normally removes 'parent dir' path components (''../'') from the names of extracted file.
|
Schließt auch absolute Pfade ein. Franko S. schrieb: > Archive die von Windowsanwendern erstellt wurden, haben meist alle Files > das Executablebit gesetzt Guter Hinweis, zum Schluss noch ein
1 | chmod -R a-x,a+X <Datei> oder <Verzeichnis> |
:
Bearbeitet durch User
Franko S. schrieb: > Ist unabhängig von zip, betrifft alle archivformate unter Linux: > Executables getarnt als pdf, bilder.... > Je nach Dateinamanger wird die Datei in/aus einem Archiv bei einem > Doppelklick ausgeführt oder die damit verknüpfte Anwendung gestartet. mc > startet solche files, thunar startet die damit verknüpfte Anwendung. Die meisten modernen Dateibrowser starten ausführbare Dateien nur nach Rückfrage. Norbert schrieb: > Guter Hinweis, zum Schluss noch ein Narrensicherer wäre es das noexec bit auf das /home Dateisystem zu setzen. Mit SELinux könnte man das auch sehr fein granular kontrollieren, oder sogar dafür sorgen dass alle von "unzip" erzeugten Dateien grundsätzlich nie ausgeführt werden können, ist aber kompliziert. Dann wird es aber umständlich wenn man manuell Anwendungen (ohne Paketmanager) für nur einen Nutzer installieren möchte.
:
Bearbeitet durch User
Angehängte Dateien:
-
thunar.jpg
16 KB
Franko S. schrieb: > Ist unabhängig von zip, betrifft alle archivformate unter Linux: > Executables getarnt als pdf, bilder.... Wenn ich ein Executable getarnt als PDF anklicke, dann startet mein Thunar Atril und dann kommt schon immer eine Fehlermeldung, das sei kein PDF.
Dergute W. schrieb: > unzip hat ggf. Palaver mit komischen Zeichen in Filenamen. > https://www.linuxfromscratch.org/blfs/view/git/general/unzip.html Das ist das alte Leiden schön erklärt, danke! Norbert schrieb: > For security reasons, unzip normally removes 'parent dir' > path components Eigentlich wollte ich nur in der Richtung forschen, so: kann jemand ein Archiv bauen, bei dem "normally" nicht gilt? Und jetzt habt ihr die Wurmdose aufgemacht :( Niklas G. schrieb: > Die meisten modernen Dateibrowser starten ausführbare Dateien nur nach > Rückfrage. und die meisten Benutzer klicken auf OK :( > Norbert schrieb: >> Guter Hinweis, zum Schluss noch ein chmod > > Narrensicherer wäre es das noexec bit auf das /home Dateisystem zu > setzen. Das chmod() hätte ich vergessen, danke für den Tipp. Aber das noexec nützt nicht viel, was ist mit /usr/bin/? Der Dateibrowser braucht eine Whitelist für ein paar GUI-Anwendungen, praktisch /usr/share/applications/*.desktop, und was da nicht drin ist, wird niemals gestartet. Der pcmanfm kann in der Hinsicht scheinbar garnichts. Gibt es vielleicht einen ähnlich kleinen Dateibrowser, der da flexibler ist?
Bauform B. schrieb: > Eigentlich wollte ich nur in der Richtung forschen, so: kann jemand ein > Archiv bauen, bei dem "normally" nicht gilt? Und jetzt habt ihr die > Wurmdose aufgemacht :( Das wäre eine Sicherheitslücke die sicher rasch geschlossen wird. Ein aktuelles Beispiel wäre wahrscheinlich übermorgen schon nicht mehr reproduzierbar.
Bauform B. schrieb: > Aber das noexec nützt nicht viel, was ist mit /usr/bin/? Da kann der Normal-User normalerweise keine ZIP-Archive hin entpacken. Nur nach /home/username. Und dort kann er die Dateien dann nicht ausführen (mit noexec). Bauform B. schrieb: > Der Dateibrowser braucht eine Whitelist für ein paar GUI-Anwendungen Das beträfe ja dann nur den Browser. Auf der Kommandozeile könnte man es immer noch starten. Sicherer wäre es das Ausführen ganz zu blockieren (noexec, SELinux).
Niklas G. schrieb: > Bauform B. schrieb: >> Der Dateibrowser braucht eine Whitelist für ein paar GUI-Anwendungen > > Das beträfe ja dann nur den Browser. Auf der Kommandozeile könnte man es > immer noch starten. Sowas macht man nicht versehentlich. Das ist ja nicht wie bei Windows CMD, wo man eine Datei angibt, und dann öffnet es die oder führt sie aus. Da muss man schon ein Programm dafür mit angeben, wobei man das xdg-open / exo-open usw. überlassen kann. Und '.' ist ja normalerweise nicht im search path. Man muss da also explizit sagen './datei', um die auszuführen, und "program datei", um sie zu öffnen. Niklas G. schrieb: > Sicherer wäre es das Ausführen ganz zu blockieren > (noexec, SELinux). Kann man oft auch umgehen, wenn man wirklich will. Bei Scripten mit dem Interpreter starten z.B. "bash script". Und bei dynamisch gelinkten Anwendungen kann man das selbe mit dem dynamischen Linker machen.
:
Bearbeitet durch User
Daniel A. schrieb: > Sowas macht man nicht versehentlich. Vor versehentlichem Ausführen schützt z.B. Nautilus schon ganz gut. Da gibt's auch ne Einstellung... Daniel A. schrieb: > Und bei dynamisch gelinkten > Anwendungen kann man das selbe mit dem dynamischen Linker machen. WIMRE wird das durch noexec verhindert (die Fehlermeldung lautet anscheinend "failed to map segment from shared object error on start"), durch SELinux sowieso. Daniel A. schrieb: > Bei Scripten mit dem > Interpreter starten z.B. "bash script". Mit SELinux könnte man der /bin/bash dem Zugriff auf sämtliche Dateien in /home verbieten (außer ~/.bash_history ?). Das kann man immer weiter treiben - alle Dateien die der Browser (und unzip?) erzeugt hat kann sonst keine andere Anwendung öffnen (außer vielleicht hexdump) und schon gar nicht ausführen, und umgekehrt. Android macht das zu einem gewissen Grad. Der Aufwand und der Nervfaktor steigen natürlich mit zunehmender Beschränkung...
:
Bearbeitet durch User
Bauform B. schrieb: > Welche Überraschungen könnten noch in einem zip versteckt sein? Alles mögliche. Problematisch ist da wohl eher, dass einige Linux-Programme nicht richtig auspacken, oder auch (markierte) Daten beim Kopieren vergessen bzw. auch nicht maulen, wenn das nicht geht.
Bauform B. schrieb: > Guten Morgen, > > Welche Überraschungen könnten noch in einem zip versteckt sein? Eine ZIP-Bombe. Unbekannt? https://de.wikipedia.org/wiki/Archivbombe
Ich habe das Problem mal eingekastelt:
1 | +-----------------+ |
2 | | Doppelklick | |
3 | | angeklickt | |
4 | | anklicke | |
5 | | klicken auf OK | |
6 | +-----------------+ |
Das Muster ist klar erkennbar.
Niklas G. schrieb: > SELinux ... Der Aufwand und der Nervfaktor ... Es gibt auch noch ACLs, praktisch SELinux für arme Leute. Nach einem simplen
1 | setfacl -m user:1000:--- /usr/bin |
sagt der Dateibrowser ganz brav: "Fehler beim Öffnen des Ordners »/usr/bin«: Keine Berechtigung" Ja, die paar erlaubten Programme muss ich dann woanders hin kopieren. Aber für den ersten Versuch finde ich das Preis / Leistungsverhältnis nicht schlecht. Jörg schrieb: > Eine ZIP-Bombe. Unbekannt? Jein; auch deshalb ist es entscheidend, dass immer nur ins Zielverzeichnis ausgepackt wird. Dafür benutze ich /var/tmp, das ist ein kleines tmpfs. Weil das außer mir niemand benutzt, ist es egal, wenn es voll ist. Und Debians unzip ist für 42.zip leider zu alt: "need PK compat. v5.1 (can do v4.6)".
:
Bearbeitet durch User
Bauform B. schrieb: > Es gibt auch noch ACLs, praktisch SELinux für arme Leute. Nach einem > simplensetfacl -m user:1000:--- /usr/bin > sagt der Dateibrowser ganz brav: > "Fehler beim Öffnen des Ordners »/usr/bin«: Keine Berechtigung" Wieso willst du ›/usr/bin‹ speziell schützen? Da hat doch sowieso nur root Schreibzugriff.
Bauform B. schrieb: > Es gibt auch noch ACLs, praktisch SELinux für arme Leute. Naja nicht so ganz, SELinux ist ein MAC, ACLs sind ein DAC. Wenn unzip (oder sonst irgendein "unsicheres" Programm wie Browser, Mailclient, ...) eine Datei versehentlich als zugänglich (z.B. in $HOME oder $TMPDIR ) ablegt / Berechtigungen falsch setzt, kann man sie ausführen. Bei einem entsprechend konfigurierten MAC-System wie SELinux kann unzip & co die Datei nicht so ablegen dass man sie dann ausführen kann, egal wo es sie hin speichert, unabhängig von Unix-Permissions oder noexec. Das ist aber eher akademisch und nicht sehr praxisrelevant. Wenn man nur auf $HOME Schreibrechte hat aber Dateien auf /home nicht ausführbar sind (via noexec) dann hat man hier einen ähnlichen Effekt, ist aber natürlich sehr grob. Ob man die Schreibrechte jetzt per UNIX-Permissions oder per ACL vergibt macht keinen großen Unterschied.
Norbert schrieb: > Wieso willst du ›/usr/bin‹ speziell schützen? > Da hat doch sowieso nur root Schreibzugriff. Weil im Dateibrowser alles interessant aussieht und man alles anklickt. Die meisten Programme geben dann nur "usage" aus, aber irgendeins macht evt. doch Unsinn. Es ist ja auch völlig nutzlos, da gibt es nicht zu sehen.
Bauform B. schrieb: > Norbert schrieb: >> Wieso willst du ›/usr/bin‹ speziell schützen? >> Da hat doch sowieso nur root Schreibzugriff. > > Weil im Dateibrowser alles interessant aussieht und man alles anklickt. > Die meisten Programme geben dann nur "usage" aus, aber irgendeins macht > evt. doch Unsinn. Es ist ja auch völlig nutzlos, da gibt es nicht zu > sehen. Da wünsche ich viel Spass! In /usr/bin stehen zB. bei Debian/MATE auch: atril (pdf), eom (imageviewer), caja(Dateimanager), …, …, … und eine viertel Tonne anderer wichtiger Programme.
Motopick schrieb: > Ich habe das Problem mal eingekastelt: > +-----------------+ > | Doppelklick | > | angeklickt | > | anklicke | > | klicken auf OK | > +-----------------+ > > Das Muster ist klar erkennbar. hmmm - schwierig die Tastatur? oder der Stuhl (das Möbelstück, nicht das Stoffwechselendprodukt)? Das Ding dazwischen? ;-)
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.