| Date: | March 3, 2008 / year-entry #73 |
| Tags: | code |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20080303-00/?p=23243 |
| Comments: | 45 |
| Summary: | Kevin asks, "Windows XP lets me install applications, delete files, etc., so why does scheduling a task requires a password?" (I guess the answer to this question wasn't obvious since nobody answered it in the suggestion box.) Because scheduled tasks run after you have logged off. All those other operations occur while you are logged on.... |
Kevin asks, "Windows XP lets me install applications, delete files, etc., so why does scheduling a task requires a password?" (I guess the answer to this question wasn't obvious since nobody answered it in the suggestion box.) Because scheduled tasks run after you have logged off. All those other operations occur while you are logged on. Your user token has been authenticated with the relevant security authority. The system has confirmed your identity and your permissions and stored them in your user token. But once you log off, your token goes away. Since scheduled tasks can run even if you aren't logged on (that's sort of the point of them after all), the system needs to re-establish your identity and your permissions, because your account may have been deleted or restricted in the meantime. And to do that, you need a password. Scheduled tasks can't use some "just act like I'm that user over there, trust me" magic cookie, because that would be equivalent to a password. |
Comments (45)
Comments are closed. |
The corresponding UNIX daemon (cron) doesn’t seem to have this limitation. So I’m curious why Windows would need the password in order to create a session for a user.
Is it because under certain configurations (encrypted volumes or a windows domain account) it would need it? So instead of asking for it only some of the time it just asks for it all the time?
not to mention a common gotcha of tasks. I see it all too often; user will map a network drive say N: then try to use N: in a scheduled task. They then log off, task runs and fails. This is easily worked around but it isn’t obvious to even most administrators.
BTW, if you select the ‘run only when logged in’, you aren’t required to provide a password.
In general Unix cron doesn’t have this problem because a Unix user ID is just a 16-bit (or 32-bit) integer that crond can set to whatever it wants because it runs as root. If your Unix machine has kerberos, though, you’ll run into the same problem because kerberos doesn’t just let you pretend to be any user you want.
Further question: Why do you have to enter a password twice in scheduled tasks?
To guard against typos. You’re unlikely to typo the password the same way twice.
I imagine it’s to prevent the situation where "really long tedious task I set to run overnight" failed because you mistyped your password. Anywhere there isn’t immediate feedback for a mistyped password it’s a good idea to confirm the password.
There could be immediate feedback. Instead of asking for the password twice, just check it when adding the scheduled task.
One problem I had with scheduled tasks that made me seek out an alternate solution is that they stopped working when I (as a good user) changed my password. It was too much of a headache to then change the password for all the scheduled tasks. When I tried to create a "scheduled tasks account" that would do nothing other than run the scheduled tasks, the GUI for the tasks wouldn’t show up for the logged-in user because it was a different account.
In the end, I found a piece of freeware, System Scheduler, that did what I wanted (behave like win9x scheduled tasks.)
>> you can at least stop it by rebooting the machine
… and removing the Run key and possibly the root kit if you run as admin.
If you run an evil program you have to rebuild the machine. If that evil program can get your password you need to build all you machines.
@whatever:
As far as I know, you never decrypt stored passwords, because it isn’t encryption… it’s hashing. You simply cannot go backwards from hash to password.
Same reason you enter it twice when changing it, I would expect – confirmation.
Sure, but that could slow things down a bit. Especially if you were scheduling a task for a remote machine. It’s not a huge problem, but I’m just saying that immediately checking the password is not necessarily a better solution than just entering the password twice. Just different, and not the solution they decided to go with.
"The corresponding UNIX daemon (cron) doesn’t seem to have this limitation. So I’m curious why Windows would need the password in order to create a session for a user."
Because the UNIX cron runs as root and can pretend to be any user it wants (except when kerberos is used, per Gabe)
Whereas in Windows, not even Local System has the power to masquerade as any user – if it could, then Local System can masquerade as TrustedInstaller and do all sorts of nasty things on Vista.
(We all know LocalSystem has full control of the filesystem and can do anything it wants, but the challenge is to change things as if TrustedInstaller itself changed them)
Also, if the password will be different by the time the task starts (or the account is only enabled at certain times), you can still create the task. Why check something now when you’re clearly talking about a different time?
There’s a much easier way to do this. Tick the "Run only if logged on" tickbox. It then runs in the GUI and doesn’t need your password.
One thing I did never get in similar respect is the shutdown utility, which I am not allowed to run as myself, although I can easily turn of the computer using the start menu…
I don’t want to go off-topic, just mentioning something worth for another article. Since through remote desktop start menu doesn’t have the usuall shutdown/reboot options, and under vista even task manager lost this functionallity, I’m also using shutdown from command line. Any reason why this has to be so awkward when not being logged on locally?
What about the AT command? No password required. The resulting process runs as SYSTEM, and normally needs to be an Administrator to use it. But there’s a Registry hack that lets Operators use it. So obviously there’s a mechanism to start processes without a password. I’m guessing AT uses the “Schedule” Service (Task Scheduler) too.
But what about application installs? They often perform operations after reboot — whose credentials they use (my guess is System/Local) then? Your token is also not present after reboot and before you login.
Actually, I thought of relying on the fact that the "login" is done when creating the task rather than when running the program, to use tasks as a sort of "setuid" solution.
Create a task scheduled to an expired/invalid/disabled time, and configured to run as Administrator (password entered upon task creation). Then you can run the task as any user, and the program it points to will run as Administrator without prompting for password, just like setuid programs in Unix.
Sounds like it should work, but I wonder whether there’s a cleaner way.
@Martijn: The "shutdown.exe" command-line utility in Windows XP has a LUA bug that prevents non-admin users from using it to shut down or restart the computer.
Workaround documented here:
http://blogs.msdn.com/aaron_margosis/archive/2006/01/27/518214.aspx
I confess, I didn’t understand your reasoning the first time around, Raymond.
If some program calls the imaginary “GetPasswordOfCurrentUser” it is *already running*. There’s no need for it to get the password to do “something evil” later on, it can just do it “now” and be done with it.
I think the truth may be somewhat more like the fact that one never decrypts stored passwords (well, not in theory, anyway), one instead encrypts entered passwords and compares them against the encrypted stored password.
> If some program calls the imaginary "GetPasswordOfCurrentUser" it is *already running*. There’s no need for it to get the password to do "something evil" later on, it can just do it "now" and be done with it.
It can just do it "now" on the current system. It *can’t* (without the password) impersonate the user to a remote system (say, ebay or paypal) and do evil there.
(And as we all know, users *NEVER* use the same password for more than one service, right? Now please excuse me while I go laugh in a corner for a while…)
Anyway, that’s not necessarily the only reason that such an API doesn’t exist, but it’s another good reason.
"But what about application installs? They often perform operations after reboot… Your token is also not present after reboot and before you login."
That is flawed installer logic. It is relying on most users being an Administrator and relying on people always logging in as the same user.
Those installers only work because most users are admins and relies on everybody being an admin and continue to promote using the computer as an admin. In other words, those installers are outmolded and should be replaced with something that doesn’t require a reboot.
@TN: They can do stuff before you log on (at least on Vista). So how does that rely on my account, which is not logged on, to be administrator?
Drak: I would guess that the Installer service can be told to finish installation procedures after a reboot.
Setting programs to run at startup is almost the same security vulnerability (runs when the user is logged in, but can’t really control her environment), and is done silently. Strange.
> Even if they can start doing evil now, you can at least stop it by rebooting the machine
The existence of viruses (or is it virii?) says that is not necessarily true.
It is possible to give this ability to Local System (or to any other account), and I remember successfully doing this when running an SSH daemon under Cygwin. However, the masquerade will only extend as far as the local machine. Any restricted fileshares will still not accept your new identity.
Brian wrote on Monday, March 03, 2008 12:05 PM:
[why enter password twice]
I do not agree. An administration password on work is "such bad", I tend to type it wrong in the same way at least 5 times in a row. It is just the order of keys that is unusual, and it is against the way my fingers want to type. I am not the only person having problems with that password. (The password is required by management, thus, we are not allowed to use another one.)
Additionally, if your keyboard language is set wrong, or CAPS LOCK is on, or similar things, it is very likely to type it wrong in the same way multiple times.
Doesn’t this behaviour imply that the password is stored somewhere (even surviving a reboot) and thus makes it possible to discover it by some malicious program?
Just about to ask the same thing.
Doesn’t scheduling a task involve creating such a magic cookie? And cause the same security risk? Couldn’t some malicious person/program grab that cookie and then use it?
Or is there an airtight hatchway involved?
One would presume that the password that’s stored for a scheduled task is somehow encrypted, much the way a service’s password must be.
We don’t need no steenking password! http://www.theage.com.au/news/security/hack-into-a-windows-pc–no-password-needed/2008/03/04/1204402423638.html
Technically it’s viri, if you want to follow strict Latin rules.
But everyone says "viruses".
Please don’t say virii: that implies there’s a word "virius". Computer people of late aren’t very good at inventing new words.
@nksingh: "You simply cannot go backwards from hash to password."
Uh……http://loginrecovery.com/ begs to differ and it works even if they only get the LMHash. I demo it every time I need to convince somebody to not use alpha-numeric passwords.
PS Virii/viruses: doctors say virii, geeks say viruses, both would sound funny using the other term.
for %s in (hippopotam radi vir doof b) do @echo The plural of %sus is %si
cyanna: no they don’t. Booksmart medics would rarely write "viri" (one "i"); it’s geeks who are obsessed with the hypercorrective "virii". Sometimes "-i" is used for categorisation (like cacti), but -uses is not wrong. Anyway, we’re probably annoying Raymond again by being the kids at the back of the class having their own conversation…
P.S. cyanna: what do you mean, "if they only get the LMHash"? LM is the easiest to crack.
"http://loginrecovery.com/ begs to differ and it works even if they only get the LMHash"
As Anonymous says, it’s pretty widely known that LM password hashes can be brute-forced almost instantly. You can turn LM password hash generation off if you don’t have any Win 9X machines (or NT4) on your network (and in fact, it’s turned off by default in Vista): http://support.microsoft.com/?kbid=299656
Hey, I didn’t claim to be able to spell!
So cute. Too bad the password hashes needed to logon to remote machines, for the last 10 users to use this machine, are already stored in the registry with the default setup (for allowing logons while the domain controllers are unreachable).
These hashes cannot (easily) be reversed to passwords, but they contain all information you need to logon to another computer (using microsofts protocols).
Oh well, this just makes me face the choice. Save a password on the disk (and remember not to change it, ever, or you’ll be continually locked out)? Or run the service as the all-powerful system account (even if it doesn’t need such powers). Neither is secure, and neither is what I want. Suddenly I remember why my critical services do not run on Microsoft OSs.
@anon re cached data for last 10 interactive users: Not true. The hashes are not stored; they are credential verifiers only – there is enough information to verify a logon and reconstitute an access token for local use, but it won’t give you anything you can use to access remote resources. You need to get to a DC to do that.
Ever heard of NtCreateToken?
The more accurate answer to all this is that Windows is frequently set up for network login (domain). Sure, a LocalSystem process can create whatever token it likes, but the token would have no meaning outside the current machine.