News macOS High Sierra: Sicherheitslücke erlaubt root-Zugriff auf Mac

iSight2TheBlind schrieb:
[...] der Typ der es jetzt verbreitete hat Apple wohl auch vor der Verbreitung bereits kontaktiert.

Wenn dem so ist, ziehe ich meine Aussage zurück.
 
Extrema schrieb:
Ohne SiCrypt Karte kein Boot!

Ja, richtig. Aber mit so Sticks will ich ja keinen sofortigen Schaden anrichten. Ich geh rein, verteil ein paar davon, verschwinde, warte bis jemand die Kisten bootet. Dazu noch ein paar präparierte USB Sticks auf dem Parkplatz verteilen oder an Arbeitsplätzen liegen lassen ;)
 
@Pinabuzz

Der Bug wurde schon vor zwei Wochen in einem Apple Supportforum gepostet, von 24 Stunden kann da keine rede sein.
 
Wobei die Frage ist, ob Apple alle Threads im Supportforum kontinuierlich im Blick hat. Die Foren sind ja auch dafür da, dass sich User gegenseitig helfen können und so nicht die Hotline zugemüllt wird.

Apple hat für Bugs ein extra Verfahren (das man bei Google auch sofort findet):
https://developer.apple.com/bug-reporting/
https://bugreport.apple.com/

Da ein Ticket zu öffnen, mit einer klaren Deadline, wann veröffentlicht wird, wäre der beste Weg gewesen.
 
Klikidiklik schrieb:
Wäre sowas Microsoft passiert, wären wir in diesem Thread schon bei Seite 35.

Hat ja auch einen deutlich höheren Marktanteil. Von daher: logisch.
 
startaq schrieb:

War auch mein erster Gedanke. Die Abfrage des root PW ist bei unixoiden so tief in system eingebettet, dass das einloggen ohne PW noch viel mehr Scheunentore aufgerissen hat, als gerade bekannt.
Anscheinend wird der komplette Authentifizierungsablauf überhaupt nicht mehr gestartet.

Das sowas durch die QA geht... unglaublich.
 
Autokiller677 schrieb:
Machst du selber Softwareentwicklung oder erzählst du nur schön durch die Gegend? Apple wird auf jeden Fall eine Testabteilung haben, die automatisiert und manuell solche Tests durchfahren - ansonsten ist eine Software von der Größe eines OS schlicht unbenutzbar, weil jeder zweite Klick Fehler verursacht. Aber mehrfach mit dem gleichen falschen Passwort versuchen, auf einen deaktivierten Account - ich hätte so ein Szenario im Testplan auch nicht unbedingt drin.

Ansonsten: Kannst du auch belegen, dass MacOS angeblich so unsicher ist, oder ist das auch nur heiße Luft? [...]

Nein, ich bin selbst Entwickler und wie wichtig Testing ist braucht man mir jetzt nicht zweimal sagen; Wobei ich da eher die Brille mit SPICE und Funktionaler Sicherheit auf habe, um nicht zu tief ins Detail zu gehen. Klar, bei MacOS ist das ganze jetzt nicht "kritisch" in dem Sinne, dass da Menschenleben dran hängen. Dennoch offenbart das ganze massive Defizite im Testing. Und Testing ist in dem Sinne ja auch nicht trivial, sondern eine anspruchsvolle Aufgabe, die aber dennoch von keiner Seite so richtig gewürdigt wird. Deswegen ist auch ein sehr häufiger Fehler, dass zwar viel, aber schlicht falsch getestet wird.
Es gibt zig Verfahren, die man auf verschiedenen Ebenen zur Testfalldefinition verwenden kann, allerdings ist auch noch Kreativität gefordert. Nur den Gutfall zu testen ist ja kein echtes Testing, da müssen mindestens die Randwerte, "bad weather"-Situationen und Fehlerfälle aller Art. Wiederholte Zugriffsversuche auf Accounts, egal ob sie vorhanden sind, deaktiviert oder nicht sind jetzt wirklich nicht SO Exotisch, sondern eher trivial.

Woran ich das festmache, dass MacOS in der Hinsicht nicht besonders gut darsteht? Dass in den Sicherheitskonferenzen mit "Hacking-Contest" eigentlich immer als erstes fällt und jedes Mal wenn ich das verfolgt habe da auch die meisten Zero-Day-Exploits (okay liegt in der Natur der Sache) gefunden wurden. Zumindest der Heise-Berichterstattung folgend. Nur ist die Herangehensweise für die Angriffe da ja schon um einige Größenordnungen komplexer.
 
Jesterfox schrieb:
Nö, das ist das selbe Problem. Es betrifft einfach jeden Account bei dem kein Passwort gesetzt ist, nicht nur root.

Meinte ich ja

