1) Nee, met fysieke toegang is het niet altijd een eitje om root te verkrijgen. Daar is FileVault voor.
Filevault is een whole disk encryption technologie. Het is leuk dat ze de boel op de schijf versleutelen maar je maakt hier wel de cruciale fout door te denken dat je daarmee dan veilig zit. Niets is minder waar. Filevault is namelijk gekoppeld aan de gebruikersaccounts. Het wachtwoord wat voor de gebruiker wordt gebruikt, wordt ook gebruikt om de Filevault schijf te unlocken. Daarmee is de werking van Filevault volledig afhankelijk van de sterkte van het zwakste wachtwoord van alle gebruikers op de machine.
Is dit aanpasbaar? Jazeker: je creëert een account die niet mag inloggen en alleen Filevault mag unlocken welke je dan ook een apart en sterk wachtwoord geeft. Daarna maak je alleen maar gebruikers aan die juist geen Filevault mogen unlocken maar wel mogen inloggen. Deze accounts geef je ook een apart wachtwoord. Alleen op deze wijze heb je Filevault en useraccounts van elkaar gescheiden en maakt een zwak wachtwoord van een gebruiker je Filevault encryptie niet ongedaan.
2) Deze bug was exploiteerbaar als "fysieke toegang" al betekende "iemand is 30 seconden afgeleid" - niet "ik steel iemands laptop en reboot hem".
Aangezien de gemiddelde computer maar 1 gebruiker heeft en die gebruiker ook meteen de admin gebruiker is, is het gebruik van een root account totaal overbodig. Wat je hier doet is van Amsterdam naar Rotterdam reizen via Rome, Moskou, New York terwijl er een directe verbinding is. Waarom makkelijk doen als het moeilijk kan?

3) Nee, dit was geen bug waar je fysieke toegang voor nodig had. Alle software/malware op je Mac kon dit misbruiken om root-toegang te krijgen door het volgende AppleScript te runnen:
4) Nee, dit was niet alleen lokaal exploiteerbare bug. Als je op je Mac file shares aanzet, of Apple Remote Desktop, kon je op afstand worden geowned.
Fout. Dit was wel een bug waar je fysieke toegang voor nodig hebt want standaard staan alle remote services en het root account uit. Iemand moet op de betreffende machine dus willens en wetens die remote services inschakelen EN daarbij ook zorgen dat deze voor ALLE gebruikers is ingesteld. Wanneer er alleen een subset wordt gekozen gaat je verhaaltje al niet meer op (en zie hier waarom dat remote exploiten niet bij iedereen werkte).
Remote een AppleScript draaien is standaard ook al niet mogelijk. Je zult de gebruiker dus moeten verleiden om dat script te draaien aka social engineering. Je vergeet hier dat jouw scriptje met een kleine aanpassing ook werkt met een volledig gepatcht systeem
Btw, op de commandline werkt een root account zonder wachtwoord niet. SSH connecties idem. Tenzij dit natuurlijk ook weer door de gebruiker is aangepast...
Bizar dat mensen denken dat dit een of ander "klein" probleem was.
Tja, kwestie van een correcte analyse van het probleem maken aangevuld met een dosis nuchterheid.
[Reactie gewijzigd door ppl op 24 juli 2024 18:00]