[rytc]

I just discovered today that an OSX system running SETI is basically completely unsecured. SETI can be allowed to run as screensaver. When logged out and the computer is at the login screen, the SETI screensaver will launch and run behind the login screen. It is run as a process belonging to root, regardless of whether root account is turned on or not. By clicking on the SETI window you can access the Apple menu and open up the System Preferences, going to accounts reveals that the system considers you to be logged in as the root user. This basically gives you complete control of the system. As an example using the Accountpanes I went in and changed the passwords for all accounts that were set up on this system. I was then able to login to all these accounts using the new password. Whilst this would appear to be a 'feature' of ow SETI has been written, it suggests that this is a flaw in the way process running while the computer is the at the login screen are handled.
Try it....
This is under Panther 10.3.3. with all the latest updates.

Cheers Ry

[yukon]

If you run something as root, you have to trust it will be safe. Anything run as root can do anything, that's accepted. This isn't a remote exploit from what I can see (read: it isn't remotely exploitable, at least this specific problem), it's no less secure than the "classic" macos (without multiuser OS9) or most windows systems, but it is still a big problem for physical security.

This is NOT necessarily an OS X vulnerability. This is a problem with the SETI client, where it grants it's root privs when it shouldn't, running as root when it shouldn't run accessably, or especially shouldn't even be root. This could also be a problem where GUI programs assume you are root when coming from programs running as root (which should be impossible without access to the root account), but that's more of a general security issue, like password hints or such. Seems like a feature of the OS, no constant authentication, but there should be an option to turn it off.

Good find, SETI needs to be fixed. Just making sure we don't get another "OS X has an MP3 TROJAN!" type problem

[Gee4orce]

Use the SETI command line client - it will run transparently in the background all the time, and if you renice it it'll only use CPU time when you're not doing anything else.

[Xeo]

Originally posted by yukon:
This is NOT necessarily an OS X vulnerability. This is a problem with the SETI client, where it grants it's root privs when it shouldn't, running as root when it shouldn't run accessably, or especially shouldn't even be root.

I'm not big on screensavers, so I'm not sure about this, but if any screensaver will activate at the login screen, then this isn't a problem with SETI or OS X but both. OS X is the one giving root privileges to screensavers. That's because the login window is controlled by the root user. It should be that login window is run by an unprivileged user, and therefore all processes, including screensavers, would be run by the same unprivileged user. That would make everything more secure. The alternative is for SETI to not release an interactive screensaver. Screensavers aren't supposed to have windows and whatnot. They are supposed to quit when activity is detected. So both OS X and SETI are at fault.

Unless SETI goes out of it's way to run the screensaver at the login window. I can't remember if screensavers will normally run at the login window or not.

Either way, I think Apple should take care to run more things as unprivileged users rather than defaulting to root.

[Basilisk]

Unless SETI goes out of it's way to run the screensaver at the login window. I can't remember if screensavers will normally run at the login window or not.

Normal screensavers won't run. The standard OS X screensavers are plugins to the ScreenSaver.engine framework which:

- Is started by the WindowServer on demand in user sessions only (never at login window).
- In 10.3 uses the authentication framework before unlocking.
- Isn't a standard GUI application (no menubar, etc.).

I don't use SETI, but based on the description of the problem and what I gather from their release notes:

- The SETI screensaver isn't a ScreenSaverEngine plugin, its a standalone app.
- The screensaver is started by a StartupItem (meaning it runs as root, just like any other service or daemon). Its _not_ LoginWindow starting the screensaver, its SETI's own StartupItem.
- They are running a full-blown GUI application from a StartupItem, which is a bad idea in general.
- They are running a GUI app as root without taking appropriate internal precautions (like switching the SystemUIMode to prevent access to the Apple menu).

In short, its their fault, and they are doing things known to be a bad idea. I presume they do this to allow the screensaver to run over the LoginWindow so that they can do their processing on idle machines.

Alex

[rytc]

It would seem that SETI has two screensaver modes, when logged it it takes over the whole screen and disappears on activity, at login screen it starts up as the actual app which can be selected and manipulated as you would if logged in. Definately needs a rewrite.

[ginoledesma]

This is a design "flaw" of SETI, and not Mac OS X itself. The nature of Unix-based systems is such that those running as privileged users (root, wheel, etc) have access to the system. That's why you frequently hear of buffer overflow exploits, in the hope that an application running as a privileged user that is exploited allows you access to the system when the program dies (and pressumably dumps you to the shell).

The "simple fix" could be that the SETI Team can change the behaviour of their application to run as setuid to a different, unprivileged user. This is common behaviour in several "exploit-magnet" apps like BIND named (the DNS server). If they're even more paranoid, they can have the app jail (chroot) itself to a particular directory, so the client makes sure that it only sees what it needs to see.

[malvolio]

Originally posted by Gee4orce:
Use the SETI command line client - it will run transparently in the background all the time, and if you renice it it'll only use CPU time when you're not doing anything else.

Excellent advice. This is exactly how I run SETI@home.

[Kenneth]

I grabbed the CLI version from the UCB site.
I then use SETIdockling to manage my working unit. It handles very well on my dual G4. I just leave it on all the time.