Discussion:
Another Mac OS X ScreenSaver Security Issue (after Security
(too old to reply)
Patrick Haruksteiner
2003-07-30 16:43:39 UTC
Permalink
Hi there!

I discoverd another security issue with the Mac OS X screensaver.
If you have installed escapepod from Ambrosia Software and hit
crtl-alt-delete(==backspace) when the screensaver with password
protection is running, it kills the screensaver and the desktop is
open to anybody - so it has the same effect as the recently
emerged password-exploit.
I expected that there should be a forced logout, if the screensaver
dies... - but there is no such behavior...

I have allready reported this to product-***@apple.com, but
as usual with no reply...

Tested on this System Configuration:

Mac OS X 10.2.6 with Security Update 2003-07-14
1GB RAM
1GHZ PowerBook G4
escapepod 1.0.0d3 from http://www.ambrosiasw.com/utilities/
freebies/


--

/harp
Rizwan Jiwan
2003-07-31 18:21:51 UTC
Permalink
I wouldn't consider this a bug. It is like me writing a script that kills
any process named "ScreenSaverEngine". If I run it with my privileges it
should allow me to kill the process (assuming I own ScreenSaverEngine).
Escape Pod does what it is meant to. OS X does what it is meant to--that is
unless you are suggesting that the operating system not allow the user to
kill the screen saver process which is just stupid because I have had my
screen saver crash on me.

-Riz

-----Original Message-----
From: Patrick Haruksteiner [mailto:***@gmx.at]
Sent: Wednesday, July 30, 2003 4:56 PM
To: Doug White
Subject: Re: Another Mac OS X ScreenSaver Security Issue (after Security
Update 2003-07-14)
Post by Patrick Haruksteiner
I discoverd another security issue with the Mac OS X screensaver.
If you have installed escapepod from Ambrosia Software and hit
crtl-alt-delete(==backspace) when the screensaver with password
protection is running, it kills the screensaver and the desktop is
open to anybody - so it has the same effect as the recently
emerged password-exploit.
This is not a bug in Apple software. This is a third party extension.
Ambrosia's Escape Pod is a utility that kills the frontmost app when
the
shortcut keystroke is typed. Naturally it does not ship with MacOS X.
Since the screen saver is just another application (called
ScreenSaverEngine), if you hit the kill key when its running, it gets
killed. Fancy that!
I know that! But it should be the concern of the OS that you cannot
circumvent its security system with the help of other applications!


--
harp
Alaric B Snell
2003-07-31 18:41:33 UTC
Permalink
Post by Rizwan Jiwan
I wouldn't consider this a bug. It is like me writing a script that kills
any process named "ScreenSaverEngine". If I run it with my privileges it
should allow me to kill the process (assuming I own ScreenSaverEngine).
Escape Pod does what it is meant to. OS X does what it is meant to--that is
unless you are suggesting that the operating system not allow the user to
kill the screen saver process which is just stupid because I have had my
screen saver crash on me.
Yes. But either way, it looks as if a side effect of Escape Pod is that
it nullifies the security of the screen saver.

It sounds like the real issue is that the screensaver - which is meant
to lock the keyboard, mouse, and display device to prevent tampering by
passers-by (who do not have the option of taking the machine home and
mounting the disk in another machine et al). The flaw seems to be in
that the OS is still passing keyboard events to the likes of Escape Pod
when the screensaver has asked to lock the keyboard. Maybe it's the
screen saver's fault, in that it's not properly locking the keyboard,
but it's more likely to be that the code in the GUI that handles locking
the console should disable 'hotkey' processing too.
Post by Rizwan Jiwan
-Riz
ABS
Brian Eckman
2003-07-31 20:29:34 UTC
Permalink
I don't quite agree. Windows uses control-alt-delete as a security
device. It binds those keys as a hotkey in such a way that no other
aplication can replace it. This is why it is used at logon; it
prevents a user from creating a program that looked like a logon
prompt, and could bind the control-alt-delete keys to display a
password prompt. (pressing control-alt-delete in any application
other than the logon screen would display the "shutdown/logoff/task
manager" window, at which point you would know not to enter your
password in any prompt)
If someone were to find a way to bind to those hotkeys, would you
then consider this a security issue with Windows? If so, how is
Apple's failure to block kill calls to the screen saver not a
security issue?
Gavin
Windows does allow others to bind to those hotkeys. The Novell client is
a good example. The Novell NDS password can be used to unlock the screen
saver, without requiring the Windows password to be entered. Obviously
other programs could bypass the Windows authentication as well.

Brian
--
Brian Eckman
Security Analyst
OIT Security and Assurance
University of Minnesota
612-626-7737

"There are 10 types of people in this world. Those who
understand binary and those who don't."
Barry Fitzgerald
2003-07-31 20:32:53 UTC
Permalink
If anything I'd call this a security consideration of Escape Pod.
Perhaps Escape Pod should try to talk to the process it's about to
kill, and get its 'permission' for killing, and failing a timely
response (2 secs?), drop the program. ScreenSaverEngine would have to
be tailored to respond to such a request.
On Linux, doesn't xscreensaver run as root? Wouldn't this be another
option here (I'm admittedly unfamiliar with Mac OS X), preventing
Escape Pod from even being capable of terminating the screensaver
process? Or does Escape Pod also run as root?
If you ask me, Escape Pod owes it to their users to develop the
product in such a way so to not nullify reasonable security measures
on the part of the OS, even if that's an option to never terminate
processes named ScreenSaverEngine.
-MightyE
You read my mind on this one. However, one of the complaints I've heard
about having xscreensaver as a SUID root binary is that an exploitable
vulnerability (buffer overflow, et al) in the xscreensaver binary could
allow an attacker even greater elevated priviledges (much worse than
simply killing ScreenSaverEngine)... a solution to this would be running
the ScreenSaverEngine SUID some other user (like, oh, maybe
"screensaver")... and that should stop a usermode program from killing
the screensaver. Unless, as you mentioned, that usermode program were
running as SUID root - in which case I'd have to ask: Why in the name of
$DEITY are you running a program that can kill any process on the screen
as root?!?

-Barry

p.s. I don't have a Mac OS X system on hand nor do I have access to
one. I have no way to test the plausibility of this solution on that
particular system. :)
David Riley
2003-07-31 22:26:01 UTC
Permalink
If anything I'd call this a security consideration of Escape Pod.
Perhaps Escape Pod should try to talk to the process it's about to kill,
and get its 'permission' for killing, and failing a timely response (2
secs?), drop the program. ScreenSaverEngine would have to be tailored
to respond to such a request.
That would be nice, though I can't really imagine Apple changing a rather
core part of their system architecture for a shareware developer's free
utility (though atmittedly, it is a rather large and important Mac
developer). It would be an interesting standard to set for a number of
platforms, similar to a "watchdog timer" on a number of microcontrollers
and other devices that resets the device if the timer isn't reset withn x
number of cycles, which would indicate a crash.
On Linux, doesn't xscreensaver run as root? Wouldn't this be another
option here (I'm admittedly unfamiliar with Mac OS X), preventing Escape
Pod from even being capable of terminating the screensaver process? Or
does Escape Pod also run as root?
This is a good idea, except for two (and possibly more) problems:

a) If the screensaver engine is compromised (as it was earlier this month,
though likely not in a command-execution sort of way), you don't want to
be able to give the user root privileges. Presumably, xscreensaver has
safeguards against that (or they assume it'll never be exploited). It
would be pretty sad to have a root security hole through the screensaver.

b) Sometimes the screensaver does crash. Keep in mind that since the
screensaver modules are executable code (as xscreensaver modules probably
are as well, though I've never made one), that's the responsibility of the
individual screensaver developer to fix. It's nice to be able to kill it
when it does crash so that you can use the computer again.
Mark Tinberg
2003-08-02 21:59:51 UTC
Permalink
Post by Patrick Haruksteiner
I discoverd another security issue with the Mac OS X screensaver.
If you have installed escapepod from Ambrosia Software and hit
crtl-alt-delete(==backspace) when the screensaver with password
protection is running, it kills the screensaver and the desktop is
open to anybody - so it has the same effect as the recently
emerged password-exploit.
I expected that there should be a forced logout, if the screensaver
dies... - but there is no such behavior...
as usual with no reply...
Mac OS X 10.2.6 with Security Update 2003-07-14
1GB RAM
1GHZ PowerBook G4
escapepod 1.0.0d3 from http://www.ambrosiasw.com/utilities/
freebies/
I'm surprised at all the confusion about this issue from the people on the
list. It seems to me that the responsibility for fixing this problem is
Apple's and that the correct course of action is for the screen lock
utility to block _ALL_ access to keyboard and mouse events for any other
process. When the screenlock is running, it should:

1) Always be on top of other windows. The window manager should not
allow windows to popup over the screensaver, and certainly not allow
them input
2) All input should be bound to the screensaver process, no other other
process should be allowed keyboard/mouse[0] input. Certainly all
hotkeys should be disabled
3) For extra points, in event of failure, system should immediately log
out the console user. It should fail closed if possible, rather than
give away console access in the event of an error.

There are probably a few other responsibilities that a screen lock has
that I can't think of at the moment, but the main thrust is that a screen
lock should enforce security policy within its realm of responsibility.

- --
Mark Tinberg <***@securepipe.com>
Network Security Engineer, SecurePipe Inc.
New Key fingerprint = FAEF 15E4 FEB3 08E8 66D5 A1A1 16EE C5E4 E523 6C67


[0] Or really any HID or ADB device. It might be easier and safer to
just disable everything that isn't a keyboard.

Continue reading on narkive:
Loading...