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
This was fixed July 16, 2002. Old news. Move along.
(It wasn't even that bad of a vulnerability, as it required end-user cooperation to exploit and also excellent timing/sustained penetration of the target network (software update runs once a week by default-- you need to guess when to arpspoof/dnsspoof properly. Still, it's not a good thing, and Apple fixed it promptly).
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;
But in X at least on slackware when the screensaver is on I can Ctrl-Alt-F1 and Ctrl-X to kill X windows and get myself to prompt.
Unless you're using xdm/kdm/gdm, which will automatically start X without you logging into the console first. If you kill X, it'll just restart X for you, and give you a graphical login prompt.
$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.
I was able to reproduce it on my Powerbook. Here is the crash log.
/Users/jonathan/Library/Logs/CrashReporter/ScreenS averEngine.crash.log
2003-07-05 23:25:41.258 ScreenSaverEngine[9993] Exception raised during posting of notification. Ignored. exception: *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0) Jul 6 00:10:42 localhost crashdump: Crash report written to:
-You may license this sig for only $6.99.
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.
Any host that can ask for a login window on the machine can then use the buffer overflow exploit to potentially pass executable code to the server, to be executed as root.
Time to check your Xaccess file and make sure it doesn't allow any remote hosts, whether by query or broadcast.
Dude, none of this pertains to Mac OS X. There is no way for any other host to "ask for a login window" on a mac OS X host.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."