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

From: David Riley (oscar_at_the-rileys.net)
Date: 07/31/03

  • Next message: ben.moeckel_at_badwebmasters.net: "[bWM#015] SQL-Injection @ Woltlab Burning Board + MOD Guthabenhack 1.3" 
    Date: Thu, 31 Jul 2003 15:53:44 -0400 (EDT)
To: MightyE <trash@mightye.org>

    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.

  • Next message: ben.moeckel_at_badwebmasters.net: "[bWM#015] SQL-Injection @ Woltlab Burning Board + MOD Guthabenhack 1.3"

    Relevant Pages

    • Re: Another Mac OS X ScreenSaver Security Issue (after Security Update 2003-07-14)
      ... If anything I'd call this a security consideration of Escape Pod. ... Pod from even being capable of terminating the screensaver process? ... >> should allow me to kill the process. ...
      (Bugtraq)
    • Re: Another Mac OS X ScreenSaver Security Issue (after Security Update 2003-07-14)
      ... >would be pretty sad to have a root security hole through the screensaver. ... up, and root access, they could always kill it that way. ... it does protect the payroll manager from having one of his lackeys give ...
      (Bugtraq)
    • Re: xhost +localhost
      ... Root should never have a pretty screensaver. ... > Programs like xscreensaver are doing FreeBSD a favor by preventing ... > you will make a mistake while running as root. ...
      (freebsd-questions)
    • Re: How can I allow screensaver unlocking by root?
      ... where the root passwd can unlock any user's screen saver. ... If I am the root passwd owner, I want to be able to get on a machine without having to destroy parts of it. ... How can I allow screensaver unlocking by root? ...
      (Fedora)
    • Lock Screen as root
      ... The "lock screen" operation in FC5 does not actually lock the screen ... When I log in as root, the Screensaver ... But this doesn't work on my FC5 ...
      (Fedora)