Bereiche
News
Rewind
Tipps & Berichte
Forum
Galerie
Journals
Events
Umfragen
Themenwoche
Kleinanzeigen
Interaktiv
Anmelden
Registrierung
Zu allen empfangenen Nachrichten
Suche...
Zur erweiterten Suche
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 Lockhart
20.02.06
19: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!
Hilfreich?
0
Kommentare
Peter_
20.02.06
19:59
bei mir ist diese Option standardmäßig ausgeschaltet gewesen. (und ist es noch)
Hilfreich?
0
Gilderoy Lockhart
20.02.06
20: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.
Hilfreich?
0
Peter_
20.02.06
20:16
ja, stimmt
Hilfreich?
0
Rantanplan
20.02.06
20: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“
Hilfreich?
0
Rantanplan
20.02.06
20: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“
Hilfreich?
0
svenn
20.02.06
20: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 ?
Hilfreich?
0
Dieter
20.02.06
21: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.
Hilfreich?
0
Dieter
20.02.06
21: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!???
Hilfreich?
0
Dieter
20.02.06
21: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;:-&:-&:-&:-&
Hilfreich?
0
MacMark
20.02.06
23: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“
Hilfreich?
0
Serge
21.02.06
00: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....
Hilfreich?
0
Serge
21.02.06
00: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.
Hilfreich?
0
MacMark
21.02.06
00: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“
Hilfreich?
0
Serge
21.02.06
00: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....
Hilfreich?
0
MacMark
21.02.06
00: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“
Hilfreich?
0
Serge
21.02.06
00: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...
Hilfreich?
0
Rantanplan
21.02.06
02: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“
Hilfreich?
0
MacMark
21.02.06
09: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“
Hilfreich?
0
MacMark
21.02.06
09: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“
Hilfreich?
0
JustDoIt
21.02.06
09: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?
Hilfreich?
0
Dieter
21.02.06
09: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
Hilfreich?
0
MacMark
21.02.06
09: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“
Hilfreich?
0
MacMark
21.02.06
09: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“
Hilfreich?
0
Dieter
21.02.06
10: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!
Hilfreich?
0
MacMark
21.02.06
10:51
Dieter
Widgets, normale Programme und AppleSkripte können Shellskripte starten. Man sollte den User nicht entmündigen.
„@macmark_de“
Hilfreich?
0
Schnapper
21.02.06
11: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...
Hilfreich?
0
Dieter
21.02.06
11: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!
Hilfreich?
0
Gilderoy Lockhart
21.02.06
12: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.
Hilfreich?
0
Gilderoy Lockhart
21.02.06
12:49
hier das Bild
Hilfreich?
0
Gilderoy Lockhart
21.02.06
12: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!
Hilfreich?
0
Serge
21.02.06
13: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...
Hilfreich?
0
Kommentieren
Diese Diskussion ist bereits mehr als 3 Monate alt und kann daher nicht mehr kommentiert werden.