Push-Nachrichten von MacTechNews.de
Würden Sie gerne aktuelle Nachrichten aus der Apple-Welt direkt über Push-Nachrichten erhalten?

Mysteriöse Mac-Probleme in Hollywood-Studios: Fehlerhaftes Chrome-Update der Auslöser

Kürzlich kursierte eine Meldung, wonach es bei diversen Hollywood-Studios Probleme beim Einsatz des 2013er Mac Pro gibt. Zunächst wurde über mögliche Schwierigkeiten im Zusammenspiel mit dem Videoschnitt-Tool Avid Media Composer spekuliert, doch inzwischen hat sich ein anderer Schuldiger herausgestellt. Google räumte einen Fehler bei einem Chrome-Update ein, der sich negativ auf macOS-Geräte auswirkt – die potenziellen Folgen sind Instabilitäten, Abstürze und abbrechende Bootvorgänge.


Chrome-Update beschädigt macOS-Dateisystem
Google spricht im entsprechenden Supportdokument von einem Chrome-Update, das einen Bug enthalten könnte, der das Dateisystem von macOS beschädigt. Die betroffene Chrome-Version kann nur Schaden anrichten, wenn Nutzer die System Integrity Protection (SIP) deaktiviert haben – was offenbar an diversen Hollywood-Schnittplätzen der Fall ist. Die System Integrity Protection muss beispielsweise abgestellt werden, wenn Anwender bestimmte externe GPUs via Thunderbolt 2 nutzen möchten.

Der Chrome-Bug wirkt ebenfalls bei älteren Apple-Rechnern, die von Haus aus kein SIP unterstützen. Nur wenn Nutzer SIP nicht abgeschaltet haben und einen Mac verwenden, auf dem mindestens OS X Mavericks (10.9) installiert ist, geht keine Gefahr von besagter Chrome-Aktualisierung aus.

Terminal-Befehl als provisorische Lösung
Wenn Nutzer von dem Problem betroffen sind und ihren Mac im schlimmsten Fall nicht mehr hochfahren können, sollen sie ihren Rechner im macOS-Wiederherstellungsmodus starten, so Google. Danach geht es über die Dienstprogramme zum Terminal, in dem Anwender folgenden Befehl eingeben (es wird die Bezeichnung „Macintosh HD“ für das Boot-Laufwerk angenommen):
chroot /Volumes/Macintosh\ HD # "Macintosh HD" is the default
rm -rf /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bu ndle
mv var var_back # var may not exist, but this is fine
ln -sh private/var var
chflags -h restricted /var
chflags -h hidden /var
xattr -sw com.apple.rootless "" /var
Nach einem Neustart ist die fehlerhafte Version des Google Software Update entfernt und Nutzer können ihren Mac laut Google wieder normal benutzen. Das Unternehmen kündigte zudem ein neues Update für Chrome an, das den Fehler beseitigen soll. Wie lange Anwender darauf warten müssen, ist nicht bekannt.

Kommentare

sierkb25.09.19 16:35
Wer's nachverfolgen möchte, hier der Bug dazu:

bugs.chromium.org: Issue 1007358: Keystone modifies /var

bzw.

bugs.chromium.org: Issue 1007946, Duplicate (Closed): Keystone crashes
0
Pixelmeister25.09.19 16:49
Ein Browser-Update, dass so massive Probleme auf den betroffenen Macs macht – herzlichen Glückwunsch, Google, das ist mal ein "richtiger" Bug.

Ich könnte jetzt gehässigerweise anfügen, dass Googles Bug-Hunter vielleicht stärker Fehler in eigenen Produkten suchen sollten, als vorwiegend in Konkurrenz-Software. – aber das lasse ich mal.
+10
sierkb25.09.19 16:57
Dieser Bug ist echt nicht schön. Erst recht, wenn man bedenkt, dass auch SIP-enabled-Rechner massive Probleme dadurch hatten (ich z.B., auch ich hatte eine massive Bootschleife dadurch und hochdrehende Lüfter und einen Amok-laufenden Update-Prozess von Chrome – trotz eingeschalteten SIPs).

