[10.6 Snow Leopard] Mit gesetztem Firmware-Passwort: Booten im Single User Mode möglich?

[naich]

Hallo,

Ich habe ich mit der Möglichkeit beschäftigt, ein Firmware-Passwort zu vergeben. Dieses verlangt das Passwort, wenn man von einem alternativen Datenträger booten will, und deaktiviert alle möglichen Tastenkombinationen beim Booten (C, D, Cmd+s, Cmd+v, Shift ...).
Dies ist auch erstmal der Grund, wieso ich das Passwort setzen will. Schließlich kann sonst jeder, der mein Macbook in die Hand bekommt, einfach im Single User Mode booten und hat dann sofort uneingeschränkten Zugriff auf die Dateien.

Nun kann aber sicher mal der Fall eintreten, dass man bei Boot-Problemen die o.g. Kombinationen braucht, aber keine Installations-CD hat, um das Firmware Passwort wieder zu deaktivieren. Kennt jemand eine Möglichkeit, wie man in diesem Falle trotzdem noch z.B. in den Single User Mode kommt?

Nach meinen bisherigen Google-Ergebnissen ist dies wohl nicht vorgesehen. Wenn dem so ist, stellt sich mir die Frage: War Apple einfach zu faul, für die Tastenkombinationen auch einfach die Passwort-Abfrage einzubauen, oder gibt es ernsthafte Gründe dagegen? Mir erscheint es sehr kontraproduktiv, wenn man bei Problemen erstmal das Passwort umständlich ausschalten und nach erfolgter Reparatur wieder setzen muss...

 

[Mac 2.2]

Das habe ich mich auch schon gefragt Anscheinend gab es mal ne Tastenkombination auf PPC Macs, die bei intel Macs nicht mehr funktioniert - habe ich auch schon selbst ausprobiert -> http://support.apple.com/kb/HT1352?viewlocale=de_DE

Würde mich aber auch mal interessieren, warum diese Funktion abgestellt wurde....

 

[Rastafari]

Aus Sicherheitsgründen.
Es gibt einen Weg, ja. Genaugenommen sogar viele, von denen aber nur einer oder zwei interessant sind.
Aber ich muss dich warnen: Das ist nichts, das ein Amateur einfach nachmachen bzw abtippen kann.
(Das erfordert einen kleinen Geländelauf durch die EFI-Shell.)

Unsachgemässe Anwendung kann nicht nur zu totalem Datenverlust, sondern auch zu einem nicht mehr startfähigen Mac führen, dem man mit dem Schraubenzieher an seine Innereien gehen muss. Da solche Warnungen grundsätzlich nicht ernst genug genommen werden halte ich es nicht für besonders klug, das hier offen im Forum zu erläutern.
Wenn du verstehst was ich meine.

 

[naich]

Erstmal danke für deine Antwort.

Aus Sicherheitsgründen.

Hmmm, kannst du mir genauer erklären, inwieweit es unsicherer sein sollte, wenn nach erkennen der Tastenkombination einfach das Passwort abgefragt wird?

(Das erfordert einen kleinen Geländelauf durch die EFI-Shell.)

Bringt also einem Normalo-User auch nicht wirklich was. Schade...

Eine Möglichkeit in den Single-User Mode zu kommen habe ich hier gefunden - auch wenn die IMHO nicht sonderlich intuitiv ist (keine Ahnung ob das mit den aktuellen Geräten überhaupt noch funktioniert...):
http://hints.macworld.com/article.php?story=20020725085134490

Das setzt aber vorraus, dass man im Bedarfsfall noch überhaupt bis zum Login-Schirm kommt.

Kann man wenigstens das Firmware-Kennwort auch vom installierten MacOS aus zurücksetzen? Nach [1] konnte man von der Tiger-CD das entsprechende Programm kopieren, bei Leopard wird darauf verwiesen, die DVD zu benutzen.
Das Kopieren scheint auch noch von der SL-DVD möglich zu sein. Ist es sicher das Programm auch aus dem installierten OSX heraus anzuwenden?

[1] http://support.apple.com/kb/ht1352

 

[Mac 2.2]

Vermute ich jetzt mal nicht Immerhin setzt das zurücksetzen oder setzen des Firmware-Passwortes generell einen Neustart, damit die Änderungen wirksam werden. Von daher kannst du auch grad von der DVD booten
Ich bin mir fast sicher das das kopierte Programm nicht funktionieren wird, aber kannst es ja mal ausprobieren ob es überhaupt startet

 

[Rastafari]

