Silverlight, SRP, unprompted Netflix DLL download!

Silverlight not only seems to be incompatible with (Microsoft's) SRP (Software Restriction Policies), but also allows DLLs to be downloaded and run without user's authorization.

I'm using a non-Administrator account (LUA) on Windows XP Pro with full SRP - all programs and DLLs are restricted by default for LUAs. I download and install Silverlight (3.0.40818.0) separate from Netflix from a Windows Admin account. I go to the Netflix webpage and videos play fine from the Admin account. Go to my regular LUA account - get an "Error code 8151" when trying to play videos.

Turns out by going to Netflix and playing a video, Silverlight has downloaded a DLL into my user area and run the DLL WITHOUT EVER PROMPTING ME that it was going to install executable code on my PC and RUN it!

First, executable code should be installed into "Program Files", not under C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\agdrm000.dll

Second, since I never got a prompt saying it was going to download and install executable code, this seems like a major security hole (if the PC has Silverlight, simply download a Silverlight DLL with a virus, Silverlight will run the code).

Third, the option to NOT "Enable download and updates to components required for protected content playback" (translation: install DLLs on your system from any website you visit without any prompting) is per-user, not per-system, so I don't see any reasonable way to manage Silverlight from an IT perspective.

The "engineering" (if one can call it that) side of Silverlight looks like a total hack-job.

If Silverlight needs addition DLLs, it should be a separate install to a system area, like "Program Files" (duh), and not the current hack, which creates opportunities for viruses, makes it difficult to lock down a PC against viruses (using Microsoft's own SRP), and makes managing software almost impossible (installing a DLL for every Windows user on a PC - you must be joking).

 

Microsoft blows a big hole in its own LUA/SRP controls...who would have thought it

 

That's not what has happened here at all. People need to do their homework better.

You may notice Techgee got an error in LUA when trying to play the protected content in Silverlight. That would most likely be because the drm dll could not be loaded - due to SRP. So in fact there was no big hole (or any hole) blown in LUA or SRP by MS here. And of course, LUA does not prevent executing code in the context of the limited user account. So, in LUA without SRP, it's entirely by design that one can download executables and run them in the context of the user account. That's how it goes in practically any multi-user OS these days, Windows or not. What is limited is system-wide installations.

As for drm dlls being downloaded to view protected content, that doesn't surprise me. I'm not familiar with Silverlight, but with any protected content there has to be a drm element of some sort to enforce it, and how else is it going to get on the system than with the actual protected content? As for any security risks in the downloading of such dlls, you'd have to talk to someone who knows how Silverlight was designed. My guess is that there's some kind of sandbox that limits what the drm dlls can be used for, for reasons of security. Obviously you couldn't save such drm dlls in system folders, because then no limited user could view protected content without admin approval, because limited users can't write in system folders. Therefore, such drm dlls need to be stored somewhere where limited users can write, and that is the user's profile folder. Often things that seem like problems are not, when you look further into them.

Oh, and all "executable code" should not be installed in Program Files. Program Files is a place for system-wide installations, programs that are installed for all users of the system. The user profile folders (or anywhere else the user can write) can be used for executables that are intended for use only by that user and not for system-wide use. That's how it's supposed to be. IOW, if you want Open Office installed for all users, you can put it in Program Files where everyone can read but only admins can write. If you want to install some program for only one user, you put that in that user's profile folder in Documents and Settings. Very simple.

Finally, as for Silverlight being "incompatible" with SRP, that's not really the case. One needs to understand that the user sets the SRP rules. If the user doesn't set rules that allow drm dlls to run wherever Silverlight stores them, then those dlls don't run and Silverlight can't use them. Again, that's how it is supposed to be. The user needs to decide on the rules that they want to use and that allow the applications they want to run to work as required. SRP is not "click here once and you're done" technology, the rules you need to set depend on what you intend to do on the system. In other words, it's the user's responsibility to find and apply the rules that are correct for their systems. This is the same as firewall rules, for example: if you want to run a web server on port 80, you shouldn't make a firewall rule that blocks port 80. If you do, and can't access your server, that's not an incompatibility issue, it's a configuration issue.

 

Correct - lift the SRP restrictions and it runs fine from a LUA - which IS good.

The most powerful strategy I know for reducing viruses picked up by visiting websites is to isolate programs with readonly (but execute) access in one "corner" and data with no execute (but read/write) access in another "corner". Silverlight (or at least the Netflix implementation it) makes this unmanagable and does not fit into a LUA/SRP strategy to achieve this.

My point is, it's not necessary to implement DRM with downloaded DLLs - content could be protected by using code supplied with the Silverlight system-wide installation. Hopefully, they "sandboxed" any DLLs, as you've suggested, but IMO the implementation is poor from a security standpoint. Regardless, in the same way I installed Silverlight in "Program Files" (the default) from an Admin account, any DRM code can (and IMO) should also be installed system-wide. Even if content-specific DRM code is necessary, there should be an option to install it system-wide.

Not simple because it's NOT compatible with a SRP/LUA security strategy. A better way (or should I say the standard IT way) of doing per-user software this IS compatible with a SRP/LUA strategy is to install in Program Files and use ACLs to control access. This is what I want to be able to do. I can't with Silverlight.

I, as the user, want to install Silverlight "addons" where I want, system-wide. I can't do this. And I want to be prompted that DLLs or software is being installed. Forcing Silverlight DLLs to user areas makes Silverlight incompatible with a LUA/SRP strategy of dividing up code and data with appropriate access to reduce viruses (i.e. for security reasons).

 

Pardon me for saying so, but I think you're looking at this whole thing from a somewhat strange perspective - as if Windows was built around SRP and software for Windows was supposed to be designed (to get that "Designed for Windows" blessing from MS) to be as easy as possible to use with SRP. In reality, SRP is just one feature in Windows that allows system admins to manually create rules that suit their needs and the requirements of the programs they want to run - in other words, you are supposed to adapt your SRP rules to the software you run, instead of software adapting to deny-all type SRP setups in a world where many if not most coders don't even know about SRP. Again, this brings to my mind firewall configuration: they don't make web servers that work with deny-everything firewall rules, we make firewall rules that allow the servers that we want to run to receive traffic. Yes, this is a calculated risk - and if we can't accept the risk, we can always choose to not run the server...

Yes, not letting untrusted code execute is of course good for security. The obvious weakness in something like a tight default deny SRP is that it is clearly not suited for an environment where you do want to run some new and "untrusted" code - obviously we can't deny all new code and allow some new code at the same time. For a situation like this, one could relax the SRP: one could make an allow rule for the Silverlight drm folder for dll files. In that case, you could run new dlls from that folder, but not elsewhere. This would still effectively block drive-by malware attacks, and should allow Silverlight to deal with protected content. In short, a compromise. If this is unacceptable, one could just not run Silverlight if one considers their current SRP policy more important than Silverlight's functionality. That's how it goes. I don't run Silverlight, btw.

I would not judge the implementation as poor without understanding the security model.

As for installing Silverlight drm code into Program Files only instead of the user profile folders, I say again that doing so would break protected content for limited users (who don't know the admin password and can't elevate) and therefore it should never be the default if the developer wants limited users to be able to view protected content. And obviously MS would want it to work for LUA, which they're trying to encourage people to use. A system-wide installation could be optional, but apparently MS doesn't think it's worth it. You could always request the feature.

Allowing limited users write access in even only specific Program Files subfolders of certain installed programs is far more risky potentially than relaxing SRP rules as suggested above. Why? Because if an admin ever forgets that limited users can write in those folders and executes some file from those folders, then you've just given full admin privileges to a piece of code that could be anything the (potentially malicious) limited user or some malware running in the limited user account wants to write there - like a rootkit, perhaps. It's opening a potential privilege escalation issue - whereas relaxing SRP is only at worst allowing some code to run in the security context of the limited user and not admin. One really is not supposed to play too much with the ACLs in system folders, including Program Files. One can do that, but that means taking a far greater risk than is involved with relaxing SRP rules.

But perhaps you didn't mean giving write privileges to LUA for creating subfolders in Program Files. If you didn't, I don't understand what you meant, though. Because how else could you install a program for one non-admin user than either installing it in a folder where the user can normally write or giving the user some write access to some system folder so they may install the program there?

In any case, the people who designed the OS meant Program Files for global system-wide installations and the user profile folders for per-user installations and user's data. You can see some apps like Google Chrome conforming to this design.

Now we're dealing with design choice. You may find other browser plugins and software that don't allow you to control where they store their data, addons and such. Silverlight doesn't work well with one very tight SRP ruleset, but works well with many more relaxed rulesets. That proves there is no incompatibility with the actual SRP technology. Instead, the issue is a ruleset that is too tight - or alternatively, trying to run software that does not conform to such a tight ruleset. IOW, a configuration issue. You use the word strategy, but configuration is really where the problem is here - or one could say your strategy is too limiting to doing what you want to do, like Silverlight protected content.

But this is just slightly philosophical musing on my part on the differences of configuration issues and real software incompatibility issues. Sorry for getting long-winded.

Where I'm going with this all is: Silverlight does not open any holes in LUA or SRP (the user himself has the choice of whether or not to relax SRP rules), and the drm dll download issue is likely to be a much smaller security issue than it may seem at a glance. Posting in the Silverlight forum or reading the MSDN about how the drm components are handled might be useful and give more information about the security implications. But certainly one should consider treating Silverlight with the same caution as Flash, for example. Unfortunately I can't be of help here - Silverlight isn't something that I have a deep knowledge of.

 

The SRP/LUA policies I have set up and what I'm trying to accomplish (drastically reduce malware) are described elsewhere (see Click Here). Basically LUA's can't install programs, period. Software is only installed from an Administrator group account and only Admins can change SRP policy. LUA's have no write access to Program Files. Even if a LUA installs software to the user area it won't run, due to SRP. Ditto for malware - even if downloaded, it won't run. Also, see Click Here (scroll down to "Step 3 - Setting up the Software Restriction Policy").

Yes, I can and have added a SRP rule to allow C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\*.dll. Which means malware can now download DLLs to that area and run them (outside of Silverlight). So, I've had to poke a hole in my security to make Silverlight work.

Additionally, if you're managing 100 PCs how do you add a SRP rule for Silverlight to these PCs? Either you'll need 100 different rules - one for each user, or you'll need to use a user path that translates to each user-specific Silverlight area. Either way, you might as well just install it system-wide! Oh, but you can't do that with Silverlight....

ssj100 has some good links on techniques to lock down PC's from malware (including SRP, LUA, DEP, restricting auto-start areas with Kafu or otherwise) at Click Here on Wilders.

For SRP, LUA, and DEP to work preventing malware, programs need to be "well behaved". If every program requires security exceptions it doesn't work very well.

 

Yes, that was my guess on your configuration: SRP with a default rule of disallowed, in what is called the Line-of-Business PC config by Microsoft in their SRP documentation. It's something that I've recommended for people interested in controlling what limited users can execute. It works indeed very well against malware.

Now that we're on that subject, generally I also advise people to audit their file permissions with something like Sysinternals' AccessEnum to check if there are subfolders in the default allowed system folders where limited users can both write and execute to get around SRP. The Windows\Temp folder tends to be one such subfolder, where one might want to add an additional SRP rule to disallow execution from that folder.

Not a very big "hole", though, depending on what we're fighting. If one is fighting a malicious user who is present at the system, then they can quickly take advantage of this and execute unauthorized code of their choice (still only gaining limited user level access, though). If one is trying to prevent remote attacks via browser or browser plugin exploits, however, then that additional allow rule for the silverlight drm folder doesn't really mean much. Before there could be an issue, you'd have to have a vulnerable browser or plugin first, and find yourself a site that tries to exploit the right vulnerability. If you keep up with the patches, this should already be pretty difficult most of the time. And even if you get unlucky and run into an exploit site, the exploit will typically just drop a trojan dropper executable in the browser cache, which then tries to download and install the actual malware into system folders or the root of the drive. Problem is, the trojan dropper already will fail, because SRP doesn't allow it to execute from the browser cache. But suppose that it does allow it, what then? Then you'll get some downloaded malware, and the dropper most likely trying to copy them in folders where limited users can't write anyway, and it fails there. If the dropper is smart enough to copy the malware into folders where LUA can write (I've seen some, but not that many, which do this) such as creating a new folder in the root of C or saving in user profile's temp folder, then SRP will again prevent execution. I've never seen an ITW exploit that expects SRP to be present on the victim system and does anything to attempt to get around it, since SRP is fairly little known and even more rarely used as compared to the huge number of systems that don't use it. What I'm saying is that currently malware is as if it didn't know that your SRP rules allow execution from a certain folder, and can't take advantage of that.

With group policy, as always. You create a new group policy object that has the kind of SRP ruleset you want, and then you push that to all the systems that you want to apply this SRP ruleset to. It's exactly the same as with everything else you could do with group policy. I don't know what kind of rules Silverlight needs to work with protected content, but if it's just that it needs to allow dlls from the drm folder, you should be able to use just one single rule for that:
%USERPROFILE%\Local Settings\Application Data\Microsoft\Silverlight\DRM\*.dll Unrestricted
Or for a more secure option, you could check if a registry path rule can be used. If Silverlight stores the location of its drm folder in the registry, you can make the rule based on that without having to use environment variables.

No system-wide installation required.

Yes, programs do need to be "well behaved" to work with LUA, DEP and SRP. We absolutely agree on that. But, in order to work with LUA, programs need to use the user profile folder for storing their per-user data, and if the program is intended to be possible to install in a limited user account for that user only, then it also needs to be installed into the user profile folder, like Google Chrome. (Well, technically you could install into other folders where LUA has write access, but those may not be so easy to find especially if there are non-default ACLs set for example to prevent creating folders in the root of drives.) There's no going around this. Getting compatibility with DEP is easy, and that doesn't require storing data in any specific folders. But by now we should be able to see the issue here: if the developer wants to make their program possible to install in a limited user account, or wants to make it possible for limited users to add components to their program, they need to use the user profile folder for storing all this data. Otherwise, the limited user will not have the required write access. Seeing that many decent developers would want their software LUA compatible, they will do exactly this: store stuff in the user profile, and even allow installing into the user profile folder so you don't need admin rights to install the software for a single user. Can you now see why it's a little hard to make a software that is "well behaved" both with LUA and a full deny-everything SRP at the same time? If you want your program to be installable in LUA and want LUA to be able to add components like, say, Silverlight protected content drm components, then you need to store this stuff where LUA can write, meaning the user profile folder. And if your deny-everything SRP does not allow running code from there, you've got a problem. So, again, the issue is not that the technology is incompatible. The issue is that one has configured SRP to be too strict for the programs one intends to run. Relax the rules a little, and suddenly it all works. Firewall rules and servers, again. But let me put it in just one clear sentence: if we want a limited user to be able to install programs or components for their own account (and many of us want exactly that), then we can't use a software restriction policy ruleset that is so tight as to prevent execution anywhere where limited users can write. A software restriction policy that denies everything new from running is not intended to be used in situations where some new code must be possible to run. It really is that simple. So, one might say that instead of Silverlight requiring security exceptions, a deny-everything type SRP ruleset is a security exception - it's very unusual and unexpected, and it just doesn't work in a case where LUA must be able to execute some new software in their own account. Such a tight SRP is intended only for cases where the admin should be the only one who can install anything new, leaving the users without rights to run new programs even in just their own account. A very special scenario. Such a tight SRP is great for malware protection, but not so great for allowing users to run new software. Where the latter is not required, it works well, of course.

In your case, you need to make a compromise one way or the other: either you relax the SRP rules, or you accept that Silverlight protected content won't work because the drm components can't be loaded. An unlikely third option would be convincing MS to add a feature to install the drm components system-wide, but I doubt they'd see a point to that.

 

Not true. Replace C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\*.dll with this: C:\Documents and Settings\*\Local Settings\Application Data\Microsoft\Silverlight\DRM\*.dll, and you're done.

Keep in mind that SRP represents 0.000000...0001% of the setups in the world. In other words, it is so insignificant that the probability that a hacker decides to bypass it specifically, by using your very "specific" srp setup is close to...0. And anyway, if there was to be an execution, it would be on the context of the user credentials...

Don't forget that Winchild, MechBgon, Tlu, and Sully are the ones who taught us how to use SRP... And the rest...

One last thing, the real "weakness" of SRP doesn't lie here, but in the fact you can run different command lines and request an escalation. On top of your already fine setup, I would recommend you forbid the execution of some extra "features"...: debug.exe, wscript.exe, cmd.exe, command.com, cscript.exe, format.com...

 

Windchild, I'm was already aware of most of the issues you've pointed out - thanks to Wilders Security Forums and others like yourself. All good stuff.

I've still got a lot of tweaking to do on my systems' security - thanks for the tip on AccessEnum and %USERPROFILE%. Already use a couple of Sysinternals' other utilities.

Still disagree on installing programs to LUA accounts. If someone else wants to do it that way, fine. IMO all well-behaved program installs should have the option of installing all code to Program Files and/or Windows folders, which should be the default. The only reason SRP is even possible from a managment standpoint is that most programs today put code in one place and user data in another, like they should. We disagree on what data is - DLLs are not data by any definition (even according to SRP - .dll is one of the default file types that can be managed with SRP). Otherwise, one could argument a .exe is user data if it's sandboxed. Nope, it's still code.

Lucy, don't know why your suggestion to replace the user with * didn't occur to me. I'll keep that in mind.

Don't recognize everyone's name on the forum yet. I do use Sully's PGS on Windows Home edition PCs. Had to tweak the registry using some of your posts to set the default SRP Security Level to Disallowed.

I'm running as a "pure" LUA, not an Admin with reduced rights, so escalation requires entering a password (on XP I often have an Admin Command Prompt up for convenience), so no weakness regarding credentials. However, trustlevel is easily modified which circumvents SRP, which is a problem.

Regarding extra "features": one of my current dilemmas is how to lock down RunAs, cmd.exe, etc., but still be able to use them to escalate (secondary logon to an Admin) without enabling the ability to modify one's trustlevel. IMO, the real weakness of SRP (as currently implimented) is that it's very easy to circumvent. SRP is still relatively unknown and unused, so odds of a virus trying to avoid it are slim. Still, that day will come....

--------

I figured out how to get Silverlight/Netflix to work with NO exceptions to SRP, at least on XP. It's not pretty or easy to manage (so I'm only going to implement it on one PC). My SRP configuration is default Disallowed, Program Files and Windows Unrestricted, plus some other settings. So,

1. Create a temporary SRP exception, allow Unrestricted:
   
   C:\Documents and Settings\*\Local Settings\Application Data\Microsoft\Silverlight\DRM\*.dll​
2. Play a Netflix video (which will put 3 files in the user folders below).
3. Move agdrm000.dll and agdrm000.kf (Requires Admin privs.) from:
   
   C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\​
   to:
   
   C:\Program Files\Microsoft Silverlight\3.0.40818.0\​
4. Edit in place C:\Documents and Settings\*\Local Settings\Application Data\Microsoft\Silverlight\DRM\agdrm.ini - change text to point to the new folder location
   
   original:
   
   
   [agdrm]
   DrmRuntimeName=C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\agdrm000.dll
   DrmKeyfileName=C:\Documents and Settings\<user>\Local Settings\Application Data\Microsoft\Silverlight\DRM\agdrm000.kf​
   to:
   
   
   [agdrm]
   DrmRuntimeName=C:\Program Files\Microsoft Silverlight\3.0.40818.0\agdrm000.dll
   DrmKeyfileName=C:\Program Files\Microsoft Silverlight\3.0.40818.0\agdrm000.kf​
5. Remove temporary SRP exception created above, or set to Disallowed.

Works fine, no holes/exceptions required for SRP. Likely how it should have been implemented in the first place.

Should work until Netflix changes their DRM (in which case I should get another 8151 error). Hopefully at some point Netflix's DRM will be either incorporated into Silverlight, instead of being a special case, or Netflix will have a "real" installation for their DRM code.

 

Netflix eh?

I use netflix, and it is the only reason I have to use silverlight.

Personally I do it one of two ways. I either am shadowed using Shadow Defender, so I just install it and it is gone on next reboot, or I use it in SBIE.

I am not going to bother with actually installing it on my real system. It takes all of 30 seconds to install, so it is a minor annoyance when I need it.

Sul.

 

I think we ought to remember that Microsoft's intention is that limited users can install software for their own account (but not system-wide, of course). I also think this is exactly what most people running limited user accounts want. I certainly do. An account where I can't run any software except that approved by an admin is pretty much useless in some cases (and quite useful in some other cases). So, it is completely by design that LUA can install software for their own account. I like to bring up Google Chrome here, which is a good example. To be installable in LUA, the program has to store itself in the user profile folder, instead of the usual system folders. I certainly agree that software should have an option to install into Program Files - and practically all software I know of does. But, if the developer wants limited users to be able to load additional components - like Firefox extensions, for example - to their software, these additional components which are executable code will have to be stored in the user profile folder or it will not work. That's the plain and simple of it. Sure, code in one place and user data on another - that's the idea for software that is installed system-wide for all users. But for software that's installed per-user or with an option to let LUA add components to the software, you have to place some code, meaning the additional components, in the user profile folder, or it just doesn't work.

One has to understand that the deny-everything SRP is the exception, not the default. Such a software restriction policy is intended to take away LUA's ability to execute new software in their own account, something that is possible in LUA by design. Again, this is simply a configuration and policy issue: you have to decide whether or not you want LUA to be able to run software of their choice in their own accounts. The default is that LUA can run new software in their own accounts. If you want to prevent LUA from doing that, then you can use a deny-everything type SRP, in which case you need to understand that doing so may obviously prevent 1) LUA from running new software of their choice and 2) LUA from adding components for their own account even for software that is already installed system-wide. With the Silverlight protected content, the issue is #2, and it isn't really very surprising.

The whole point of saying this again is to remind folks that a deny-everything SRP is a completely different policy and configuration than exists by default and completely different from what most people want. Such a configuration will limit what you can do, and what will work. That is not an incompatibility issue, it's just a plain configuration issue and policy choice. IOW, if you want to prevent running new code and create a policy to do that, it doesn't really make sense to then complain when you can't run new code - after all, you just made a policy to stop running new code! But perhaps that's enough from me on that. Sometimes people just have irreconcilable differences of opinion.

No, we don't. In general, executables are executables (such as exe or dll) and non-executable data is non-executable data (such as txt or jpg). However, if one wants LUA to be able to run new software or add components to already installed software, then one needs to store new executables in the user profile folder or any other location where LUA can write. And by design, by default, LUA can do that, and software that is intended to be installable in LUA does that. So, I'm not saying these protected content .dlls are non-executable user data. I'm saying they're something that needs to go in the user profile folder, if the intention is that LUA can install those dlls for their own account (and that is exactly the intention of the developer, it seems).

But then, I'd like to make the usual note that given the right interpreter, everything is executable.

It's a good suggestion, and should work just fine as long as Windows is not installed on a drive other than C, or the Documents and Settings folder moved to another drive. In those cases, the %USERPROFILE% environment variable works better.

It's a little easier than it looks. You could disallow runas.exe to prevent using the trustlevel switch for bypassing SRP. This won't prevent you from using the Run As option in the GUI to elevate privileges as long as you don't disable the Secondary Logon service. If you would like to disallow other things, like cmd.exe, for limited users, you can do that, and still use Run As in the GUI to run them with admin privileges.

As far as malware trying to circumvent SRP, I don't think we'll ever see any serious attempts at it. SRP won't ever become very widely used, and it's also getting obsolete even for the limited number of folks using it now - Windows 7 brings us AppLocker, which is very different. From what I've read, AppLocker uses a kernel driver called appid.sys to enforce AppLocker policies, so bypassing that should be a little more tricky than the hacks one can use to bypass SRP. And then there's the whole problem that bad guys tend to be obsessed with admin privileges, and even if you could get around the SRP or AppLocker policy, you'd still be likely to get only LUA privileges, which quite frankly suck if you intend to hide something from the admin and any possible security software. My prediction is that SRP and AppLocker will remain so marginal that they won't be seriously attacked anywhere outside penetration testing, proof of concepts, and perhaps a few highly sophisticated targeted attacks against very high value targets.

Nice hack Glad you found a way to do it. Often there are clever ways to solve issues like this, and you just found one. Maybe they take some time and effort, but that tends to be the price we pay for using non-default configurations and tighter security policies. Now, when someone googles that Silverlight error, maybe they're going to find this thread and find your solution for their problem. Thanks for posting it in such great detail.

 

Um... IIRC, by default, when SRP is activated for the first time it does... nothing! Everything is Unrestricted, which of course, is pointless. The SRP policy and configuration that exists by default is... no policy whatsoever.

Just keeping you honest...

SRP was designed for businesses. Hence, it's not included with Home Editions of Windows. The single largest "installed base" of SRP is businesses. Who uses it? The IT Manager. Why? Because he does NOT want the average user installing or using unapproved software. What SRP policy does he implement to do this? Default Disallow. The normal business usage is exactly the policy I'm trying to implement. That's why Microsoft calls it Line-of-Business PC config, as you've already mentioned.

The default for most home users is not to use SRP at all. For businesses that do use it the default is to Disallow everything but approved software, with exceptions for power users (like yourself) and situations where it isn't practical (IT labs, developers, users that need flexibility in installing software, etc.)

----

I think we both agree that software should be compatible with different security policies, and different security policies are appropriate for different situations. The security policy I'm trying to implement isn't the norm for the average home user, but I still want it supported or possible with the software I use. For medium and large businesses, it's a different story, especially financial institutions. No IT manager wants users installing SW left and right. Of course, there's always some power users who are the exception - usually they get their own separate network/sandbox to play in.

----

It might seem odd the I want Netflix to play nice with SRP. But what I want is, I think, what everyone wants. A PC that lets me do the basic stuff without constant malware hassles. Out of the half dozen PCs in the house, I want the main one to be solid, reliable, and never have serious problems. It should have little or no core system corruption issues or risk of user data theft. Using LUAs protects the core system. But LUAs (especially with unsuspecting users) are susceptible to downloaded viruses. They'll only effect the one LUA, but with key loggers, etc. there is a risk of personal data theft. This where the Disallow by default SRP policy comes in.

So basically, I have a main PC for the house that has only pre-canned apps on it. It can do general office-like stuff, browsing, email, music, videos (DVD and online - Hulu, Netflix, etc.), etc. (No PC games, though - too impractial - other PCs are used for that.) The main PC is safe for (from?) any user, safe enough to feel comfortable doing online banking, keeping personal records on it (SS#s, etc.), etc.

The tradeoff for this is the apps are pre-canned/selected and new software can only be installed from an Administrator account. Also, SRP must be managed. And, of course, as this thread illustrates, some initial configuration must be done when setting up an app for the first time.

So, I don't think my perspective is strange at all.

I've decided using %USERPROFILE%, as you've suggested, is preferred, regardless. Less of security hole. Both of them work fine, though.

(FYI, I've generally avoided using expanded paths in SRP because of a bug I encountered: Setup was Vista Ultimate 64 SP2 with a Core i7 processer, with SRP set to all the defaults except default Disallow and disallow DLLs. SRP denied the avast and PowerDVD's startup/logon process! To resolve the problem, I had to explicitly add C:\Program Files, etc. instead of relying on the %...% versions Microsoft places there by default. Wasted a good part of a day on that.)

I hope you're right. Better for those of us using SRP.

Unfortunately, the 8151 error is a general DRM error. Yes, it does occur when Netflix/Silverlight is denied access to agdrm000.dll due to SRP. However, the error can be due to other things. Just for fun I copied agdrm000.dll and agdrm000.kf to another PC. Got the same 8151 error because the Netflix DRM files don't match the PC. (Copy was from XP 32-bit to Vista 64-bit, so may or may not have been a DRM problem - Silverlight might have thought the DLL was corrupt, missing entrypoints, etc.)

 

I would say that SRP was designed as a tool to have more granular control over execution of a list of monitored executable file types. I would not say it is a tool 'designed' for businesses to create a default deny scenario. It is just how it has been commonly used.

Groups and Group Policies are the method you are really meaning. As home users, they use Admin or Users, with some maybe in Power Users. Have you ever seen the list of default groups in windows for a domain? A little something for everyone. Add into that the ability to create your own groups, and you can tweak the defaults to your likings.

IT departments might use SRP, but more often they will implement a group policy and assign users into a group or groups. They can use security templates on one machine to create the group, then use that template on every computer in the joint. This is how you deploy it in mass. There are other ways as well, but this is a simplified example.

The point is, while SRP can create a default deny situation, it does not by itself do so, because of the possibility of it being much too restrictive. It is meant to restrict or allow specific software, but not really be part of ones overall security scheme. If you are in a corporation and relying soley on SRP then you have a fairly weak scheme IMO when you could be using group policies to much more effect.

SRP is a great tool, and given the fact that many users think outside of the box, it has shown to be even more robust than I am sure even MS thought it would be. But I don't think it is on par with group policies in any fashion.

But then, we all have our opinions just as it should be.

later.

Sul.

 

I believe SRP can be implemented using both Local Security Policy (which can be made to work on Home Editions of Windows with registry tweaks) and Group Policy. However, Group Policy requires setting up a Windows Domain and can NOT be made to work with Home Editions of Windows. So, a lot of the flexibility (and security) of Group Policy isn't really available to home users.

Regardless, I think you're saying both SRP implementations are "layered" on top of "real" ACL security, run in user mode, etc. and as a result have weaknesses.

I believe (correct me if I'm wrong), Group (Domain) Policy allows for a truly secure "SRP" using the execute privilege of ACLs, security templates, custom user groups, etc. All running in kernel mode. While you could probably do the same without Group Policy, without the tools it would probably be a pain to setup and manage.

However, at some point in the future I'd like to try and do such an implementation of "SRP" without a Domain: Set up the PC so by default the ACLs of all folders, files, etc. on the root of all devices, and inherited downward, have no execute privilege for LUAs. The exception being Program Files and Windows folders.

 

True, without some 'extra help' groups and policies on home versions are pretty much lacking.

But, the good news is that you don't need a domain to have better control over a group. Using only the snapins for security templates, you can manipulate it in many wonderous ways. You can use secedit or cacls or subinacl to do even more if you choose to. Granted, this is advanced stuff, but then again, the average user is not going to do as much as you currently are, so you are in a different category already.

I have not point to make here, other than real security can be had by adapting to a policy if one so chooses. Tools like SRP are methods to ease implementation or add more granularity. 3rd party softwares provide a plethora of different interfaces and methods that users might not like about the built-in methods. They all work, it just depends on what flavor of security you like.

Yes, SRP can be implemented as well in mass. If you understand ACL, you understand just how powerful that is. It is, as you elude to, a pain in the watuski to manage if you don't know much about it, especially if you are doing it on your home machine. I think sometimes it is not really that you can't figure out how to change a permission somewhere, but really you lack the knowledge of what to change it to so that you achieve the effects you desire.

I find looking at default security templates and .inf files are the most informative. Once you figure out the differing syntax values, you begin to see just what is set by MS as userland or admin land. The more complex part is tweaking these differing layers of security towards something that is either more tight or less tight. I have played with them more than I ever should have, came up with some rather complex scenarios, some that worked some that did not. Scripting things and building tools to do things for me. I still, after the better part of two years, do not have an implementation that I feel is easy enough to reproduce and modify to give to others. I wish I could, as if more users were to take the time to udnerstand this aspect, they would look at security in a bit different light. Unfortunately, I don't see the average user getting to this point without a lot of studying and playing.

Sul.

 

I, too, can "see" what I want, but implementing it I feel will veer too far to the "non-standard" side. Will have to look into the tools you've suggested, Thanks.

----

Took a look at Microsoft's documentation for AppLocker for Windows 7. Has a local and group implementation like SRP. Only available on Win 7 Ultimate & Enterprise editions (plus Server editions). Seems like it will be more secure than SRP as it's deliberately designed for what I'm trying to do. From Microsoft's site:

You can use AppLocker for the following scenarios:
​

• Help prevent malicious software (malware) and unsupported applications from affecting computers in your environment.
  
• Prevent users from installing and using unauthorized applications.
  
• ...

It's default rule action is whitelisting (default deny):

Can I configure the default AppLocker rule action?
The default rule action is to run only those applications that are specifically allowed in the AppLocker rule collection. While there is no setting to configure the default rule behavior, you can use AppLocker's default rule collection to override the default rule behavior. To do this, create an allow rule with a path condition set to *. This configuration will allow all files to run. You can then create deny rules to block specific files.

Why am I unable to change the default rule action?
Specifying files that are allowed is a more secure and manageable way of controlling applications in an organization than specifying files that are denied. Although initial rule setup can be easier with a deny list, organizations that want to restrict their environments will find that they will need many more rules to block specific files than if they had created a list of allowed files.
​

Another FAQ regarding whitelisting by default from Microsoft's site:

What should I do if my rules are too restrictive and Windows is functioning irregularly or will not start?
When AppLocker is enabled, only applications that are specified will be allowed to run. When you first create rules, AppLocker will prompt you to create the default rules. These default rules ensure that key Windows system files and all files in the Program Files directory will be permitted to run. While the default rules are not mandatory, we recommend that you start with the default rules as a baseline and then edit them or create your own to ensure that Windows will function properly.

If computers cannot start properly due to your AppLocker policy, edit the AppLocker rules in the corresponding GPO to be less restrictive. If the AppLocker rules are defined in a computer's local policy, start the computer in Safe Mode, create the default AppLocker rules, and then restart the computer
​

Microsoft's AppLocker, which "advances the functionality of the SRP feature", is default deny by design. Exactly what I'm trying to achieve with my security policy.

 

That is a great way to put it, 'non-standard'. That is exactly what it becomes. For the creator it is ok, but for others, they would almost certainly have to learn to understand/change.

Regarding AppLocker, I was going to build a front end for it the same as I did for PGS. The front end in AppLocker is not as bad as the SRP one is, but could be easier. However, since 7 cannot seem to provide the same level of hdd performance on my system that XP currently does, I doubt I will buy it until I buy a new machine next year. And even then, if it is a dog on the new hardware in that respect, I will stick to XP or something else rather than shelling out $$$ for a slower experience.

Sul.

 

In reference the inf templates, I agree these are interesting. You can also look at the NSA, NIST and CIS security templates that they publish and see what configurations they are recommending along with an explanation of each setting and ton of information. For example, at (http://www.cisecurity.org/benchmarks.html) you fill out a little form, agree and download a pdf for selected system. Also, the Security Configuration and Analysis Console, is the way to view these inf files in gui without having to know the syntax.

 

Yes, but honest about what? I'll try to explain what I was trying to convey again.

I said the deny-everything SRP is not the default. It isn't, as you know. Instead, it's an exception - something that is unusual, and something that you need to actively set up or it won't be there. This is to say, when you install Windows, no deny-everything SRP is created. Instead, in a default installation of Windows, users can run new software freely in the context of their own accounts. The default policy is "no policy." Since limited users can run new software in their own accounts by default, software developers will create programs that assume they can run new software in a limited user account, since by default that's how those accounts work. They don't assume that everyone is running with a deny-everything SRP, since most everyone is not and the folks who make the operating system don't recommend developers to make that assumption when developing software. This was my point: we need to understand that a tight whitelist type SRP policy is an exception, and it will only be enforced by a select group of folks who want things that many others don't. Developers will not and should not code their software with the assumption that they will be used only in environments where a very non-default, non-standard and extremely tight security policy is enforced. If they made that assumption, limited users couldn't run any software, and LUA would be very uncomfortable for a vast number of users - which would go against the intended design of LUA.

So, I was not making a statement on what the default SRP settings are. I was making a statement of the fact that a deny-everything SRP is not the default in any Windows installation, and that by design limited user accounts can run new software. And what this means is that developers should, can and sometimes will develop software that can be installed in a limited user account and can add components in a limited user account. Doing such things doesn't work when a deny-everything SRP is enforced, but this is not an incompatibility issue, it's simply a configuration issue. My whole point is that a deny-everything SRP blocks functionality that exists by design, meaning the ability to run new software in a limited user account, and therefore developers can't make their software with the assumption that a deny-everything SRP will be enforced on systems where their software will be installed, or they will break things that would and should otherwise work in a LUA. At best they may provide options to save even per-user executables in system folders so one wouldn't need to relax the SRP, but providing those options only works for cases where LUA has the admin password or the admin can be bothered to do this for them, and it would take resources from doing more important things.

SRP is rather rarely used even in businesses. But that doesn't really matter. No matter how many people are using SRP, developers have little choice. They can either stop making software that can be installed or added components to in LUA, or they can continue to make fully LUA-compatible software that obviously can't be installed in a LUA if a deny-everything SRP is enforced. This is my point again. If we make server software, we can't assume that everyone is running a firewall that blocks absolutely all traffic. If we did assume that, what could we do? We'd have to stop making server software, because they wouldn't be able to receive any traffic through the overly tight firewall.

I think different security policies that users may have should be considered in software development as far as it's practical and reasonable and efficient use of resources. Apparently, MS thought that it would not be worth the trouble to create an option for Silverlight to install drm components that are intended to be per-user into system folders so that one could use a deny-everything SRP with no additional exceptions to allow the drm components. Most likely they thought any of those people who actually run a deny-everything SRP are also skilled enough to just make the exception rule to allow the drm components, or if unwilling to do so, find a solution like yours. Indeed, perhaps MS wondered why anyone should even be able to install drm components for Silverlight in such a restricted environment. Me, I'm inclined to agree with MS here. They could have created an additional option to install drm stuff into system folders instead of per-user, but that would only have made a few people happy and the resources spent on that could have been better spent on more important things like fixing real security vulnerabilities or improving Silverlight performance that would benefit far larger numbers of people.

And since you did solve this issue by a rather clever hack, the problem isn't that big, is it? Required some elbow grease, but was solved eventually. This is the kind of stuff one sometimes has to do when using a very restrictive security policy. It would be nice if that wasn't necessary, but frankly that may be asking too much from devs who have more than enough trouble with performance issues and the normal requirements as far as security is concerned. In the SRP documentation Microsoft makes a point to frequently warn readers that SRPs can really mess things up and should be tested carefully with the software that one needs to use on those systems. That's just because SRP changes things so radically: normally you can run new code, but now you can't, and that mucks things up. It would be enormous work for developers to try to play as nice as possible with all the different possible security measures and software, even with just SRP, so what they do is they try to play nice with how the OS works by default, and then let users configure the rest themselves if they use additional security measures. And imagine trying to make your software so it plays nice with some of the HIPS products, for example! Should the software pop up recommendations on what you should allow it to do in your classic-style HIPS configuration, or warn you when it detects it's being virtualized or sandboxed and may be unable to save files in your real system? Complex stuff, and I think developing time would be better spent on the actual features and performance and security of their own program, instead of trying to learn how to work with various security measures that aren't included in the OS (after all, SRP only exists in select Windows versions, and mostly those which home users do not run).

As for the use of dlls for the drm components, likely they thought that was the most powerful and easiest way to go about adding the drm. Design choice - and I don't think it was a bad one.

Yes, I think everyone wants a PC that lets them do things they want without malware hassles. That desire is not strange at all. And your strategy to achieve that with LUA and SRP is one that I personally like and find rather effective.

The one part I was calling strange was that you seemed to me to expect software developers to consider a very unlikely and rare scenario - the deny-everything SRP - instead of just assuming that limited users can run new software, including drm components, which is how the operating system is by design intended to work. I of course may have misinterpreted you! My point being, if you choose an unusual configuration or security policy that prevents something that is normally intended to work in the OS, like executing new code in LUA, then you need to be prepared for the fact that software developers will not assume that unusual configuration will be used by their 'clients' and this will lead to configuration issues like the one you faced and solved here. It's not realistic for developers to cater to all possible security policies - only the basics required by the OS design, such as LUA (and to get devs to do even this is hard!). Those who want to use more complex and restricting security policies simply have to do some work themselves to get things working, and sometimes this may require either ditching the software or relaxing the policy a bit.

Some people have reported that SRP can behave strangely in Vista. I haven't noticed those things personally, but I think there probably are some bugs in there that are causing some folks real trouble. But about the default rules, I always create additional rules to allow the system folders, with full paths, instead of the registry rules created by default. I figure it can't hurt much, and may avoid some issues.

That is doable, but it takes lots of elbow grease and needs to consider ownership for it to really work. As in, LUA creates new file and becomes the owner, and while LUA doesn't have execute permission for anything outside system folders, owner does for everything they own. And even if you take away owner's execute permission, owner can still modify the permissions and take execute permission back. So, you'd have to change the permissions for both users and owner. I actually did this a couple of times, and it worked nicely, but as SRP exists, I kind of thought it too much work for the benefits. And with AppLocker, I don't think doing this is very useful except for the giggles.

But I'm getting all long-winded again! Sorry for boring all you guys with my ranting, but I felt I should at least try to defend the developers a little and explain why they might make their software work like this.