Warum die runtergeladenen Chrome-Updates unterhalb von $DARWIN_USER_TEMP_DIR (gesandboxtem randomisierten /var/folders/e2/awu6giss6r8dre0f058cpqdr1003gp/T/-Pfad…) gemountet werden, anstatt unterhalb von /Volumes, wird wohl mal zu erklären sein, habe ich nie verstanden, warum der Keystone-Installer (der in den letzten Tagen offenbar fehlerhaft war) das macht.

[OT]
Pixelmeister:

Dank denen ist macOS und iOS trotzdem sicherer, und Apple hat mit deren Hilfe schlimme bzw. schlimmste Lücken schließen können, die Apple offenbar nicht selber vorher gefunden hat– und Du und ich haben somit sicherere Apple Betriebssysteme (sie sind also so sicher, wie Apple sie lässt bzw. wie andere die Fehler finden). Wäre es Dir lieber gewesen, sie hätten den Mund gehalten, Apple drauf sitzenlassen sollen ("sollen sie doch alleine zusehen, wie sie ihre Systeme dicht kriegen – wir sagen nix"), uns ohne Hilfe Apples Fehlern überlassen sollen? So Arschloch kann man natürlich auch sein: um die Fehler wissen, aber schön den Mund halten, und die Ahnungslosen Anwender unwissend einer vergrößerten Gefahr ausgesetzt und ins offene Messer laufen lassen. Ich weiß nicht, ob Dir DAS lieber wäre.
[/OT]
+2
Marcel_75@work
Marcel_75@work25.09.19 18:36
In diesem Kontext betrachtet, kann man wirklich froh sein, dass Apple die SIP-Daumenschrauben weiter anzieht.

Mit 10.15 "Catalina" passiert da ja einiges, u.a. gibt es einen 'unsichtbaren' read-only-APFS-Bereich für bestimmte Systembestandteile.

So lange das System auf lange Sicht nicht völlig zugenagelt wird, ist das sicher i.O.
+1
sierkb25.09.19 19:24
Marcel_75@work:

Apple muss das nur machen, weil sie dem Standardnutzer im ausgelieferten Werkszustand Admin-Rechte geben. Anstatt den Benutzer dazu zu drängen und es ihm anzuempfehlen, sofort nach erster Inbetriebnahme eines Macs einen Non-Admin-Benutzer als Standardnutzer einzurichten mit begrenzten Rechten, zumindest keinen Admin- und sudo-Rechten (so, wie sie es in ihren eigenen Sicherheitsrichtlinien auch seit Jahren vernünftigerweise empfohlen haben und so wie es jede andere Sicherheitsrichtlinie auch empfiehlt und es unter Unix bereits seit Jahr und Tag üblich ist). Wer sowas nicht macht bzw. unterlässt, der Bequemlichkeit für die Nutzer wegen (und u.a. eigenen Sicherheitsempfehlungen zum Trotz), der muss halt erst recht zusätzliche Sicherheitslinien einziehen – so wie mittels SIP geschehen – um root bzw. root-Level System-Ebenen zu schützen bzw. da eine zusätzliche Brandmauer einziehen und somit den Abstand zum Standard-Nutzer mit seinem (Admin-)Rechte-Level (statt Non-Admin) zu erhöhen.
-4
ssb
ssb25.09.19 19:46
Ein guter Grund für mich, Chrome einfach mal komplett zu löschen - ich habe den eh nicht benutzt.
Was in der Anleitung vergessen wurde:
  • /Library/Google (einfach komplett löschen)
  • /Users/<username>/Library/Google (auch gleich mit löschen, da ist auch ein Updater drin)
  • Library/Launch\ Daemons/com.google* löschen (da wird keystone gestartet)
  • Library/Launch\ Agents/com.google.* (da liegen weitere Daemons drin)
  • /User/<username>/Library/Launch\ Agents/com.google.* (auch hier)

