Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Verbogenes "Öffnen mit"...

Verbogenes "Öffnen mit"...

Gilderoy Lockhart20.02.0619:50
Bei heise im Rahmen mit Safari beschrieben:



Auch wenn man das automatische öffnen deaktiviert hat, fühlt es sich ungut an. Nach dem heise-Test war ich schon ein wenig schockiert. Ne einfache "JPG"-Datei, die plötzlich ganz was anderes macht -- und mir das auch im Icon nicht anzeigt. Hier muss Apple m.E. dringend nacharbeiten!
0

Kommentare

Peter_20.02.0619:59
bei mir ist diese Option standardmäßig ausgeschaltet gewesen. (und ist es noch)
0
Gilderoy Lockhart20.02.0620:10
@Peter_: Ja, bei mir auch. Ich habe trotzdem mal das Zip entpackt. Per Hand. Als Admin arbeite ich sowieso nicht. Dann bekam ich eine JPG-Datei. Dachte ich. Und das ist der Punkt. Auf was soll man sich denn noch verlassen? Ich will doch nicht bei jeder Datei nachsehen, womit sie geöffnet wird. Meistens sehe ich das übrigens, so ändert sich i.A. das Icon. Hier aber nicht. Das finde ich schon ziemlich spooky! Es ist m.E. kein Problem des Browsers, sondern des Finders.
0
Peter_20.02.0620:16
ja, stimmt
0
Rantanplan
Rantanplan20.02.0620:18
Sagst du auch "Hey, super, wer hat mir die Pulle Wein vor die Türe gestellt? Die trink ich doch jetzt gleich mal aus!"? Vor... weiß nicht... vielleicht 20 Jahren oder so gab's den Fall mal, da sind dann gleich ein paar dran Hops gegangen, weil ein "Menschenfreund" was reingetan hatte.

Was ich damit sagen will: ne Pulle erkennt jeder. Aber das heißt noch lange nicht, daß ich es ohne Bedenken benutzen darf, nur weil ich meine zu erkennen was es ist. Wichtig ist: wo kommt es her. Und wenn man nicht weiß wo es herkommt, dann Finger weg, selbst wenn man meint zu wissen was es ist.
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
Rantanplan
Rantanplan20.02.0620:19
PS: Das mit der Pulle war hier bei mir im Viertel... Vielleicht klicke ich deswegen auch nicht auf jeden Müll, der mir unter die Maus kommt
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
svenn
svenn20.02.0620:20
wenn ich dem terminal alle rechte entziehe, wird das heise "jpg" nicht mehr gestartet.
ich arbeite nicht mit dem terminal, weiss daher auch nicht ob das terminal ohne rechte auswirkungen auf andere funktionen des system hat ?
0
Dieter20.02.0621:28
Ich meine auch, dass bei mir standardmäßig die Option deaktiviert war (zumindest nach Mitte 2004). Aber seit dem damaligen Exploit (DMG) sollte man es abgeschaltet haben. Spätestens jetzt!

Ich hatte seinerzeit schon der Sicherheit den Vorzug vor der Bequemlichkeit gegeben.

Ist es tatsächlich so, dass die HelperApp NICHT bei der ersten Ausführung fragt?

Noch mal meine Empfehlung:
Öffnen des Finder-Inspektors (Apfel-Alt-I) und vor dem Doppelklick die betreffende Datei selektieren und einen Blick in den Inspektor werfen was für eine Datei es wirklich ist und mit welchem Programm es geöffnet würde.
0
Dieter20.02.0621:34
Die Prüfung von Safari, was eine sichere Datei ist, ist offensichtlich fehlerhaft und arbeitet (zumindest teilweise) auf Basis der Extention statt auf dem Inhalt. Der "Open" hingegen scheint im sich im Gegensatz dazu nicht durch die Extention irritieren zu lassen, sondern dem Inhalt den Vorzug zu geben.

=> Apple: Bitte eine einheitliche Identifizierung bei Safari und Open!