Hmmm, kannst du mir genauer erklären, inwieweit es unsicherer sein sollte, wenn nach erkennen der Tastenkombination einfach das Passwort abgefragt wird?

Das Passwort muss schon *vor* der Verarbeitung irgendwelcher Bootparameter abgefragt werden.
Das Passwort wird von der Firmware verarbeitet, die Tastenkombinationen zur Steuerung des Kernels aber erst vom Bootloader.
Da dieses Kennwort *jedes* auf dem System startbare OS zuverlässig schützen soll (und auch andersherum das System vor evtl nicht erwarteten "OS"), diese Tasten aber nur für OS X eine Bedeutung haben, wird sicherheitshalber *überhaupt kein* Kernelparameter übergeben, egal wie der auch lauten mag. Das übermittelte "-s" kann in anderen Umgebungen gänzlich andere Bedeutungen haben, deren Tragweite man nicht vorhersagen kann --> zu unsicher.

keine Ahnung ob das mit den aktuellen Geräten überhaupt noch funktioniert.

So wie dort beschrieben hat das überhaupt noch nie funktioniert.
Das Kommando "shutdown" hatte zwar früher mal einen implizierten Defaultparameter, der heute als Option "-k" zwingend angegeben werden muss, aber der bringt dich nicht in den Single-User Mode. (Das ist lediglich ein "Kick-Off", d.h.: Multiuser-Modus mit erzwungener Abmeldung aller Logins, die bis zum Reboot gesperrt bleiben, und das ist was völlig anderes als "Single-User".)

Kann man wenigstens das Firmware-Kennwort auch vom installierten MacOS aus zurücksetzen?

Ja, das ausschalten des Schutzes ist problem- und gefahrlos möglich (zumindest bei allen mir bekannten intel/EFI Systemen. Das aktivieren bzw setzen/ändern des Kennworts geht auch, aber das ist >>gefährlich<< und sollte keinesfalls gemacht werden).

sudo nvram security-mode="none"

Anschliessend ist ein sauberer, regulärer Shutdown erforderlich (erst dann werden Laufzeitänderungen von der Hardware angenommen, so wie bei anderen NVRAM Einstellungen auch).

Es gibt aber eine praktischere Möglichkeit, den SU-Modus beim Start zu erzwingen, ganz ohne irgendeinen Tastendruck, und ohne dass der Kennwortschutz dazu entfernt werden muss (dann wird NUR noch im SU Modus gebootet, von jedem Startvolume, solange bis du das wieder rückgängig machst.) Du brauchst nur einfach den Bootloader dazu bringen sich noch von anderen Stellen weitere Bootparameter abzuholen, die müssen nicht unbedingt vom Keyboard her kommen.
Das hier sorgt zB dafür dass jeder gebootete mach-Kernel dauerhaft glaubt, du hättest "Command+S" gedrückt:

sudo nvram boot-args="-s"

...und das hier stellt den Normalzustand wieder her:

sudo nvram boot-args=""

Etwas spezieller wird das in dieser man-Page behandelt.

Das Kopieren scheint auch noch von der SL-DVD möglich zu sein. Ist es sicher das Programm auch aus dem installierten OSX heraus anzuwenden?

Definitiv: NEIN.
Es funktioniert zwar, aber wer es aufgrund einer nicht erwarteten Problemlage mit exotischeren Tastenbelegungen/Fremdkeyboardtreibern/modifizierten Layouts/InputManagern etc irgendwie hinbekommt eine "illegale" Zeichenfolge reinzuhacken, der wird sein System nicht mehr booten können.
(Erlaubt sind nur ASCII und Ziffern, aber durch einen kleinen Kobold könnten da zB auch Unicode-Zeichen mit reingeraten - die sind zur Bootzeit unmöglich mit der Tastatur einzugeben und damit bist und bleibst du ausgesperrt.)
Das Prog sollte nur in der klar definierten und überschaubaren Systemumgebung der Installations-DVD eingesetzt werden. Ich bezweifle stark, dass das für einen anderen Einsatz wasserdicht genug ausgetestet wurde.

Ausserdem ist es sowieso ein erhebliches Risiko, das auf der lokalen HD installiert zu haben - das lädt den "Lebenspartner mit Chromosom-XY-Mangel" doch geradezu dazu ein, damit rumzuspielen und das Kennwort dann zu ... "vergessen". Besonders während dieser unerklärbaren "PMS Phasen"... nicht gut.

 

[naich]

Das Passwort muss schon *vor* der Verarbeitung irgendwelcher Bootparameter abgefragt werden.
Das Passwort wird von der Firmware verarbeitet, die Tastenkombinationen zur Steuerung des Kernels aber erst vom Bootloader.

