Another Mac OS X ScreenSaver Security Issue (after Security Update 2003-07-14)

[Patrick Haruksteiner]

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

[Doug White]

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!

You should really report this to Ambrosia, and ask for a feature that
inhibits the kill functionality for specific applications.

[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.

-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 Doug White

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

[MightyE]

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

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

[Barry Fitzgerald]

Post by MightyE
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]

Post by MightyE
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.

Post by MightyE
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.

[MightyE]

Post by David Riley
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.

Yes, this would certainly be pretty sad, but as I see it, the
screensaver is one of the most important local (non remote) security
devices, it protects against casual cracking attempts of using a
restricted application that was left running when someone was called
away from their desk. Although a root expoit on the screensaver would
be worse than merely crashing the screensaver, neither are tolerable if
you ask me, so may as well stress test the screensaver engine till you
can rely on it, then trust it with root access.

Post by David Riley
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.

A developer could add a --PERMIT_KILL option while testing their
screensaver which would tell Escape Pod that it's ok to kill this
process when the request came in. Also if they had a remote terminal
up, and root access, they could always kill it that way. As I see it, a
user really needs to be able to depend on their screensaver to protect
their workstation while they're not at it. A person doesn't necessarily
have the option of logging out of their workstation completely when they
go away from their desk, nor the time to take other security steps.

It's true that someone having physical access to your machine (and a
desire to use such access for evil) gives them a level of control that
can't be truly protected against with a screensaver of any calibre, but
it does protect the payroll manager from having one of his lackeys give
himself a pay raise while he's at a meeting.

-e

[Mark Tinberg]

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.