Another Mac OS X ScreenSaver Security Issue (after Security

[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-security@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]

On Tue, 29 Jul 2003, Patrick Haruksteiner wrote:

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

--
Doug White | FreeBSD: The Power to Serve
dwhite@gumbysoft.com | www.FreeBSD.org

[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:haruk@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)



On Wednesday, July 30, 2003, at 10:07 h, Doug White wrote:
> On Tue, 29 Jul 2003, Patrick Haruksteiner wrote:
>
>> 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]

Rizwan Jiwan wrote:
> 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.

>
> -Riz
>

ABS

[MightyE]

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

>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

[Brian Eckman]

Gavin Hanover wrote:
> 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]

MightyE wrote:

> 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]

On Thu, 31 Jul 2003, MightyE wrote:

> 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]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 29 Jul 2003, Patrick Haruksteiner wrote:

> 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-security@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/

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 <MTinberg@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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/

iD8DBQE/K3l+Fu7F5OUjbGcRAmeEAJwPwx2A3kXC9aOikXOSfPZ0/Pr2ygCeOf0a
VlGpRBfYTM7/tFO9lVntl9Q=
=cEWK
-----END PGP SIGNATURE-----