| Date: | August 25, 2006 / year-entry #290 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20060825-17/?p=29963 |
| Comments: | 25 |
| Summary: | I remember a question from somebody who asked, paraphrasing: We're writing a secure screen saver that the user can interact with. We're going to present the user with various types of information, and if they click on a hot link, we want to launch a web page on their desktop once the user unlocks the... |
I remember a question from somebody who asked, paraphrasing:
Apparently these people didn't get the memo on security. Windows tries to make it hard for you to do this to a secure screen saver. The restrictions on secure screen savers have gotten tighter over time. Originally, secure screen savers were isolated by putting them on a separate desktop. Nowadays, Windows also runs the secure screen saver in a job object, and when the user unlocks the workstation, all processes in the job are forcibly terminated. Even if you came up with some sort of workaround for this, it's entirely possible that your workaround will be treated as a security hole and rendered ineffective in a future version of Windows. Suppose you find yourself some workaround and are willing to concede that your technique is living on borrowed time. It's still a bad idea. One of the aspects of security that doesn't get much attention is repudiation. Responding to the user's actions from a secure screen saver to do anything other than unlock the workstation gives the user plausible deniability. "Yes, I know it's on your auditing logs, but I assure you, I didn't click on that link. When I came back from the printer room and unlocked my workstation, this web site appeared. It must have been somebody who wandered into my office." If your screen saver does anything nontrivial, it becomes something the user can plausibly deny, because any random person walking by could have done it. You have an untrackable and unattributable action. Network security administrators really get the heebie-jeebies when you say "untrackable and unattributable action". I'm told that when people ask for this sort of "interactive secure screen saver", they typically have some sort of process control program that they want always to be available. The thing is, if you're going to trust random passers-by with your control program, then you have basically decided that your computer's physical security is already assured. In that case, you may as well create a special account, configure the computer to auto-logon with that account, and put the control program in the special account's startup group. Just run the program like normal. Don't try to pretend that wrapping it inside a "secure screen saver" accomplishes anything. Sidebar: While the rules for secure screen savers have gotten tighter over time, the rules for insecure screen savers have gotten more and more relaxed. Insecure screen savers are run on the user's desktop so that they can do the sorts of funny things that they got away with on Windows 95 such as taking a snapshot of the user's screen and using it as the basis for a jigsaw puzzle that it animated. Windows used to kill insecure screen savers as soon as the user touched a key or moved the mouse, but that behavior was disabled in order to allow people to write "interactive screen savers". (Remember PointCast?) Some people might argue that allowing insecure screen savers to interact with the user was a bad idea. (Yes, Internet Explorer at one point had a screen saver that did something like this. I'm told that in follow-up surveys, no customers actually admitted to liking the feature.) |
Comments (25)
Comments are closed. |
How do you create a "secure screen saver?" I checked Google for the phrase, but couldn’t find anything except a WinLogon constant and a bunch of articles talking about the C# starter kit.
I’m curious what the distinctions are, so if you could enlighten me that would be great.
Bjorn, you don’t, the system does. It’s a property of how the screen saver is run, not of how it is written. As soon as the user password-protects the screen saver, it will be run in "secure" mode
Prevent a secure screensaver from doing this may be problematic. The user has to be a willing accomplice, but if they want a secure screensaver to be able to open a web site or start processes outside the job object, all they have to do is have a process running before the screensaver starts. The screensaver can then proxy whatever commands it needs to that running helper process by any number of methods, a shared file, windows message, named pipe, shared memory, … Cutting off every avenue that the helper application might use sounds like a big job and would end up crippling the screensaver. And maybe that’s not such a bad idea – if you really want a secure screen saver.
Q: We know it’s insecure, but we want to do it anyway.
A: OK.
Q: … so how do I do it?
A: You don’t.
Q: … but I want to!
A: I know you want to do it, but you can’t anyway.
Actually, I just came up with the idea of invoking a program as a screensaver. In order to make a program that runs securely by default, you have to create a low-privilege account, make it login by default, lock it down, make it run your program, and put a wrapper around it so that it can restart automatically if it exits for any reason. And then you still have to deal with avoiding all the crap that Windows likes to pop up on top of your window.
If you just make your program the screensaver for the .DEFAULT hive (and set the timeout to something low, like 1 second), it will run automatically. You don’t have to create an account for it, figure out how to lock it down, try to avoid pop-ups, or anything else. The only configuration it requires is changing a single registry key.
It even has the advantage of allowing you to remotely access your kiosk via RDP without having to disturb the person viewing it.
"We know it’s insecure, but we want to do it anyway"
Now that’s a scarey statement. Surely the team shouldn’t need to read security memo’s to be responsible. Naughty people. I didn’t even know that I might want an interactive screen-saver fabulous the un-forseen needs that are being planned for.
Setting a password on my screen-saver is a clear, understandable act requesting security. I’ll wait the few minutes to log-in for interactivity for what-ever they think I’ll need…. is this a case of enthusiastic over-engineering by a team that love fiddling with their feature? Oh my.
Back in the days of 98 i worked for an multimedia advertising company and the interactive screensaver was quite a common gimmick.
Marketing speech: Make it so, that the user can click here and there and it opens the browser on that particular URL. The user wants it (though nobody seems to have actually asked the enduser).
We ended up with an agent app that was installed with the screensaver that provided reminder services and sat in the taskbar. The screensaver would write the URL into a file and closed itself. The agent checked for the file in intervals and then started up the browser. Eeeeew!
Security measurements weren’t really a important part of the decision.
Just from the title …. "Allow Service to Interact with Desktop"
How can I tell whether my screen saver is one that runs on a separate desktop?
On Windows 2000 and up (XP, 2003) "secure" vs. "non-secure" in this case refers to whether you enable the "on resume, password protect" setting. With that setting enabled, the screen saver will run in a separate job on a separate "screen-saver" desktop with no [direct] access to the applications running on the user’s interactive desktop. When the screen saver exits, any other processes in that job (i.e., directly launched by the screen saver) will be terminated. If the password-protect setting is not enabled, the screen saver runs on the user’s interactive desktop, can take screenshots, etc.
One way to bypass the job restriction is to launch a child process via DCOM or WMI. Processes started this way are not contained within the job object of the parent process.
All that said, I don’t know whether/how Vista changes any of this…
"Secure Screen savers on Vista get away with funny things. The "Bubbles" screen saver keeps all the information on the screen visible."
A similar problem exists in XP – when FUS is enabled, the logged in user’s desktop is visible for a short period of time when resuming from hiberation (or returning to the logon screen in general).
I think you meant ‘unsecure’.
Who actually owns the computer – Microsoft or the end user? If I want to do something silly, foolish and ridiculous on MY PC, then who are Microsoft to say what I can and cannot do? This whole philosophy of ‘protecting the user from themselves’ has become extreme.
Think of it as banning kitchen knives since some people occasionally cut themselves. Insane.
If the user wishes to do something insecure ON THEIR OWN BOX, then by golly, let them.
Then Zenja clicks on the random attachment and whines about "Insecure Windows"
Microsoft cannot win.
Zenja: Then don’t password-protect your screensaver. If you don’t want it secure, you don’t have to HAVE it secure.
Zenja:
"Who actually owns the computer – Microsoft or the end user? If I want to do something silly, foolish and ridiculous on MY PC, then who are Microsoft to say what I can and cannot do? This whole philosophy of ‘protecting the user from themselves’ has become extreme."
Here, let me fix that for you.
Who actually owns the computer – Microsoft or the person who wrote the screensaver I’m using? If someone I haven’t ever met wants to do something silly, foolish and ridiculous on MY PC, then who are Microsoft to say what a potentially malicious person can and cannot do? This whole philosophy of ‘protecting the user from malware’ has become extreme.
Perhaps you see the point?
The problem is that once a malicious actor gets his software on it, he will own your computer, not you. Microsoft’s job is to prevent the malicious ones from owning your computer.
I remember a fun screen saver story from when I was training for Packard Bell tech support (gosh, it’d have to be almost twelve years ago now). The PC running Windows 3.1 went into screen saver while the instructor was talking. It was clear he didn’t know the password. But he did know a trick.
At the password prompt, he pounded on the keyboard for several seconds. Then, when the 486SX was trying to catch up with the keyboard buffer, he hit Ctrl+Alt+Del. Immediately a blue screen popped up: "ssmarque.scr: This program is not responding." Hit Enter and BAM! Back at the desktop.
I suppose moving the password prompt out of the screen saver binary was a good security move…
Well, it’s a bit stupid but "interactive secure screensavers" have their meaning, after all.
Simply and plain: you can write a simple s.saver that let the user do a few things while it is active. Meanwhile, you protect it with a password, so nobody can access to the desktop and do anything else.
In the end, take the PC to that show/fair/whatever, and look people passing by interacting with what has a full application look, but cannot be crippled or bypassed in any way….
from Zenja: "If I want to do something silly, foolish and ridiculous on MY PC, then who are Microsoft to say what I can and cannot do?"
perhaps if you want to to something silly, foolish, and ridiculous on YOUR PC, then I agree, Microsoft has no place telling you not to. But they don’t tell you anything; you’re the one who’s gone out and installed a Microsoft OS. If you want to do something silly, foolish, and ridiculous, maybe you should start by setting up an environment which lets you do silly, foolish, and ridiculous things.
yo wizards, this is offtopic but can someone point me to a good explanation of when to use Addref?
The problem I see, is that naturally MS cannot figure out all perfectly valid ways of using a PC and everytime they block a given scenario with no workarounds, they are crippling a 0.1% of their popoulation.
The fair example is quite good.
A simple screen with 5 radio buttons and a text box for inserting an explanation. A button sends the data to the database (a service running on the same machine). Another button unlocks the screen saver [with password and so on].
Maybe other and better ways exist to kiosk mode the workstation, but this is a plain good way to do it. And if it fails and the disk got formatted and the system corrupted and etc, it’s an isolated single purposed PC which can be reghosted that night.
Is there any definition of what "kiosk mode" should and should not include? Do Windows have any recommended support for it?