Dann gegebenenfalls neu starten, damit der Keystone Daemon sicher nicht mehr geladen ist. Kann man im Terminal mit
ps -ax | grep google
prüfen, wenn da nur grep google angezeigt wird, läuft nichts im Hintergrund. Nach dem Neustart ist auf jeden Fall der Keystone Agent nicht mehr bei launchd registriert.
+4
Marcel_75@work
Marcel_75@work25.09.19 20:45
sierkb:

Klar, da kann ich Dir nur beipflichten – und genau das ist auch eine meiner ersten Empfehlungen bei sämtlichen Kunden seit Jahren (Trennung zwischen Admin-Account und "Arbeits"-Account ohne Admin-Rechte) …

Nur ist es z.B. so, dass speziell der Google Updater im Enterprise-Umfeld äußerst beliebt war, weil er eben auch bei Standard-Usern ohne administrative Rechte verlässlich Aktualisierungen installieren konnte, inkl. Steuerungsmöglichkeiten über Skripte und sogar Configuration Profiles.

Dass Google jetzt so einen heftigen Fehler im Updater hat (und dies nicht aufgefallen ist), kann ich mir nur so erklären:

Bei Google wird wahrscheinlich nur auf den aktuell mit Sicherheits-Updates versorgten Systemen gearbeitet / getestet (also das aktuelle System und die beiden Vorgänger-Systeme), außerdem wird SIP natürlich nicht deaktiviert.

Und im error log hätte man diesen bug zwar sehen können [müssen], aber da er bei aktiven SIP eben keinen Schaden anrichten konnte, ist das leider niemanden aufgefallen bei Google …

PS: Und da man auf anderen Seiten schon wieder die übelsten Verschwörungstheorien bezüglich Google lesen kann (sinngemäß: "erst diese Project Zero Meldung bezüglich der iOS-Sicherheit, jetzt die Startfähigkeit von Macs "kaputt gemacht", was kommt als nächstes"?) – Google engagiert sich seit Jahren in diversen Open Source Projekten rund um macOS, u.a. auch in sicherheitsrelevanten Bereichen, als Beispiel sei hier "Santa" genannt:



Zu glauben, dass Google solche Fehler "mit Absicht" machen würde, entbehrt jeder Grundlage.
+2
dan@mac
dan@mac25.09.19 22:22
Aber welchen vernünftigen Grund hat Apple denn den Standardbenutzer ab Werk Admin Rechte zu geben? Irgendwas müssen die sich dabei ja denken.
-1
maculi
maculi25.09.19 22:36
dan@mac
ganz einfach: Der erste Benutzer, der angelegt wird, muss nunmal ein Admin sein (ohne Admin geht es nicht). Werden weitere Nutzer angelegt, dann ist da die Voreinstellung auf Standard gesetzt. Wenn sich jemand einen Mac zulegt und nur einen Benutzer anlegt, dann ist der zwangsläufig Admin. Es könnte jeder hergehen und mindestens zwei Nutzer anlegen, aber die Entscheidung muss jeder für sich treffen, Apple kann niemanden dazu zwingen.
+1
Peter Eckel26.09.19 07:53
sierkb
Apple muss das nur machen, weil sie dem Standardnutzer im ausgelieferten Werkszustand Admin-Rechte geben.
Das ist so nicht richtig.

Die Admin-Rechte, die Apple dem ersten angelegten Benutzer gibt, sind im wesentlichen mal daran aufgehängt, daß er Kommandos mit sudo ausführen kann (im Installer passiert nicht viel anderes - es wird das Benutzerpaßwort abgefragt und damit dann unter sudo der privilegierte Teil der Installation durchgeführt).