Anscheinend wird der komplette Authentifizierungsablauf überhaupt nicht mehr gestartet.
Ergänzung ()

B.XP schrieb:
Nein, ich bin selbst Entwickler und wie wichtig Testing ist braucht man mir jetzt nicht zweimal sagen; Wobei ich da eher die Brille mit SPICE und Funktionaler Sicherheit auf habe, um nicht zu tief ins Detail zu gehen. Klar, bei MacOS ist das ganze jetzt nicht "kritisch" in dem Sinne, dass da Menschenleben dran hängen. Dennoch offenbart das ganze massive Defizite im Testing. Und Testing ist in dem Sinne ja auch nicht trivial, sondern eine anspruchsvolle Aufgabe, die aber dennoch von keiner Seite so richtig gewürdigt wird. [...]

Soweit würde ich nicht mal gehen. Aber als Entwickler weißt Du doch selbst am besten wie UAT aufgebaut sind.
Kennst Du auch nur einen UAT in dem steht: "Bitte testen sie die Funktion zehn mal hintereinander?"

Was ich damit meine, ein Tester hätte ja bewusst 10x die PW-Abfrage leer lassen müssen und einfach "durchentern"..
Da würde ich als SuperUser den Schuh zurück in die Entwicklung / QA schieben - müsste sowas nicht durch fuzzing auffallen..?
 
Zuletzt bearbeitet:
Der Bug scheint aber wohl anders zu sein... da wird in der Authentifizierung mal falsch abgebogen und dadurch beim ersten Versuch das eingegebene Passwort für den entsprechenden Benutzer gesetzt und deshalb ist ab dann das Login möglich. Aber die Authentifizierung an sich wird schon jedes mal durchlaufen.
 
Blöde Frage, aber ist doch nur halb so wild, oder? Mein System ist mit FV abgesichert und wie soll sich die Person einloggen, wenn mein Gerät die Passwortabfrage aktiviert hat? Es scheint ja nur zu funktionieren, wenn man schon am Gerät ist und dieses entsperrt ist.
 
Das ist so richtig. Es war ein krasser Fehler, der aber nur in gewissen Umgebungen (bei gemeinsam genutzten Macs, Schulen, Behörden, etc) wirklich gefährlich wurde. Mittlerweile ist die Lücke mit dem Sicherheitsupdate 2017-001 auch behoben.
 
Zuletzt bearbeitet: (Rechtschreibung)
Chibi88 schrieb:
Blöde Frage, aber ist doch nur halb so wild, oder? Mein System ist mit FV abgesichert und wie soll sich die Person einloggen, wenn mein Gerät die Passwortabfrage aktiviert hat? Es scheint ja nur zu funktionieren, wenn man schon am Gerät ist und dieses entsperrt ist.

Es geht ja nicht nur um dein Privatgerät. In Firmen haben Mitarbeiter mit Absicht keine Admin-Rechte, damit sie keinen Mist machen können.
Dann gibt es Macs, die irgendwo als Kundenterminal stehen. Oder Ausstellungsgeräte in Läden. Da sollte keiner mit root Rechten rumwerkeln.
 
Autokiller677 schrieb:
Es geht ja nicht nur um dein Privatgerät. In Firmen haben Mitarbeiter mit Absicht keine Admin-Rechte, damit sie keinen Mist machen können.
Dann gibt es Macs, die irgendwo als Kundenterminal stehen. Oder Ausstellungsgeräte in Läden. Da sollte keiner mit root Rechten rumwerkeln.

Kann ich den root Benutzer einfach deaktivieren und das Problem ist behoben?
 
Der ist standardmäßig deaktiviert, aber durch den Bug kann man ihm ein Passwort geben und dadurch aktivieren. Und dann viele schöne Dinge mit dem Rechner tun...
 
Chibi88 schrieb:
Kann ich den root Benutzer einfach deaktivieren und das Problem ist behoben?

Wie Kharne sagte, das reicht nicht. Du kannst den root Benutzer aktivieren und selber ein Passwort setzen. Dann geht der Angriff nicht mehr.

Das war aber nur der Workaround. Es gibt noch andere deaktivierte User ohne Passwort auf einem Unix System, die sich mit dem Angriff alle aktivieren lassen.

Daher ist die beste Lösung, so schnell wie möglich das Update 2017-001 einzuspielen. Das behebt den zugrunde liegenden Fehler und der Angriff wird verhindert - gegen alle Accounts.
 
Angenommen ich habe das Update eingespielt und das Problem ist behoben. Ist es nicht sinnvoll nicht doch den root Benutzer zu aktivieren und ein komplexes Passwort zu geben? Auch wenn der jetzt standardmäßig deaktiviert ist, ist doch normalerweise kein PW vergeben. Würde das etwas "extra Sicherheit" geben?
 
Zurück
Oben