Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?
Forum>Software>Lösung für die derzeitige Sicherheitslücke

Lösung für die derzeitige Sicherheitslücke

derondi
derondi21.02.0618:07
Hallo zusammen!

In einem vorherigen Thread (http://www.mactechnews.de/index.php?function=17&thread=45758&cat=2) wurde eine mögliche Lösung für die derzeitige Sicherheitslücke (Entpackte Archive können getarnte Skripte enthalten) diskutiert. Hier möchte ich jetzt (m)einen Lösungsansatz der Community zur Verfügung stellen und bitte euch, diesen zu testen und ggf. zu verbessern.

Unter dem unten angegebenen Link findet ihr ein DMG, welches einen Automator-Workflow sowie eine Read Me zu Installation und Vorgehensweise des Workflows.

Das angehängte Bild zeigt euch, wie der Workflow arbeitet.

Frohes testen und spart nicht mit Feedback!
0

Kommentare

MacMark
MacMark21.02.0619:34
Du nimmst nur dem User die Ausführungsrechte, nicht der Gruppe, nicht Anderen. Ganz zu schweigen von etwaigen ACLs, die Vorrang hätten.
„@macmark_de“
0
derondi
derondi21.02.0620:37
MacMark:
Ja, hast Recht. Da hatte ich vorhin zu kurz gedacht. Aber zu 90% würde ja selbst das reichen - es geht ja darum den User davor zu bewahren versehentlich das Ding zu starten.

Die Änderung in
chmod ugo-x echo "$f"
sollte doch reichen, oder?

Wie man ACLs einsetzt weiß ich leider (noch) nicht. Aber wer dies tut braucht sicher mein Skript nicht oder kann es selbst anpassen, was?

MacMark: Kannst mich aber gerne aufklären bzgl. der ACLs..
0
MacMark
MacMark21.02.0621:09
derondi
...
MacMark: Kannst mich aber gerne aufklären bzgl. der ACLs..

arstechnica.com/reviews/os/macosx-10.4.ars/8
„@macmark_de“
0
derondi
derondi21.02.0621:28
OK, so wie ich das verstanden habe müsste der Trojaner für genau den User, der gerade angemeldet ist und das Skript versehentlich starten soll, eine Rule "<User> allow execute" mitbringen. Die Konstellation halte ich zwar für theoretisch möglich, aber praktisch nicht vorhanden.

Wer will kann sich ja die Zeilen
chmod +a "<User> deny execute" echo "$f"
etc. entsprechend hinzufügen...
0
derondi
derondi21.02.0621:45
Eine Version mit der modifizierten Zeile chmod ugo-x echo "$f" ist online...
0
derondi
derondi21.02.0622:45
Habe festgestellt, dass länger dauernde Safari-Downloads nach meinem bisherigen Workflow nicht vollendet werden können. In der neuen Version (21.2.06 21:44) ist dies behoben...
0
Dieter21.02.0623:02
Ich weiss nicht ... aber Shell-Scripten das x-Flag (bzw. entsprechende ACL-Flags) zu entziehen ist nicht wirklich die Lösung!

1. Der Anwender sollte sich ansehen, was er da bekommt, bevor er es öffnet! Immer!
2. Apple könnte Hinweise bei sensiblen Daten einbauen, was aber NIE 100% sein wird!
3. Wir müssen uns im Klaren sein, dass man das Auge täuschen kann! Icons können täuschen!
0
derondi
derondi21.02.0623:11
Dieter:
Na ja, vielleicht nicht die Lösung - die sollte Apple wohl liefern (siehe Mail-Problem) - aber zumindest eine, die vorläufig ziemlich gut funktioniert.

Ich denke unbekannten, aus dem Internet heruntergeladenen Inhalten generell die Rechte zu nehmen hilft auf jeden Fall. Sie können einfach nicht mehr gestartet werden.

Seien wir doch mal ehrlich: Niemand sieht sich immer genau an was er da gerade runtergeladen hat - besonders wenn er es in einem Forum o.ä. seines Vertrauens findet. Ich denke mein Ansatz ist da zumindest sicherer als eine irgendwie an einem Identifier festgemachte Kennzeichnung "gefährlicher Inhalt" oder ähnlicher Kram.
0
Dieter21.02.0623:28
Sorry hatte es auf den Mail-Bug bezogen.

Mhm ... hilft ja auch nur für Dateien, die ich direkt aus dem Netz hole (und in dem Download-Ordner landen). Die kritischen Dateien, die in Archiven (ZIP) stecken und mit einem "falschen" Icon etwas vortäuschen um diese doppel zu klicken, werden nicht berücksichtigt. Für die Downloads (vorallem die nicht erwarteten) über Safari reicht es das "Öffnen sicherer Dateien abzuschalten" und den Inspektor des Finder offen zu lassen (hatte ich letzte Woche auch noch nicht).

Für den Mail-Bug ( ) hilft es nicht ...

Was nicht im Download-Ordner landet (z.B. Mail-Attachments) oder was archiviert ist, was zur Täuschung genutzt wird, hilft es auch nicht ... Mhm! Oder habe ich es komplett falsch verstanden?
0
derondi
derondi21.02.0623:39
Für das Mail-Problem hilft es in der Tat nicht. Oder nur bedingt, aber dazu später.

Im Prinzip habe ich mit dem Workflow/Skript einen Quarantäne Ordner geschaffen - ähnlichen denen aus AV-Programmen. Alles, was in diesem Ordner landet kann nur geöffnet werden - nicht aber gestartet. Landet also so ein ZIP mit Trojaner-Inhalt in dem Ordner und wird per Doppelklick entpackt, springt automatisch der Mechanismus an und entzieht den entpackten Inhalten die Ausführungsrechte. Gegen den Schrott hilft es also definitiv.

Voraussetzung ist allerdings - und das schreibe ich auch im Read Me - das dieser Ordner als Default in Safari eingestellt ist!

Lädt man jetzt wirklich mal eine App runter, die als ZIP daherkommt, kann man das Archiv einfach aus dem Download-Ordner rausziehen und dann entpacken. Oder man speichert es direkt woanders. Bei DMGs ist das nicht erforderlich, da diese i.d.R. ihre Inhalte ja als Volume bereitstellen.

Beim Mail-Problem hilft es insofern, dass man einen Quarantäne-Ordner hat, in dem man die empfangenen Mail-Attachments speichern kann. Von dort aus ist ein Doppelklick "sicher". Alternativ kann man auch seine komplette Mailbox ebenso schützen. Das dürfte aber arg zu Lasten der Performance gehen...
0
Dieter22.02.0609:59
Ok, soweit OK! Wenn das ZIP einen Ordner mit einer kompromitierenden Datei enthält, dann wird dem Ordner die x-Rechte entzogen, so dass ich diesen nicht mehr öffnen kann. Die enthaltene Datei behält ihre Rechte.

Um die Rechte von Dateien in Ordner zusätzlich zu berücksichtigen, aber nicht die Ordner selber wäre:
find "$f" -type f -exec chmod ugo-x {} \;
find "$f" -type f -exec chmod +a "<User> deny execute" {} \;

Wie derondi aber sagt muss man Sachen die man braucht außerhalb des Ordners auspacken, weil nun die Rechte-Reparatur deutlich zu lästig wird. Zudem ist der Find-Exec keine Rakete, aber es betrifft ja nur NEUE Objekte, also sollte es im Rahmen bleiben.

Ich hoffe Apple reagiert sehr sehr zügig! Auch Secunia hat es als High Critical eingestuft:
0

Kommentieren

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