| Date: | January 31, 2008 / year-entry #34 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20080131-00/?p=23633 |
| Comments: | 29 |
| Summary: | Mark Russinovich pointed out that if you let users run arbitrary programs, they can circumvent policies. This is actually not surprising, because policy is not the same as security. Shell policies control how Explorer and other shell components behave, but that's just blocking the front door. For example, there is a shell policy to prevent... |
Mark Russinovich pointed out that if you let users run arbitrary programs, they can circumvent policies. This is actually not surprising, because policy is not the same as security. Shell policies control how Explorer and other shell components behave, but that's just blocking the front door. For example, there is a shell policy to prevent the user from changing the wallpaper from the Desktop control panel. This disables the controls on the Desktop control panel for changing the wallpaper, but there are ways to change the wallpaper other than that. If users can run an arbitrary program, then they can run a program that calls Setting a policy to remove the user interface for a feature is like removing the staircase that leads to the second floor to keep people out. If you let them bring a ladder, then they can still get up there. Mark Russinovich points out that policies are enforced at the application level, and since applications run as the user, the user can run a program that commandeers the application and patches out the code that checks the policy setting. Shell policies are just for modifying the user interface. If you want to block an operation even from users who bypass the normal user interface, you have to block it at a level below the user interface. For example, you might revoke write permission to the relevant registry key; that way, even if the user manages to run their own code on the machine, they still can't change the underlying setting. Every so often, somebody who doesn't understand the difference between shell policy and security submits a security vulnerability report to MSRC saying, "Check this out, I can set the policy to prevent the user from changing the desktop wallpaper via the shell, but through this clever technique of injecting code into Explorer and patching the binary in memory, I can change the desktop anyway!" Well yeah, but why go to all that effort? Just write a program that changes the desktop wallpaper already. |
Comments (29)
Comments are closed. |
Even if you don’t allow your users to run arbitrary programs, they could still exploit some bug (like a buffer overflow) in one of your allowed applications to run arbitrary code anyway.
“For example, you might revoke write permission to the relevant registry key; that way, even if the user manages to run their own code on the machine, they still can’t change the underlying setting.”
Is it guarenteed the location of that key won’t change in the future?
> For example, you might revoke write permission to the relevant registry key
Just to clarify for people who don’t read the article as a whole: if you can run your own code, you can still rewrite the program to read a different key that you have control over.
In the case of desktop wallpaper, it doesn’t even matter if the key is read-only unless the wallpaper file itself is also read-only. Otherwise if you let me run Paint, I can always open the file I want as wallpaper and save it as whatever file the registry says is wallpaper.
Fortunately most things that policy protects are not files and don’t suffer from this additional point of failure.
[Depends on the key. Check the documentation. I can’t believe I had to write that. -Raymond]
That’s what I meant – sorry I was unclear about that. I did check the documentation, but didn’t find any mention of it, so I was kind of asking “Is it OK to do this, and I just didn’t find the answer in the documentation?”
Exactly. But it’s often easier to fix an existing one.
This is definitely an old new thing…
Years ago, IT at the tech support call center I worked in decided to disable registry editing in Windows 95 and pushed the policy to workstations that turned off registry editing. We all had copies of the Windows 95 Resource Kit, and within a week everyone had placed into their Startup folder a .REG file that undid the policy change.
Would you consider the IRM (information rights management) features in Office to be a form of policy? How do you convince a manager that IRM is just a little speedbump and cannot guarantee that recipients of a protected document cannot make copies?
@consequence
Policies can prevent accidental changes.
i.E. your Corporate Policy is to have each computer match the CI. With policies, you can prevent users from making accidental changes.
Malicious users can still change their wallpaper, but in that case they did that maliciously.
"How do you convince a manager that IRM is just a little speedbump and cannot guarantee that recipients of a protected document cannot make copies?"
Remind your manager what a camera is. ;p
Windows have über complicated security under the hood, but still throw in speed bumps like policies, UAC and privileges on top. I really don’t get it. If they made a simple security system that we could actually use, that’d be something. I often find systems "protected" by policies, while the underlying system is unprotected. Off course, its the sysadmins fault, but Windows made it real easy for them.
you mention that there is an API function that does wallpaper changes for you. Why not enforce the policy within the API function as opposed to the application that calls the function? Would it still be the same problem?
[Subverting this alternative API is left as an exercise for the reader. -Raymond]
Ohh… I can do that one… Just write a program that runs "always at the back" (ie behind the icons) that displays the custom wallpaper, just like Active Desktop used to do to display web pages and stuff.
Not being a win32 programmer, I don’t know the actual API and Google doesn’t show up anything easily, but I’m sure Raymond can tell us…
osexpert: It’s one thing to say "somebody should do this", but doing it is another matter. What sort of simple security system do you propose that would permit login scripts to run but not allow the user to get a command prompt?
[Subverting this alternative API is left as an exercise for the reader. -Raymond]
You don’t even need to do that. The shell is just another program running as the user, and the desktop background is part of the shell. There’s nothing the shell can do that the user can’t do, so ultimately it’s a battle you can’t win.
[Subverting this alternative API is left as an exercise for the reader. -Raymond]
Security on api level sounds really wrong, but if Windows had registry value security, not just key, the correct thing would be to deny write to this value.
BTW, one should notice that permissions in HKCU are irrelevant. A user can change the permissions on ntuser.dat and usrclass.dat as well as their top directories to either
a) allow another user to modify them
b) to stop windows from loading them on next login
This way, a user can directly write into these files to change permissions, and then load the hive again.
Gabe: its impossible with any security system. Only the check within cmd.exe can accomplish this. But this is not security! The user could use an alternate command shell or run a patched cmd.exe. This kind of security is pointless: if the user can run harmful commands via cmd.exe, the problem is someplace else.
Also, a simple security system wouldn’t make things possible that aren’t already, but chances are people would use it thus making the system more secure. Currently, you must be an expert to fully understand Windows security and even I struggle.
anonymous: yeah, you are right. ntuser.dat should have been encrypted.
On a terminal server, everything that prevents information disclosure (from mther users) and system failures is welcome. Unfortunately, it’s impossible to get it right. When the shell is locked down to an almost useless level, users complain. When other users hose the server, users complain. It might have to do with the idiot theory.
BTW, don’t forget memory quotas. It ain’t fun when you think everything has been fool-proofed only to discover a couple of sessions running paint can cripple a server, all they have to do is change the size to 99999×99999 pixels.
What’s the point of having shell policies, given that 1) they don’t really prevent anyone from doing anything, and 2) buried somewhere under all the Vista / XP cruft is a real security system that really *can* secure the machine?
[all they have to do is change the size to 99999×99999 pixels.]
Then all you have to do is wave your corporate computer usage policy in their face and disable their account while you contact said future-ex-employee’s manager.
and how would i know what caused a server crash after it happened? Or even while the attack is still going on, with the server in an unuseable state?
Only used by ego tripping IT support folks….
My Uni disabled Internet Explorer’s New Menu and CTRL+N feature to make a new window…
Why oh why when you just had to shift-click a link?
Not to mention we had Visual Basic, Delphi, Turbo c++ and just about every other compiler you could think of installed so it make little difference anyway.
You have to wonder what’s going on in the minds of the people who set these things. Yes, they have their uses, in internet cafes where you dont want settings being changed – but not where a user has their own profile.
Congratulations. You’ve completely missed the point of that comment and this blog entry.
The point of policies is a deterrent, nothing more. You can achieve a lot by preventing the idly curious from messing around with system settings, even if it’s just in terms of reducing the number of helpdesk calls.
Triangle:
No, I did not.
Don’t confuse Group Policies with written Computer Usage policies and guidelines.
It’s not a technical issue.
My favorite example of Microsoft Insecurity nonsense was the setting that let you limit the programs that could be run in Win 98 to those on a named list.
How did it check the program was on the list? It read the program’s name. So if you called NastyVirus.exe, Word.exe it would run fine. Not even shutting the front door; just painting a picture of one.
"It’s not a technical issue."
Except it is. A user shouldn’t be able to cause a system to hang or crash. The solution involves a policy but that doesn’t make it any less technical.