Safari-Absturz - dann Info wegen schwerer Sicherheitslücke

JARVIS, One, nochmals danke für eure Infos. Ich bin wohl paranoid, das stimmt. Aber sicher ist sicher. Leider kann ich das Crashlog nicht dranhängen txt, pdf usw. ist wohl im Forum nicht erlaubt.

Schöne Grüße
 
Leider kann ich das Crashlog nicht dranhängen txt, pdf usw. ist wohl im Forum nicht erlaubt.
Wenn musst du es in CODE Tags pasten, aber das komplette Log interessiert eh nicht, nur der Crash Grund und der Backtrace des gecrashten Threads, der ist auf dem Foto abgeschnitten.

Aber häng dich nicht an die Monterey Lücke, wenn du Big Sur hast.
Das Safari 15.3 Update kam am 26.1., das hast du doch bestimmt installiert.
 
  • Gefällt mir
Reaktionen: dg2rbf
Ja, das hatte ich installiert vor ein paar Tagen. Allerdings gab es heute ein Update für Safari zur Beseitigung der Lücke, wenn ich das richtig verstanden habe. Wohl auch eine andere Built-Nummer.
 
Habe jetzt erstmal eine Betriebsystem-Aktualisierung auf die aktuelle Version Monterey durchgeführt. Da ich einen M1-Mac habe, habe ich mich reingelesen. Es ist wohl so, dass ich durch Festhalten der Power-Buttons in einen Recovery-Mode komme und dort dann das ganze System plätten kann. Zur Neuinstallation benötigt man dann wohl eine Internetverbindung.

Hat damit jemand Erfahrungen? Soll ich das tun oder ist das jetzt doch too much? Ich gehe davon aus, dass bei der Aktualisierung von Big Sur auf Monterey sämtliche Betriebsystemdateien getauscht werden, sodass zuvor eingerichtete Malware damit auch weg ist. Kann das vielleicht jemand bestätigen?

Danke für eure Hilfe.
 
Ach ja, hier der Teil aus dem Crash-Log:

Application Specific Information:
*** Terminating app due to uncaught exception 'NSRangeException', reason: '*** -[NSConcreteTextStorage attribute:atIndex:longestEffectiveRange:inRange:]: Range or index out of bounds'
terminating with uncaught exception of type NSException
abort() called