Oder sehe ich das falsch?

BTW: Ich dachte immer erst wird der Hersteller über eine Lücke informiert, bevor man es in der Öffentlichkeit breit tritt!???
0
Dieter20.02.0621:43
Safari (oder dieser Helper) öffnet nicht nur das ZIP (weil 'sicher'), sondern auch das vermeintliche 'MOV' (weil auch 'sicher'), was dort enthalten war. Und das ist FATAL, weil der Inhalt nicht als Shell-Script erkannt wird, es aber anschließend als solches ausgeführt wird!

amp;:-&:-&:-&:-&
0
MacMark
MacMark20.02.0623:51
Das Shellskript hat die erste Zeile nicht mehr, die es als Shellskript ausweist. Ein normales Shellskript würde erkannt werden und als ausführbares Programm dem Benutzer mit Warnung und Frage angezeigt.

Das kastrierte Shellskript wird ausgeführt, weil der Autor der Datei die Info "immer öffnen mit Terminal" im Finder eingestellt hat. Diese Metainformation bleibt beim Zippen erhalten und wird in einem Verzeichnis __MACOSX gespeichert.

Hier sehe ich mir den Inhalt des Ziparchives nur an:

unzip -l Heise.jpg.zip

Archive: Heise.jpg.zip
Length Date Time Name
-------- ---- ---- ----
76 02-20-06 15:41 Heise.jpg
0 02-20-06 15:41 __MACOSX/
1420 02-20-06 15:41 __MACOSX/._Heise.jpg

Auspacken:

unzip Heise.jpg.zip
Archive: Heise.jpg.zip
inflating: Heise.jpg
creating: __MACOSX/
inflating: __MACOSX/._Heise.jpg

Eine Finderinfo im üblich benannten Verzeichnis und eine Bilddatei?
Was haben wir denn da in der Finderinfo?

strings __MACOSX/._Heise.jpg
%/Applications/Utilities/Terminal.app
usro

Ui, Terminal will er.

Was ist denn das für ein Bild?

file Heise.jpg
Heise.jpg: ASCII text

Oh, eine Textfile!

Was mag da drinstehen?

cat Heise.jpg
/bin/ls -al
echo
echo
echo "heise Security: Sie sind verwundbar."
echo
echo

Sie würden das aktuelle Verzeichnis listen und einen Kommentar ausgeben, hmm.
„@macmark_de“
0
Serge
Serge21.02.0600:07
Hmm, das Ding ist in der Tat sehr bedenklich. Vor allem weil der Finder einem vorgaukelt, das Script sei ein Bild oder ähnliches. Ich sehe hier genau die Problematik, wie es auch unter Windows der Fall ist, dass Dateien von Usern eben nicht mehr richtig erkannt werden und dadurch verleitet werden, diese auszuführen und sich damit schadbringenden Code einschleusen...
Ich war schon immer der Meinung, dass die Dateierkennung an dem Drei-Zeichen-Kürzel eine schlechte Idee war, und bin es übrigens immer noch.
Ich denke, hier sollte sich Apple etwas nehr einfallen lassen. Irgendwie sollte auf einen Blick klar sein, dass eine Datei ausführbar ist....
0
Serge
Serge21.02.0600:09
im Übrigen verdient der Thread wirklich den Titel "ACHTUNG POTENTIELLE SICHERHEITSLÜCKE"... auch wenn es in vielen Fällen ins leere laufen wird, aber damit sollten zumindest die letzten Mac-User mitbekommen, dass das automatische Öffnen keine besonders gute Idee ist.
0
MacMark
MacMark21.02.0600:13
Wenn man das Archiv mit dem Terminal entpackt, wird die Finderinfo getrennt im __MACOSX-Verzeichnis abgelegt. Entpackt man jedoch durch Doppelklick (oder automatisch), dann landet die Finderinfo wieder bei der Datei.

