Workarounds
By: Richard Glaser - Revised: 2006-06-06 devinIntroduction
On Mac OS X 10.2.8 or early the workaround is replace OR recompile init & modify ttys.
On Mac OS X 10.3.x the workaround is modify ttys.
Replace init
One current workaround until Apple hopefully releases a security update, is replace the vulnerable systems
init with the Mac OS X 10.3
init, located in
/sbin.
Recompile init
Another option if you don't have access to Mac OS X 10.3, is to recompile the init from Mac OS X from the Darwin Source with the -DSECURE flag set. For more details on this option see "
recompiling init" section.
Modify ttys
The next setup is to modify the
ttys file located in the directory
/etc.
First, backup the ttys file with command:
cp ttys ttys_backup
Next, open the ttys file in a text editor like unix editors like vi, emacs, etc or GUI editors like BBEdit. Note, if you must use pico use it option
pico -w <filename> and double check for hard wraps.
Remove "secure" from the following section of the ttys file and save.
console "/System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow" vt100 on secure window=/System/Library/CoreServices/WindowServer onoption="/usr/libexec/getty std.9600"
Test Workaround
Next reboot the Mac & test if workaround worked properly. If is worked, you will be prompted for a root password similar to the following:
Enter root password, or ^D to go multi-user
Password:
If you don't have a root enabled, you can continue the boot process by pressing CONTROL+D.
Root Password
Since DirectoryServices is not running by the time we enter single-user mode. The init will ask for the non-shadow crypt password stored for root in:
/etc/master.passwd
Non-Admin users shouldn't have read access to this file, but if you are really paranoid, you might consider changing the password to something very secure & then keeping root disabled. You should be able to do all you need to do to administrate a Mac using the
sudo command and enabling root really isn't needed.
Note - This step is completely optional & is not necessary as a workaround to the exploit documented here.