Das machen andere unixoide Betriebssysteme, z.B. Ubuntu, ganz genau so. Wiederum andere, z.B. die RedHat-Familie, legt bei der Installation zwei Benutzer an - einmal root und einmal einen unprivilegierten Benutzer ohne sudo-Rechte, der dann aber auch wirklich nicht zur Administration verwendet werden kann, weshalb man dann wieder alle administrativen Tätigkeiten unter root ausführen oder die sudo-Rechte von Hand einrichten muß - IMHO ein Rückschritt gegenüber der sudo-Lösung in Ubuntu.

SIP zielt in eine ganz andere Richtung, die unter anderen Unix-artigen Systemen von Sicherheitsschichten wie SELinux abgedeckt werden. Diese Sicherheitsschichten haben eben die Aufgabe, auch root die Allmacht zu nehmen - genau wie SIP unter macOS.

Bezogen auf den aktuellen Fall - Chrome will unbedingt irgendwas in Verzeichnisstrukturen installieren, wo es eigentlich nichts verloren hat - hätte ein unprivilegierter Benutzer auch nicht geholfen. Zu diesem Zweck hätte der Installer wie jetzt auch ggf. einen Benutzernamen und auf jeden Fall ein Paßwort anfordern müssen, um sich die erforderlichen Rechte zu verschaffen, und damit wäre die Installation wieder unter root erfolgt. Auch in diesem Fall hätte wieder nur SIP zwischen dem Installer und vollständigem Systemzugriff gestanden.

Grundsätzlich sehe ich es aber ähnlich wie Du auch: Je weniger Rechte der Benutzer hat, der die tägliche Arbeit am System durchführt, desto besser. Wieviel das im Einzelfall ist, hängt natürlich auch von der Art der Arbeit mit dem System ab: Ein Entwickler wird hier unter Umständen mehr Zugriffsrechte benötigen als ein Mailleser, Surfer und Dokumenteeditierer.

Die Lösung von Apple (und anderen wie Ubuntu), dem ersten Benutzer Admin-Rechte in Form von sudo einzuräumen, ist ein Kompromiß. Einige der Einschränkungen, die dieser Kompromiß mit sich bringt, sind mit SIP und den kommenden weiteren Entwicklungen in Catalina abgedeckt, und wie das Beispiel des verbockten Google-Installers zeigt, ist das auch dringend nötig.
Ceterum censeo librum facierum esse delendum.
+5
Peter Eckel26.09.19 07:59
Marcel_75@work
Nur ist es z.B. so, dass speziell der Google Updater im Enterprise-Umfeld äußerst beliebt war, weil er eben auch bei Standard-Usern ohne administrative Rechte verlässlich Aktualisierungen installieren konnte, inkl. Steuerungsmöglichkeiten über Skripte und sogar Configuration Profiles.
Dafür gibt es einen schönen Ausdruck. Backdoor.
Marcel_75@work
außerdem wird SIP natürlich nicht deaktiviert.
Wie sierkb schrieb, hat er auch bei einem System mit SIP massive Probleme gehabt. Was mich zu der Vermutung drängt, daß Google nicht mal den Fehler, den SIP ihm eingebracht hat (nämlich den verbotenen Zugriff auf /var) sauber abgefangen hat. Und das in einem Stück Code, das mit hohen Zugriffsrechten läuft.