Oben: Per Doppelklick (oder automatisch) entpackt.
Unten: Per Terminal (siehe oben) entpackt.
„@macmark_de“
0
Serge
Serge21.02.0600:15
MacMark: Das heisst aber nur, dass das unzip aus dem Terminal nicht mit Resource-forks klar kommt... was ich persönlich eher schwach finde....
0
MacMark
MacMark21.02.0600:17
Serge Paulus
... Ich war schon immer der Meinung, dass die Dateierkennung an dem Drei-Zeichen-Kürzel eine schlechte Idee war, und bin es übrigens immer noch.
Ich denke, hier sollte sich Apple etwas nehr einfallen lassen. ...

Hat Apple bereits seit 10.4.0: Uniform Type Identifiers (UTIs). Ist aber noch nicht zum Standard erklärt worden von Apple. Wird wohl hoffentlich mit 10.5 passieren.
arstechnica.com/reviews/os/macosx-10.4.ars/11
developer.apple.com/macosx/uniformtypeidentifiers.html
„@macmark_de“
0
Serge
Serge21.02.0600:28
macmark: Hmm, das klingt gut: Ich zitiere: "And unlike file name extensions, it doesn't suck"
Naja, wenn das bei Panther unten drunter schon werkelt, dann hat Apple noch ein wenig zu tun... dann ist das jetztige Verhalten des Finders definitiv als schlecht (Bug?) zu werten... Die Lösung wäre ja dann schon da, irgendwie...
0
Rantanplan
Rantanplan21.02.0602:06
Witzig ist allerdings: wenn man das Ding per Doppelklick auspackt und sich dann anzeigen läßt, welchen UTI es zugewiesen bekommt, dann sieht man das da:

> mdls Heise.jpg
Heise.jpg -------------
kMDItemAttributeChangeDate = 2006-02-21 01:02:51 +0100
kMDItemContentCreationDate = 2006-02-20 15:41:02 +0100
kMDItemContentModificationDate = 2006-02-20 15:41:02 +0100
kMDItemContentType = "public.jpeg"
kMDItemContentTypeTree = ("public.jpeg", "public.image", "public.data", "public.item", "public.content")
kMDItemDisplayName = "Heise.jpg"
kMDItemFSContentChangeDate = 2006-02-20 15:41:02 +0100
kMDItemFSCreationDate = 2006-02-20 15:41:02 +0100
kMDItemFSCreatorCode = 0
kMDItemFSFinderFlags = 0
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSLabel = 0
kMDItemFSName = "Heise.jpg"
kMDItemFSNodeCount = 0
kMDItemFSOwnerGroupID = 501
kMDItemFSOwnerUserID = 501
kMDItemFSSize = 1414
kMDItemFSTypeCode = 0
kMDItemID = 1649077
kMDItemKind = "Dokument"
kMDItemLastUsedDate = 2006-02-20 15:41:02 +0100
kMDItemUsedDates = (2006-02-20 15:41:02 +0100)


Es hat den "falschen", der sich aus der Endung .jpg ergibt
„Wenn ich nicht hier bin, bin ich auf dem Sonnendeck“
0
MacMark
MacMark21.02.0609:04
Die offizielle Typbestimmung ist halt noch die Endung. Die mit Tiger eingeführten UTIs funktionieren zwar schon, jedoch hat die Endung in der GUI noch den Vortritt.

Allerdings kann man UTIs genauso fälschen wie Endungen. Ich gehe davon aus, daß man keine zuverlässige Typisierung einer Datei haben kann, die fälschungssicher ist.

Natürlich sollte automatisches Entpacken deaktiv sein - habe ich schon sei jeher, weil ich keinem Programm zutraue, daß es nicht betrogen werden kann bzgl. Dateityp. Und was geöffnet wird, bestimme ich.

Wie bei dem Trojaner vor einigen Tagen genügt es, sich seine Downloads im Infofenster mal anzusehen, bevor man sie startet. Wer es genauer will, macht es mit dem Terminal wie von Rantanplan und mir gezeigt.

