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

[Patrick Haruksteiner]

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

[mns]

On Wednesday, July 30, 2003, at 04:56 PM, Patrick Haruksteiner wrote:

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

I agree with Doug White in the assessment that this is, in fact, an
issue
that is the responsibility of Ambrosia, if it is to be considered a
security
issue at all. Apple cannot be held responsible for the code of third
party
developers.

I downplay the definition of this as a security issue at all because
there are
so many immediate workarounds. One is not running or installing Escape
Pod
in the first place. Another is simply logging out when you leave your
workstation,
rather than relying on ScreenSaverEngine for your security. Bottom line,
there are more direct and more threatening exploits that are available
to
people who happen upon an OS X machine unattended. Allow me to describe
a couple of them:

1) If a user finds a machine unattended, whether running
ScreenSaverEngine
or not, and regardless of the presence of Escape Pod on said machine,
the
machine can be booted from an OS X installation CDROM, at which point
the
"Reset Password" option can be used to change root access to the
machine,
which allows the user to log in as root, then change the password for
any account,
including whatever account was initially running ScreenSaverEngine.
Data can
then be removed or overwritten at said user's discretion.

2) If an unattended machine is discovered, it can also be powered
down, and
carried off, physically, without regard to the presence of
ScreenSaverEngine
or Escape Pod.

Do these constitute security threats or exploits that are Apple's
responsibility
to protect against? Of course not. Both are common sense examples of
how many
security measures can be circumvented using simple, direct techniques.
Neither
implies that anyone at Apple should be recoding the operating system,
or any of
it's underlying core technologies in order to prevent them from being
used.

Beispiel: If the rightful user/administrator of any given OS X machine
were to install
the following shell script, how would it be Apple's responsibility to
prevent this?

#!/bin/sh
while true
do
killall ScreenSaverEngine
sleep 60
done


-
m a t t h e w n . s h a r p
mns(at)mnslab.com

[Gavin Hanover]

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

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

: I agree with Doug White in the assessment that this is, in fact, an
: issue
: that is the responsibility of Ambrosia, if it is to be considered a
: security
: issue at all. Apple cannot be held responsible for the code of
third
: party
: developers.
:
: I downplay the definition of this as a security issue at all
because
: there are
: so many immediate workarounds. One is not running or installing
Escape
: Pod
: in the first place. Another is simply logging out when you leave
your
: workstation,
: rather than relying on ScreenSaverEngine for your security. Bottom
line,
: there are more direct and more threatening exploits that are
available
: to
: people who happen upon an OS X machine unattended. Allow me to
describe
: a couple of them:
:
: 1) If a user finds a machine unattended, whether running
: ScreenSaverEngine
: or not, and regardless of the presence of Escape Pod on said
machine,
: the
: machine can be booted from an OS X installation CDROM, at which
point
: the
: "Reset Password" option can be used to change root access to the
: machine,
: which allows the user to log in as root, then change the password
for
: any account,
: including whatever account was initially running ScreenSaverEngine.
: Data can
: then be removed or overwritten at said user's discretion.
:
: 2) If an unattended machine is discovered, it can also be powered
: down, and
: carried off, physically, without regard to the presence of
: ScreenSaverEngine
: or Escape Pod.
:
: Do these constitute security threats or exploits that are Apple's
: responsibility
: to protect against? Of course not. Both are common sense examples
of
: how many
: security measures can be circumvented using simple, direct
techniques.
: Neither
: implies that anyone at Apple should be recoding the operating
system,
: or any of
: it's underlying core technologies in order to prevent them from
being
: used.
:
: Beispiel: If the rightful user/administrator of any given OS X
machine
: were to install
: the following shell script, how would it be Apple's responsibility
to
: prevent this?
:
: #!/bin/sh
: while true
: do
: killall ScreenSaverEngine
: sleep 60
: done
:
:
: -
: m a t t h e w n . s h a r p
: mns(at)mnslab.com

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBPylpHDJ2eyFxcwE8EQJicwCgnSYRGSUNTfNMAV0iou93BB dp7igAoNqQ
H3kwAEa039HOvQw6E3TnIZ+B
=qfb3
-----END PGP SIGNATURE-----

[CHRIS GRABENSTEIN]

That's not really allowing another program to bind the keys. In the =
case of
the Netware client, Microsoft's GINA is completely replaced by the =
NWGINA
which handles the authentication at that point. It doesn't simply =
bypass
MS's GINA unless I'm incredibly misinformed. A malicious user can =
certainly
write their own GINA, but I don't think that's on the same level as =
simply
remapping some keys. I also don't believe you can have multiple GINAs =
in use
at once.

|-----Original Message-----
|From: Brian Eckman [mailto:eckman@umn.edu]=20
|Sent: Thursday, July 31, 2003 4:08 PM
|To: Gavin Hanover; bugtraq@securityfocus.com
|Subject: Re: Another Mac OS X ScreenSaver Security Issue=20
|(after Security Update 2003-07-14)
|
|
|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.
<snip>=20
|> Gavin
|
|
|Windows does allow others to bind to those hotkeys. The Novell=20
|client is=20
|a good example. The Novell NDS password can be used to unlock=20
|the screen=20
|saver, without requiring the Windows password to be entered. Obviously=20
|other programs could bypass the Windows authentication as well.
|
|Brian
|--=20
|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."
|
|

[Fred Noltie]

From: "Brian Eckman" <eckman@umn.edu>

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

It's been a few years and things may have changed, but in the past
Novell accomplished this by replacing the standard msgina.dll with one
of their own making. Microsoft provides information on how to do this
sort of thing:

http://support.microsoft.com/default...b;en-us;810756

FWIW, there is even a GNU replacement (well, for NT, anyway):

http://wwwthep.physik.uni-mainz.de/~...09/readme.html

It seems to me, though, that if the admin replaces Microsoft's GINA, he
can't complain about how (or whether) the replacement traps
Ctrl+Alt+Del. I don't think (though I may be mistaken) that there's a
way to trap those hotkeys when Microsoft's msgina.dll is in place and
working properly.

Regards,

Fred Noltie