Ok, das macht natürlich Sinn. Beim setzen des FW-Passworts wird ja der "command"-Mode verwendet - so wie ich gelesen habe gibt es auch noch einen full-mode, welcher das Passwort bei jedem Start abfragt. Ich hab keine Informationen dazu gefunden, ob/wie dieser Modus überhaupt bei Apple-Geräten setzbar ist, aber theoretisch müsste er ja dann das Problem lösen und die Tastenkombis würden keinen Sicherheitsverlust mehr bedeuten.

Definitiv: NEIN.
Es funktioniert zwar, aber wer es aufgrund einer nicht erwarteten Problemlage mit exotischeren Tastenbelegungen/Fremdkeyboardtreibern/modifizierten Layouts/InputManagern etc irgendwie hinbekommt eine "illegale" Zeichenfolge reinzuhacken, der wird sein System nicht mehr booten können.

Wieso das, das Passwort wird doch bei einem normalen Start gar nicht abgefragt? Oder schaut sich dich Firmware - auch wenn es nicht nötig ist - bei jedem Start das gespeicherte Passwort an und schaut ob das Format korrekt ist?
Wenn nicht, dann könnte man bei einer Fehleingabe immerhin noch normal booten und das Passwort wieder löschen.

(Erlaubt sind nur ASCII und Ziffern, aber durch einen kleinen Kobold könnten da zB auch Unicode-Zeichen mit reingeraten - die sind zur Bootzeit unmöglich mit der Tastatur einzugeben und damit bist und bleibst du ausgesperrt.)
Das Prog sollte nur in der klar definierten und überschaubaren Systemumgebung der Installations-DVD eingesetzt werden. Ich bezweifle stark, dass das für einen anderen Einsatz wasserdicht genug ausgetestet wurde.

Ich hab das Programm mal kopiert und gestartet, das geht wunderbar. Im Gegensatz dazu ist zb. bei "Kennwörter zurücksetzen" explizit und natürlich berechtigterweise ne Sperre eingebaut, welche das Programm nur von der Install-DVD starten lässt.

Wie ist es zu erklären, dass für Tiger sogar offiziell noch der Weg mit dem kopieren beschrieben wird? Ich vermute, dass es damals schon das gleiche Problem mit Unicode existierte...
Wobei es doch sicher nicht so schwierig sein dürfte, in dem Programm den String als ASCII zu behandeln, und nur Zahlen und Buchstaben zuzulassen?! Ich kann mir zumindest keine Systemerweiterung vorstellen, die einen 7-Bit-Vergleich z.B. mit 'a' oder 'z' entsprechend manipulieren würde.

Vielen Dank auch für die anderen ausführlichen Infos. Wenigstens kann man sich auch ohne Install-DVD behelfen, wenn man noch ne funktionierende Konsole hat.

 

[Rastafari]

wird ja der "command"-Mode verwendet - so wie ich gelesen habe gibt es auch noch einen full-mode, welcher das Passwort bei jedem Start abfragt.

Der existiert nicht mehr, das war bei der OF im PPC. Da es keinen bereits in der Firmware integrierten Kommandointerpreter mehr gibt (der muss bei EFI Macs erst von einem Datenträger nachgeladen werden), könnte man damit ernste Probleme verursachen.
Bei PPC Macs landete man damit direkt am Kommandoprompt von OF, bei EFI und der "spartanischen" Installation mit der bei Macs ausgeliefert wird, käme man damit nur ins Nirvana.

Wieso das, das Passwort wird doch bei einem normalen Start gar nicht abgefragt?

Falsch. Das funktioniert so ähnlich wie bei den automatischen Benutzerlogins - die Kennwortfrage wird immer gestellt, aber sie wird ganz von alleine durch den gespeicherten Wert beantwortet. Geht das nicht, hängt die Firmware fest.
Durch den Druck einer beliebigen "Snag" Taste beim Start wird der automatischen Antwort auf die Kennwortfrage ein weiteres Byte hinzugefügt, was eine "Fehleingabe" bedeutet - dadurch landest du beim Eingabeprompt. Schreibst du einen illegalen Wert in die Kennwortvariable, führt das ggf. ebenfalls zu ständigen "Fehleingaben", und schon kommst du aus dieser Schleife nie wieder raus. "Bazinga!"

Im Gegensatz dazu ist zb. bei "Kennwörter zurücksetzen" explizit und natürlich berechtigterweise ne Sperre eingebaut, welche das Programm nur von der Install-DVD starten lässt.