„@macmark_de“
0
MacMark
MacMark21.02.0609:11
Serge Paulus
macmark: Hmm, das klingt gut: Ich zitiere: "And unlike file name extensions, it doesn't suck"
Naja, wenn das bei Panther unten drunter schon werkelt, dann hat Apple noch ein wenig zu tun... dann ist das jetztige Verhalten des Finders definitiv als schlecht (Bug?) zu werten... Die Lösung wäre ja dann schon da, irgendwie...

Ich habe schon öfters erwähnt, daß von den Neuerungen in Tiger im Moment nur die Spitze des Eisbergs in der GUI verfügbar ist. Spotlight ist nur ein Feature, was schonmal ein bißchen zeigt. Die Programme müssen erst angepaßt werden, bevor mehr sichtbar wird. Es hat sich technologisch unter der Haube mehr geändert als in jeder Version zuvor. Eine gute Zusammenfassung gibt ars technica in meinem Link oben.
„@macmark_de“
0
JustDoIt
JustDoIt21.02.0609:34
Diese Analysen sind ja schön und gut.

Nur was macht der Durchschnittstanwender. Der sieht halt eine JPG Datei und klickt drauf. Zur Not gibt der auch noch mal eben das Admin Kennwort ein - wenn's denn sein muß.

Hier muß Apple definitiv für eine sichere Erkennung des Dateityps sorgenund am besten noch eine besondere Kennung (Sperrung) von Dateien wo es Widersprüche zwischen unterschiedlichen Typkennungen gibt. Haben Sie nicht schon Leute für einen neuen Finder gesucht?

0
Dieter21.02.0609:39
Leider kann der Anwender über den Resource-Form zu einfach getäuscht werden. Ich würde mir zwei Sachen wünschen:

1. Ausführbare Dateien mit einem Symbol (analog zum Aliaspfeil) kennzeichnen
2. Keine Ausführbare Dateien als "sicher" in Safari/Helper einstufen!
(Wobei hier keine Ausführbare Dateien vorlag, sie war nur mit Terminal.app verknüpft)
2a. Keine Shell-Scripten starten
0
MacMark
MacMark21.02.0609:45
JustDoIt
Ich halte eine sichere Erkennung von Dateitypen für nicht möglich. Du wirst die Typangabe immer fälschen können.

Selbst, wenn man für die Typisierung den Inhalt heranziehen würde, kann man Typisierungssoftware (Finder oder was auch immer) austricksen. Das Bewertungsschema ist fest in Software und wenn bekannt ist, worauf sie achtet, läßt es sich umgehen. Und die Kriterien lassen sich leicht rausfinden.

Es gibt nur eine Möglichkeit: Jeden Download wie einen Trojaner behandeln. Nicht umsonst werden Checksummen bei professionellen Downloads angeboten, mit denen man die Integrität der Datei prüfen kann.
„@macmark_de“
0
MacMark
MacMark21.02.0609:48
Dieter
Ich würde mir zwei Sachen wünschen:
...
2a. Keine Shell-Scripten starten

Du möchtest alle Shellskripte nicht-ausführbar machen?
„@macmark_de“
0
Dieter21.02.0610:34
MacMark

Sorry! Falsch ausgedrückt! Als UNIXer würde ich ohne Shell-Scripten ja wahnsinnig.
Ich meinte eher: Keine "Shell-Scripten" durch Safari/Helper lokal ausführen!
0
MacMark
MacMark21.02.0610:51
Dieter
Widgets, normale Programme und AppleSkripte können Shellskripte starten. Man sollte den User nicht entmündigen.
„@macmark_de“
0
Schnapper21.02.0611:29
MacMark

Meine Rede. Es gibt einen ganz, ganz einfachen Gedankengang, den man mit jeder heruntergeladenen Datei durchgehen sollte:

"Hab ich die Datei angefordert? Stammt die Datei aus einer Quelle, der ich sicher vertraue?"