Wäre was für Google Project Zero
Marcel_75@work
Und im error log hätte man diesen bug zwar sehen können [müssen], aber da er bei aktiven SIP eben keinen Schaden anrichten konnte, ist das leider niemanden aufgefallen bei Google …
Sorry, wer privilegierten Code schreibt und dann nicht mal so viel Sorgfalt aufwendet, die Logs zu lesen, sollte nochmal genauer nachdenken, was er da macht. Auch wenn's Google ist.
Marcel_75@work
Zu glauben, dass Google solche Fehler "mit Absicht" machen würde, entbehrt jeder Grundlage.
Sehe ich bis zum Beweis der Schuld des Angeklagten ähnlich. Aber besser wird die Schlamperei dadurch nicht, und steht schon in einem gewissen Widerspruch zur ansonsten sehr gewissenhaften Arbeit von Project Zero. Andere Abteilung ...
Ceterum censeo librum facierum esse delendum.
+3
Walter Plinge26.09.19 11:04
sierkb
Apple muss das nur machen, weil sie dem Standardnutzer im ausgelieferten Werkszustand Admin-Rechte geben.

Im Zusammenhang mit dem Fehler ist diese Diskussion Unsinn. Für den privilegierten Zugang zum System würde in jedem Fall das Admin-Passwort abgefragt, völlig unabhängig ob - wie jetzt - für "sudo" oder eben bei getrenntem Account "admin/root".

SIP soll das System eben genau davor schützen, dass der privilegierte User sich das System zerschießt (bzw. von ihm autorisierte Software).
+2
sierkb26.09.19 11:06
Peter Eckel:

1. Was Ubuntu macht, ist nicht unbedingt immer sinnvoll und richtig, es kann gut sein, dass sie sich da, auch der Bequemlichkeit für den Nutzer wegen, an Apples Praxis orientiert haben und es genauso gemacht haben – entgegen einschlägiger Sicherheitsempfehlungen. Und es ist nicht so, dass Ubuntu deshalb nur Lob eingeheimst hat, ganz im Gegenteil: da hagelte esmeiner Erinnerung nach gehörig Kritik.

2. Das von der NSA erdachte gehärtete und open-sourcte Linux (Kernel) namens SELinux war Vorbil für entsprechende gleichzielende Bemühungen unter BSDs (TrustedBSD, OpenBSD) und erhielt in jener adaptierten Form und somit dann später auch Einzug unter OSX, ebenso wie Novells AppArmor-Ansatz (openSUSE, Ubuntu) adaptiert wurde. SELinux ist ebenso auch Bestandteil von Android, vor allem durch Samsungs Zutun.

3. Warum die in /var/folders schreiben bzw. dort die Images mounten (mounten: zumindest bei mir waren sie dort gemountet, als ich mich vor ein paar Tagen auf Ursachenforschung begab, warum der Update-Prozess Amok läuft bzw. mehrere solche auf einmal parallel waren, keiner abgeschlossen, alle hängend, immer wieder einneuer dazu)?
Und wenn macOS' System-Funktion NSTemporaryDirectory() – Returns the path of the temporary directory for the current user es erzwingt bzw. dorthin zeigt – nach /var/folders/…?

Und dem betreffenden Entwickler der Update-Funktion ein kapitaler und unverzeihlicher Flüchtigkeitsfehler beim Aufräumen nach dem Mounten passiert ist?
(Ich könnte ihn würgen dafür, solche massiven Probleme hatte ich vor ein paar Tagen bei mir mit dem GoogleSoftwareUpdate (trotz aktivierten SIP, es war bei mir noch nie deaktiviert – es hat bei mir wohl Gottsei Dank noch Schlimmeres verhindert). Sowas darf nicht passieren!)