Application Specific Backtrace 1:
0 CoreFoundation 0x000000018da6b8e8 __exceptionPreprocess + 240
1 libobjc.A.dylib 0x000000018d794fe8 objc_exception_throw + 60
2 UIFoundation 0x0000000190f2613c -[NSTextStorage ensureAttributesAreFixedInRange:] + 0
3 UIFoundation 0x0000000190f45c60 -[NSMutableAttributedString(NSMutableAttributedStringKitAdditions) setBaseWritingDirection:range:] + 196
4 Safari 0x0000000102658840 -[BrowserWindowController _updateUnifiedFieldWritingDirection] + 228
5 Safari 0x00000001026445cc -[BrowserWindowController unifiedFieldBecameFirstResponder:] + 280
6 Safari 0x00000001029f71c8 -[UnifiedField fieldEditorDidBecomeFirstResponder:] + 404
7 Safari 0x0000000102a399f0 __42-[UnifiedFieldEditor becomeFirstResponder]_block_invoke + 220
8 libdispatch.dylib 0x000000018d73e128 _dispatch_call_block_and_release + 32
9 libdispatch.dylib 0x000000018d73fec0 _dispatch_client_callout + 20
10 libdispatch.dylib 0x000000018d74e314 _dispatch_main_queue_callback_4CF + 884
11 CoreFoundation 0x000000018da2d998 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 16
12 CoreFoundation 0x000000018d9ec3ac __CFRunLoopRun + 2524
13 CoreFoundation 0x000000018d9eb258 CFRunLoopRunSpecific + 600
14 HIToolbox 0x0000000195912280 RunCurrentEventLoopInMode + 292
15 HIToolbox 0x0000000195911ff4 ReceiveNextEventCommon + 552
16 HIToolbox 0x0000000195911db4 _BlockUntilNextEventMatchingListInModeWithFilter + 72
17 AppKit 0x00000001901dd2ac _DPSNextEvent + 836
18 AppKit 0x00000001901dbc4c -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1292
19 Safari 0x000000010255eb9c -[BrowserApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 236
20 AppKit 0x00000001901cda98 -[NSApplication run] + 596
21 AppKit 0x000000019019f4c4 NSApplicationMain + 1064
22 Safari 0x00000001028fc6e4 SafariMain + 436
23 libdyld.dylib 0x000000018d90d430 start + 4
 
Unter 20 Stunden nach Release ist nicht langsam, sondern recht gut.
Nenn mich verrückt, aber ich hätte jetzt erwartet, dass 2 Sekunden nach Bereitstellung des Updates sofort ein Fenster aufpoppt, das mich darüber informiert, dass SOFORT ein Update eingespielt werden muss. Alternativ 2 Sekunden nach Bereitstellung des Updates eine automatische Installation im Hintergrund mit dem Hinweis, wenn sie fertig ist bzw eine App / der Mac neugestartet werden muss.

Ganz besonders, wenn eine Lücke bereits aktiv ausgenutzt wird.

Beste Grüße
 
Wenn musst du es in CODE Tags pasten, aber das komplette Log interessiert eh nicht, nur der Crash Grund und der Backtrace des gecrashten Threads, der ist auf dem Foto abgeschnitten.

Aber häng dich nicht an die Monterey Lücke, wenn du Big Sur hast.
Das Safari 15.3 Update kam am 26.1., das hast du doch bestimmt installiert.
Für Big Sur gab es für Safari 15.3 zwei Updates:
(…die ich jeweils tagsdrauf installierte)
Safari:
Version: 15,3
Quelle: Apple
Installationsdatum: 27.01.22, 17:12

Safari:
Version: 15,3
Quelle: Apple
Installationsdatum: 12.02.22, 07:31
 
Für Big Sur gab es für Safari 15.3 zwei Updates:
(…die ich jeweils tagsdrauf installierte)
Ja. Als ich den Beitrag schrieb, war es nicht auf der deutschen Security Seite gelistet.
 
  • Gefällt mir
Reaktionen: dg2rbf
Mag paranoid klingen, aber wenn ich nun auf dem vermeintlich kompromittierten System macOS 12 über die Softwareaktualisierung lade und das System dann neu aufsetze, wer garantiert mir, dass sich die Schadsoftware nicht an das macOS 12 Installationspaket hängt und mir damit ein frisches, aber wieder infiziertes System installiere?

Ja, ein klein wenig bist du paranoid. Aber dagegen hilft Wissen.

Hier ein kleiner Teil Wissen:

Die Art und Weise des System bei macOS 12 in Zusammenarbeit mit den Einstellungen des Startsicherheitsprogramms garantiert dir, dass ein installiertes OS nicht manipuliert installiert / gestartet werden kann, selbst wenn irgendwie magischerweise beim download, so wie du das dir zusammen fantasierst, was angehängt sein sollte. Warum? Weil das System kryptografisch signiert ist und jede Änderung / Ergänzung auch nur eines Bits, eben dieses kryptografische Siegel verändern und damit brechen würde. In Zusammenarbeit mit dem Startsicherheitsprogramm (das per default so eingestellt ist) wird der Start von einem nicht korrekt signierten System nicht ermöglicht.

Auch im laufenden Betrieb kann per default die Systempartition nicht manipuliert werden, da sie ergänzend zum Siegel auch noch auf einer read-only-Partition läuft.

Du siehst, dein Angst-Szenario ist in diesem Punkt unbegründet.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: k-mac, JARVIS1187 und dg2rbf
Was mich nun beschäftigt:
1.Wie bekomme ich eine saubere Neuinstallation hin? Ich möchte den Mac neu aufsetzen, alle Daten sollen dabei gelöscht werden (Habe noch ein älteres Backup).
2. Einige Dateien sichere ich über einen Stick, die nicht in meinem alten Backup enthalten sind. Wie kann ich sicher gehen, dass sich dort nicht irgendwo Maleware festgebissen hat, die ich ja beim zurückspielen auf das frische System dann wieder einbringen würde.
3. Es heißt in den Beschreibungen, dass durch die Lücke "Beliebiger Programmcode" auf den betreffenden Maschinen ausgeführt werden kann. Ich gehe also davon aus, dass es keinen Sinn macht, hier auf bekannte Trojaner oder so suchen zu lassen, korrekt?

Falls du wirklich immer noch meinst, du müsstest alles löschen, dann gehe wenigstens den Weg, den dir macOS 12 mittlerweile anbietet.

Zu. 1. Du musst das System nicht neu installieren. Warum? Sieh meine Ausführungen oben zum kryptografischen Siegel. Nimm den Weg, den dir Monterey anbietet: Starte Systemeinstellungen, Menu Systemeinstellungen -> Einstellungen und Inhalte löschen.
https://support.apple.com/de-de/HT212749

Zu 2. Das hier ist dein grundlegendes "Problem". Eine 100%-ige Sicherheit wird es nur dann geben, wenn du diesen Stick vernichtest, denn selbst ein Untersuchen auf die aktuelle Malware sagt ja nichts darüber aus, dass nicht schon unbekannte Malware drauf sein könnte. Das ist das logische Problem an "unbekannt". Dennoch, du kannst den Grad deiner Sicherheit erhöhen, wenn du dir die Wahrscheinlichkeit überlegst, mit der diese neue Malware auf dein System gekommen ist. An ältere Malware musst du nicht denken, denn damit hast du bislang ja beruhigt gearbeitet. Also sieh dir den Stick durch nach ausführbaren Dateien. Am besten im Terminal. Diese überträgst du nur dann, wenn die File-Modifiaction-Time älter ist, als dein Absturzdatum. Das sollten mit einer Wahrscheinlichkeit von nahezu 1 alle Dateien sein. Nichtausführbare Dateien kannst du ohne weitere Prüfung rüber kopieren.

Zu 3. stimmt.
 
  • Gefällt mir
Reaktionen: k-mac
Ich habe mir jetzt ein Chromebook bestellt, die ganzen reinen Surf-Arbeiten, Twitter, usw. laufen jetzt halt darüber. Offenbar muss ich meinen Mac als Produktivsystem vor Angriffen schützen, Apple träumt hier offenbar nur so vor sich hin. So viel Ärger wie ich jetzt haben, ohne dann sicher zu sein, dass ich überhaupt wieder ein cleanes Systes hinbekomme.

Abschließend eine Frage:

Wie kommst du bei deinen Ängsten zu der Entscheidung und Ansicht, dass ein Chromebook die von dir verlangte 100%-ige Sicherheit bietet? Könnte es vielleicht sein, dass du hier nur Wunschträumen erlegen bist?

Ansonsten, viel Spaß mit dem Chromebook.
 
  • Gefällt mir
Reaktionen: BalthasarBux und dg2rbf
Man kann auch in einer VM surfen, einige Malware prüft doch darauf und läuft dann nicht.
Und durch das Snapshot System kann man einen definierten Zustand wiederherstellen.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zunächst mal danke für de rege Teilnahme an der Diskussion zu meinem Problem.

Die Art und Weise des System bei macOS 12 in Zusammenarbeit mit den Einstellungen des Startsicherheitsprogramms garantiert dir, dass ein installiertes OS nicht manipuliert installiert / gestartet werden kann, selbst wenn irgendwie magischerweise beim download, so wie du das dir zusammen fantasierst, was angehängt sein sollte. Warum? Weil das System kryptografisch signiert ist und jede Änderung / Ergänzung auch nur eines Bits, eben dieses kryptografische Siegel verändern und damit brechen würde. In Zusammenarbeit mit dem Startsicherheitsprogramm (das per default so eingestellt ist) wird der Start von einem nicht korrekt signierten System nicht ermöglicht.

D.h. der ganze Baum unter /System ist der Teil, der auf einer eigenen Partition liegt und kryptografisch abesichert ist? Nur um das Verfahren dahinter zu verstehen. Nach meinem Kenntnisstand ist es so, dass es eine Installationspartition gibt, auf der das System zur Installation bereit liegt, diese Installationspartition ist signiert / gesichert und wird bei jedem OS-Update mit den Daten des neues OS ersetzt. Von dort werden dann in einem Installationsprozess Dateien auf die andere Partition geschrieben, auf der das ausführbare OS mit allen Zubehör sowie die Benutzerordner liegen. Hier können im laufenden Betrieb auch Dateien verändert oder hinzugefügt werden, auch innerhalb des /System-Ordners, ohne das dies erstmal so bemerkt werden würde. Denn ansonsten verstehe ich auch nicht, wie Malware generell ihr Dasein auf macOS fristen kann, und das auch nach einem Neustart. Es muss also möglich sein, dass sich bösartige "Extensions" irgendwo einnisten, die auch von einem frischen System dann ausgeführt werden.

Zur aktuellen Lücke habe ich gelesen, dass sie erlaubt, dass ein Angreifer beliebigen Code ausführen kann. Beliebiger Code muss nicht zwangsläufig die Installation eines Trojaners oder einer anderen Schadsoftware sein, sondern kann auch nur ein einmaliges Ereignis z.B. zum Abfragen bestimmter Inhalte sein (z.B. Kopiervorgang von Dateien aus dem Benutzerordner oder ähnliches) Denn "beliebiger Code ausführen" klingt für mich nach Zugriff mit root-Rechten. Als Angreifer macht es aber Sinn, ein Tool auf dem System zu lassen, das dort dauerhaft rumhängt und weitere Schweinereien ermöglicht (Nachladen von Code usw). Und hier ärgert mich das träge Vorgehen Apples. Dass es auch anders geht zeigt z.B der Signal-Messenger für macOS, dort bekomme ich manchmal mehrmals am Tag den Hinweis, dass es eine aktualisierte Version gibt, die ich dann mit einfachem Klicken laden kann. Die App wird dann einmal kurz neu gestartet und fertig. SO muss es m.E. auch bei kritischen Systemupdates laufen!

Das sehr angenehme Verfahren zum Löschen der Dateien bei Monterey löscht ja nur die Schlüssel, damit sind die nicht mehr lesbar und das System nur noch in seiner reinen Form drauf, ähnlich iOS. Das wäre die Variante, die ich tatsächlich noch in Betracht ziehen würde, bei der Neueinrichtung des Systems geht dann aber wieder ein halber Tag drauf.

Ich habe mir das Chromebook jetzt als reine Surfmaschine bestellt, Auf dem Mac laufen dann meine Programme, während ich mal so nebenbei Twitter, Youtube, Foren, also reine Surf-Tatätigkeiten auf dem Chromebook mache, damit durch den Besuch infizierter Seiten nicht mein wichtiges Hauptsystem mit sensiblen Daten in Mitleidenschaft gezogen wird. Was soll denn daran falsch sein?

Beste Grüße
 
  • Gefällt mir
Reaktionen: dg2rbf
D.h. der ganze Baum unter /System ist der Teil, der auf einer eigenen Partition liegt und kryptografisch abesichert ist? Nur um das Verfahren dahinter zu verstehen. Nach meinem Kenntnisstand ist es so, dass es eine Installationspartition gibt, auf der das System zur Installation bereit liegt, diese Installationspartition ist signiert / gesichert und wird bei jedem OS-Update mit den Daten des neues OS ersetzt. Von dort werden dann in einem Installationsprozess Dateien auf die andere Partition geschrieben, auf der das ausführbare OS mit allen Zubehör sowie die Benutzerordner liegen. Hier können im laufenden Betrieb auch Dateien verändert oder hinzugefügt werden, auch innerhalb des /System-Ordners, ohne das dies erstmal so bemerkt werden würde. Denn ansonsten verstehe ich auch nicht, wie Malware generell ihr Dasein auf macOS fristen kann, und das auch nach einem Neustart. Es muss also möglich sein, dass sich bösartige "Extensions" irgendwo einnisten, die auch von einem frischen System dann ausgeführt werden.

Nein, nicht ganz.

Bei APFS gibt es keine Partionen im klassischen Sinn, sondern Volumes. Dabei teilen sich die Volumes den Platz des APFS-Containers in dem sie sind. /System enthält insoweit das System und sog. "firmlinks" die auf Verzeichnisse der Daten-Partition verweisen und daher beschreibbar sind. Wenn du also im Terminal in /System herum navigierst, landest du auch mal über /System/Volumes/Data/Users/dein_name z. Bsp in deinem Homeverzeichnis. Insoweit ist /System nicht im klassischen Sinne nicht die "Systempartition"

Bei der Installation wird nichts "umgeschrieben". Sobald das OS auf der Platte ist, ist es gesichert / signiert. Da kann nichts mehr dran verändert werden. Die veränderbaren Verzeichnisse liegen auf dem Daten-Volume (nicht Partition). Und werden vom System-Volume aus mit den firmlinks aus erreichbar.

Alles kann sich also nur auf der Daten-Partion abspielen, ob nu Datendateien, App-Bundles, Driver, Extensoins oder Malware. Einen Neustart überleben die halt, wenn sie sich in den Startprozess z.Bsp über LaunchAgents einklinken, Löschen kann man erschweren durch z.Bsp das immutable Flag etc.

Das System-Volume kann jedenfalls nicht verändert werden ohne dass das Siegel bricht.
 
  • Gefällt mir
Reaktionen: dg2rbf und k-mac
Ich habe mir das Chromebook jetzt als reine Surfmaschine bestellt, Auf dem Mac laufen dann meine Programme, während ich mal so nebenbei Twitter, Youtube, Foren, also reine Surf-Tatätigkeiten auf dem Chromebook mache, damit durch den Besuch infizierter Seiten nicht mein wichtiges Hauptsystem mit sensiblen Daten in Mitleidenschaft gezogen wird. Was soll denn daran falsch sein?
wenn du beide Systeme getrennt voneinander hälst und keine Verbindung untereinander oder Datenaustasch hast, ist das ok. Es klnag zuerst halt so, als ob duu meintest, dass ein Chromebook keine Sicherheitslücken hätte.
 
  • Gefällt mir
Reaktionen: dg2rbf
SO muss es m.E. auch bei kritischen Systemupdates laufen!

wobei selbst das nur marginal was an der Sicherheitslage verändert, da die Zeit von der Erstinbetriebnahme der Malware bis zur Fertigstellung eines Fixes der bedrohendere Teil ist und nach wie vor vorhanden bleibt. Soviel zu deiner 100%-igen Sicherheit.
 
  • Gefällt mir
Reaktionen: dg2rbf
Einen Neustart überleben die halt, wenn sie sich in den Startprozess z.Bsp über LaunchAgents einklinken, Löschen kann man erschweren durch z.Bsp das immutable Flag etc.
D.h. man sollte gezielt nach solchen Einträgen suchen und prüfen, ob die, die da sind, ihre Daseinsberechtigung haben. Allerdings würde ich als Angreifer einen solchen ersetzen, der sowohl die eigentliche Aufgabe als auch zusätzlich die Schadfunktion ermöglichst. Interessant wäre es, wenn LaunchAgents selbst eine Signatur der Software hätten, mit der sie aufs System gekommen sind.

Bei der Installation wird nichts "umgeschrieben". Sobald das OS auf der Platte ist, ist es gesichert / signiert.
D.h. eine Aktualisierung plättet alles vorher dagewesene im System - wobei auch vorher schon ein gesichertes System bestand, das daher nicht kompromittiert werden konnte (im OS-Bereich).

Soviel zu deiner 100%-igen Sicherheit.
Mir geht es um die bestmögliche Absicherung meines Systems. Ich habe - aus welchen Gründen auch immer - den Safari-Absturz mit einem unbefugten Zugriff auf das System gleichgesetzt, obgleich ein Absturz, wie hier ja schon diskutiert wurde, dafür kein Indikator ist. Der zeitliche Zusammenhang machte mich skeptisch. Ausnutzen der Lücke soll eigentlich auch ohne irgendwelche Abstürze, also Kenntnis des Nutzer, erfolgen können. Der Absturz könnte daher, wenn ein bösartiger Angriff dahinter steckt, eher ein Indikator für das Scheitern sein. Wenn jemand noch Kenntnisse bei Lesen des Crash-Logs hat, würde ich mich über ein Feedback freuen. One hatte ja schon grob was dazu geschrieben.

Es geht mir also nur um die Sicherheit meines Systems, von "100%-iger Sicherheit", die ich grundsätzlich erwarten würde, habe ich nirgendwo gesprochen.

Beste Grüße
 
D.h. eine Aktualisierung plättet alles vorher dagewesene im System - wobei auch vorher schon ein gesichertes System bestand, das daher nicht kompromittiert werden konnte (im OS-Bereich).
du hast doch geschrieben, das nach der Installation nichmals was "umgeschrieben" wird. Da wird nichts umgeschrieben. Das neue OS wandert auf die Platte und das alte verschwindet. Das System wird als snapshot behandelt.
 
  • Gefällt mir
Reaktionen: dg2rbf
Zurück
Oben Unten