Thread: Security issue
View Single Post
Old 01-21-2009, 06:06 PM   #49
rps
Registered
 
Join Date: Oct 2008

Posts: 57
I understood it. What Dale is saying is, that if Edgar's approach to solving the security to hole is to "hide" it, by writing a file somewhere that the [typical] user isn't likely to find, that isn't really an acceptable solution.

Here's the thing: if "require a password" is enabled for a screen saver, then Windows creates a dedicated session for the screen saver to run in. This session has some default userID (call it the "null user" if you will), and the screen saver, plus any applications launched by the screen saver, will run in this session. In XP, when the screen saver terminates, the null user's session terminates immediately, killing any other processes that might still be running. (Such as the internet browser that is now trying to go to the Serene Screen website.) In Vista, the null user's session continues to run until ALL processes in the session have ended. If UAC is enabled, then the null user will only have access to those things that Everyone can access. In either case, the password to return to "unlock the computer" does appear until *after* the null session terminates. Everything that I've described so far is what Windows imposes, and which you have no choice about.

Now, how to deal with this? Here's the problem, you have to keep in mind that if you're in the null session, you aren't really supposed to have access to the rest of the computer. (You might, if UAC is disabled, but you can't count on that.) Which means that even if you get to the website, you won't be able to download an update. And there's no way to close the screen saver and launch the browser *after* the user has logged back in, because that would require an application in one user session (the null session) launching an application in another user session (the original user). Can you imagine the potential for viruses if that were actually possible?

Which brings me back to: if the owner of the computer specified that the screen saver should run in a secured (null) session, then really, the screen saver is the *only* thing that should run in that session. (Ever.) And therefore, launching a browser to go to the Serene Screen website shouldn't be allowed. (Unless it was a custom browser that *only* allowed you to visit the Serene Screen site, and *nothing* else, but I think we dismissed that already...) From a security standpoint, I still think the right answer (and the easiest to implement) is to see if: (a) the program was launched in screen saver mode, and (b) if so, is it running in a null session. If both (a) and (b) are true, then disable (or hide) the website button. Remember that users can access the website button by viewing the list of screensavers and accessing the properties dialog for the MA3 screen saver. Or by clicking on the desktop icon to launch the program manually (in non-screensaver mode). [The install program *will* offer to put an icon on the desktop, right?]

Bear in mind that most dedicated screen savers terminate as soon as any key is pressed or the mouse is moved. The fact that MA3 allows you to access the properties dialog from an active screen saver, makes it somewhat unconventional.

~Ralph S.
rps is offline   Reply With Quote