Interessant übrigens die letzten aktuellen Kommentare in den beiden von mir obig genannten Bugs über den aktuellen Stand beim Analysieren und Fixen des Fehlers.
0
maculi
maculi26.09.19 11:45
Das Google hier reichlich Mist gebaut hat, da sind wir uns wohl einig.
Jetzt könnte man noch diskutieren, ob Apple den normalen Nutzer ausreichend darüber informiert, das es sinnvoll ist, ausser dem Primärnutzer (= Admin) noch einen zweiten als Standardnutzer anzulegen. Eine vernünftige und kurze Info, die der gewöhnliche Mensch versteht, kombiniert im Fall der Fälle mit dem dreimaligen Nachfragen, ob es wirklich bei einem einzigen Nutzer bleiben soll würde das Problem etwas entschärfen.
Nur ändert das nichts daran, das letzten Endes die Verantwortung bei demjenigen liegt, der den Mac in Betrieb nimmt. Wenn der ums verrecken nicht will dann will er eben nicht (und muss schlimmstenfalls mit den Konsequenzen leben). Das erinnert an das leidige Thema Backup. Was haben sich da schon diverse Leute den Mund fusslig geredet, und trotzdem gibts noch immer andere, die meinen ohne Backup auskommen zu können. Manchen ist eben nicht zu helfen, und zu ihrem Glück zwingen können wir oder Apple sie auch nicht.
Dann werden sie halt durch Schaden klug (oder bleiben so dumm, wie sie vom Pferd gefallen sind).
0
sierkb26.09.19 12:07
[OT]
maculi
Jetzt könnte man noch diskutieren, ob Apple den normalen Nutzer ausreichend darüber informiert, das es sinnvoll ist, ausser dem Primärnutzer (= Admin) noch einen zweiten als Standardnutzer anzulegen. Eine vernünftige und kurze Info, die der gewöhnliche Mensch versteht, kombiniert im Fall der Fälle mit dem dreimaligen Nachfragen, ob es wirklich bei einem einzigen Nutzer bleiben soll würde das Problem etwas entschärfen.

In ihren einschlägigen Security-Empfehlungen, irgendwo verborgen auf Apples Servern, haben sie genau das jahrelang getan und empfohlen. In der Theorie. Auf dem Papier. Von kaum einem gewusst.
Gemacht, beworben und ausgeliefert haben sie das Betriebssystem aber leider so, dass diese Hinweise, eingebaut ins Betriebssystem selber, z.B. durch entspr. Pop-Up-Meldungen oder entspr. Nutzerführung bei der Installation/Inbetriebnahme bisher stets fehlten. In ihren einschlägigen eigenen Sicherheitsempfehlungen hingegen haben sie jahrelang glasklar und eindringlich nahegelegt, sofort nach erster Inbetriebnahme einen Non-Admin-Benutzer mit eingeschränkten Rechten anzulegen und diesen fortan als Standardnutzer zu nutzen und den Admin-Nutzer auf keinen Fall für die alltägliche Nutzung zu benutzen und nur für unbedingt notwendige Admin-Aufgaben.
Theorie versus Praxis. Reden versus Tun.

Nur ändert das nichts daran, das letzten Endes die Verantwortung bei demjenigen liegt, der den Mac in Betrieb nimmt.

Dazu muss er erstmal wissen bzw. informiert werden, um überhaupt Entscheidungen treffen zu können. Wenn er aber im Unklaren ist und nicht informiert ist über die Dinge und die Sachlage und die Möglichkeiten, Gefahren und Risiken, der Hersteller selber ihm gegenüber schön seinen Mund hält und ihn uninformiert hält, so wie Apple das leider gerne macht, den Anwender quasi künstlich dumm hält ("was Du nicht weißt, macht Dich nicht heiß" bzw. "ich, der Hersteller sage Dir: 'brauchst Du nicht zu wissen'), kommt der auf diese Weise kurzgehaltene und entmünigte Anwender gar nicht erst auf die Idee, es anders zu machen oder zu verändern, vertraut dem Hersteller blind (obwohl der hinter vorgehaltener Hand was Anderes sagt als er nach außen hin tut), wiegt sich trügerischerweise und unhinterfragt in absoluter Sicherheit und dass schon alles seine uneingeschränkte Richtigkeit habe, wie ihm dargebracht.
[/OT]
0
albertyy26.09.19 19:04
Was ist denn, besonders in Hollywood, denn so schlecht am Safari Browser, daß man sie Chrome installieren muss ?
-1

Kommentieren

Sie müssen sich einloggen, um die News kommentieren zu können.