Es gibt einen einfachen Grund warum dieser CD/DVD Test mittlerweile fallengelassen wurde - such diese DVD mal im Karton eines MB Air. So sieht die Zukunft aus.

Wie ist es zu erklären, dass für Tiger sogar offiziell noch der Weg mit dem kopieren beschrieben wird?

Die mit den meisten der frühen "Hybrid" Tiger DVD ausgelieferten Versionen waren (trotz EFI-Kompatibilität) noch unter Rosetta laufende PPC-Binaries. Aber - da ist gar kein lauffähiges Rosetta mit drauf auf der DVD. (Darum war das dort im Menü der DVD gar nicht wählbar.)

Wobei es doch sicher nicht so schwierig sein dürfte, in dem Programm den String als ASCII zu behandeln, und nur Zahlen und Buchstaben zuzulassen?

Das Programm nimmt eine Prüfung vor, ja. Aber verlass dich nicht drauf dass das in allen möglichen Situationen das richtige Ergebnis erbringt. Das ist "unsupported use", und im Problemfall wird daher der Gang zur Werkstatt grundsätzlich kostenpflichtig.
Und solche kleinen Tools sind bei Systemupdates sicher nicht das, was am besten ausgetestet wird - man kann eher froh sein, wenn überhaupt...

Ich kann mir zumindest keine Systemerweiterung vorstellen, die einen 7-Bit-Vergleich z.B. mit 'a' oder 'z' entsprechend manipulieren würde.

Der Teufel steckt in vielen Details. Nicht mal das nvram-Kommando selbst ist wirklich wasserdicht gestrickt.
Frage ich damit zB die Chassis-Nummer meines alten Mini ab, bekomme ich folgende Antwort:

nvram -p
(....)
platform-uuid	....%cb[COLOR="blue"]%b0f[/COLOR]%81
(....)

Siehe da, ein mirakulöses Byte mit 12 Bits...?
Richtigerweise müsste dort stehen:

platform-uuid ....%cb%b0%66%81

Man sieht: Das Programm interpretiert einfach *eigenmächtig* Binärdaten als ASCII-Text.
Schürt das etwa Vertrauen? Bei mir nicht. Solche "Lappalien" sind bei kennwortbezogenen Routinen absolut mörderische Killerbugs. Tritt ein vergleichbarer Fehler auch beim Schreiben einer Variable auf, dann wars das. "Bazinga!"

Wenigstens kann man sich auch ohne Install-DVD behelfen, wenn man noch ne funktionierende Konsole hat.

Eine funktionierende rEFIt Installation auf einem beliebigen Datenträger tuts zur Not auch - falls es daran hakt.

 

[naich]

Falsch. Das funktioniert so ähnlich wie bei den automatischen Benutzerlogins - die Kennwortfrage wird immer gestellt, aber sie wird ganz von alleine durch den gespeicherten Wert beantwortet. Geht das nicht, hängt die Firmware fest.
Durch den Druck einer beliebigen "Snag" Taste beim Start wird der automatischen Antwort auf die Kennwortfrage ein weiteres Byte hinzugefügt, was eine "Fehleingabe" bedeutet...

Das klingt mir aber ganz und gar nicht nach "sauberer Programmierung". Aber es wird sicherlich Gründe dafür geben, wieso es genau so gemacht wird.

Die mit den meisten der frühen "Hybrid" Tiger DVD ausgelieferten Versionen waren (trotz EFI-Kompatibilität) noch unter Rosetta laufende PPC-Binaries. Aber - da ist gar kein lauffähiges Rosetta mit drauf auf der DVD. (Darum war das dort im Menü der DVD gar nicht wählbar.)

Das heißt deine geschilderten Probleme könnten genauso auch bei Tiger auftreten. Dann ist zu hoffen, dass damals Apple das Programm intensiver getestet hat...

Schürt das etwa Vertrauen? Bei mir nicht. Solche "Lappalien" sind bei kennwortbezogenen Routinen absolut mörderische Killerbugs. Tritt ein vergleichbarer Fehler auch beim Schreiben einer Variable auf, dann wars das. "Bazinga!"

Ja, klar, Bugs können immer in der Software enthalten sein - auch auf der Software die auf DVD gepresst ist.
Einziger Unterschied, dass auf der HD die verwendeten Bibliotheken / Frameworks sicher schon mehrfach geupdated / geändert wurden. Wenn du meinst dass das die Fehlerrate signifikant erhöhen könnte, dann glaub ich dir das mal.