Wenn ich eine der beiden Fragen mit "nein" beantworte, muss ich die Datei halt genauer anschauen und im Zweifelsfall von nem Trojaner ausgehen. Punkt.

Vom Betriebssystem tausend Absicherungen zu verlangen, weil man zu faul ist, das Hirn einzuschalten, führt nur zu dem Punkt, dass die User die tausend Warnmeldungen ohne Nachdenken und ohne Durchlesen wegklicken. Und dann sieht's erst recht düster aus...

0
Dieter21.02.0611:35
MacMark ... durch "Safari/Helper".

Widgets, normale Programme und AppleSkripte SOLLEN Shellskripte starten können. Aber Safari sollte diese (Widgets, Programme, AppleScripte) wiederum nicht automatisiert starten. Wenn ich die Sachen von Hand starte, dann agieren diese stellvertretend für mich und es ist meine Verantwortung das Starten zu unterlassen.

Unschön ist einfach nur, dass ich Programme, Scripten nicht direkt am Icon erkennen kann ... Hatte ich in letzter Zeit und vor mehr als einem Jahr schon "benörgelt". Hatte damals die Idee ein Zahnrad oder ein anderes Symbol durch den Finder im Icon einzublenden. Sehe ich dies, bin ich gewarnt. Allerdings muss es Custom-Icons überlagern und vollständig sein, sonst ist die Sicherheit mit dem Blick auf das Icon wiederum trügerisch (wie jetzt auch!)

BTW: Das Shell-Script war ja nicht mal "ausführbar", es war nur mit Terminal.app verknüpft ... Am besten Apple lässt den ganzen "sichere Dateien automatisch öffen"-Kram weg, damit keiner es mehr einschalten kann!
0
Gilderoy Lockhart21.02.0612:48
Ich denke, dass hier v.a. der Finder überarbeitet werden sollte.
Ein paar Vorschläge:
- Im Kontextmenü "Öffnen" - und dahinter das Programm,
mit dem geöffnet wird (das spart Apfel-I), also so:

Hilfe
-------
Öffnen (Terminal)
Öffnen mit...
...

- ausführbare Dateien werden in einer anderen Farbe dargestellt, wo ausführbare Dateien Scripte, Apps und Dateien sind, die mit Interpretern geöffnet werden. Mein "ls" (bzw. Alias ll) färbt die Datei bereits richtig ein -- das sollte der Finder auch können (vgl. Bild)

Gerade der letzte Punkt zeigt, dass eine sicherere Behandlung relativ leicht möglich ist -- daher auch das beigefügt Bild.
0
Gilderoy Lockhart21.02.0612:49
hier das Bild
0
Gilderoy Lockhart21.02.0612:53
Wobei einschränkend dazu gesagt werden muss: 'ls" erkennt die Datei als ausführbar, weil das entsprechende Flag gesetzt ist -- nicht weil sie im Finder mit dem Terminal geöffnet wird. Wenn das Flag entfernt wird (chmod -x...), wird die Datei nicht mehr eingefärbt. Allerdings wird die Datei dann über das Öfnnent mit dem Finder/Terminal nicht mehr ausführen und die Gefahr ist gebannt!
0
Serge
Serge21.02.0613:09
Also Apple könnte da schon noch was tun, um die Sicherheit zu erhöhen. Sicherlich, Hirn wird immer erforderlich bleiben, aber bei Gilderoys Beispiel ist doch klar, dass hier eben noch etwas machbar ist. Sollte der Finder nämlich wie auch immer feststellen, dass die Informationen sich gegenseitig widersprechen, könnte eine entsprechende Warnung erfolgen. Ein jpg soll nicht ausführbar sein. Punkt. Wenn es als ausführbar markiert ist, liegt eindeutig ein Problem vor....
Aber dazu müsste der Finder mal endlich alle ihm zur Verfügung stehenden Daten auch ausnutzen, sprich UTIs, Typ/Creator-Codes, Dateiendungen...
Wir brauchen einen neuen Finder...
0

Kommentieren

Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.