Screensaver Bug in Mac OS X
dave1212 writes "Still too early to tell, but there seems to be a screen saver password exploit in Mac OS X. It was discovered and postedon the Full Disclosure list earlier today. Theories, personal tests, and rumours abound, with some success stories, and the possibility that it could affect all Cocoa programs. Speculation points toward a 2048 character buffer, with people using the emacs shortcuts Ctrl-K and Ctrl-Y to fill the text field in under half a minute."
I was the one that posted about the address bar in Safari. I am using 10.2.6. This is a problem for ALL cocoa apps.
It'll probably be trivial for Apple to fix, though. So I'm just waiting for the patch to arrive.
*taps finger on desk*
First of all, the ctl-k ctl-y macros work in just about any Cocoa field. I pointed that out earlier on macslash. What I also pointed out was that this bug will crash just about every Cocoa app with a text field. I've crashed the login panel with it. It's not pretty. I really hope apple takes heed to this bug and fixes it at the core. Unfortunately the original bug report was.... well... not too elegantly written. We'll see what happens.
In the meantime security savvy users should logout rather than trust the screen saver and use an Open Firmware password on their machine. That way you prevent people from logging in using single user mode. Hit command+O+F during boot to get into open firmware, then type in password. After that type reset-all. You should be good to go. And don't forget the password or you will be totally screwed!
100% Crunchier
I just pasted about 2.7MB of text into Safari's address bar, and it didn't crash at all. I pressed return, and it attempted to load the page; Squid aborted the connection but Safari's still trying to load it. I'm typing this in another Safari window. No problems. Process Viewer shows Safari is using 25% of my RAM.
This will probably make a pretty ugly entry in ~/Library/Safari/History.plist.
I also tried crashing the screen saver login window. It hung with the SPOD trying to manage that much data being pasted all at once, but it did not crash. After several minutes, I killed the processes remotely, but even killing the process did not return me to the desktop - I just got another login prompt, and was able to log in.
I'm running 10.2.6, the latest available version.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Personal computers and workstations make no attempt to be secure against physical access. I just changed two Mac OS X root passwords so I could create an account for myself on some pc's last week. I'm not a regular mac user, I just did a google search and found three or four ways to do it, the easiest was to just boot into single user mode, turn on the standard password authentication mechanism, and then type passwd... I've never met a Sun workstation that didn't give you fully fledged debug console at Meta-A.. Lilo lets you enter single user mode with just a kernel parameter to linux... You can overwrite the password files in Windows, etc.
You could encrypt the root filesystem, then on boot authenticate the machine (to make sure someone didn't just clone the startup to harvest your decryption key) and then enter the decryption key based on a one time response from the computer. That level of paranoia would justify caring about this "exploit." Even so someone could just install a sniffer inside the computer since our hardware is not hardened in the least.
The buffer exploit is a Quartz problem, and entirely local.
There is an X implementation for OSX - it runs on Quartz, like Exceed or CygX run on Win GDI. It may be possible to send events to Quartz via the Aplle X server - but this is not shipped by Apple as a production code, and won't be until Panther. That is several months and many bug-fixes away!
"Flyin' in just a sweet place,
Never been known to fail..."
You could always set an Open Firmware Password, if you're afraid of people rebooting your system to exploit it.