Published
Jun 27 2019 06:24 AM
11.5K
Views
First published on TechNet on Dec 12, 2005
Active Directory Group Policy settings are widely used to secure Windows systems because they can be customized to target and deploy to specific computers and users in an Active Directory-based network. In a previous blog post I warned that one of the risks of having end-users with local administrative privilege is that they can override group policy settings at will and I promoted limited-user accounts as the secure alternative. However, Windows administrators should be aware that if a user, even one running with a limited account, can execute just one program of their choice that they also can circumvent many group policy settings, including ones aimed specifically at tightening security such as Software Restriction Policies and Internet Explorer Zones.
The vulnerability within many group policy settings is that the applications at which they are directed enforce the settings. For example, Explorer limits execution of certain applications if Group Policy dictates and Internet Explorer implements Zone security. The Windows architecture sets security permissions on a process that allows the owner of the process full control over the process, which you can verify in the Permissions dialog that you access from the properties dialog of a process in Process Explorer :
That means that users can alter the code or data of their own processes, including Explorer and Internet Explorer, and by manipulating the code or data related to Group Policy enforcement they can bypass Group Policy settings.
Software Restriction Policies (SRP) are another example of Group Policy settings that can be subverted by limited users if you allow them to run an arbitrary executable – in other words, if you don’t apply SRP correctly by using it to define the executables users can run (whitelisting) instead of simply singling out executables that you don’t want them to run (blacklisting). When a user launches a process it’s the parent process that checks SRP to see if the execution of the child should be allowed or blocked, allowing the owner of the parent process to manipulate the process into bypassing or negating SRP processing. There are many ways of accomplishing that, including writing a program that reaches into the parent’s address space and changes the Registry path strings that refer to SRP storage or overwriting the code that reads SRP Registry settings.
I’ve written a simple application, Gpdisable , that demonstrates the ease with which SRP can be disabled by even a limited user. The program uses the DLL injection techniques described by Jeff Richter in Programming Applications for Microsoft Windows (Microsoft Press) to load a DLL into all the processes on the system to which the user running it has access. The DLL places a hook on the NtQueryValueKey API so that it intercepts any calls of the API made by those processes or the DLLs they’ve loaded. The Windows SRP code uses NtQueryValueKey to query the Registry value HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if present and non-zero indicates that SRP is turned on. Here’s a Regmon trace of Cmd.exe, the Command Prompt, reading the value in response to an attempted execution of Notepad.exe, which I’ve disallowed using SRP:
Users don’t have permission to modify keys under HKLM, including the SRP settings, but Gpdisable fools the SRP code by returning an error value, STATUS_OBJECT_NAME_NOT_FOUND, whenever it sees a value named “TransparentEnabled” passed to NtQueryValueKey:
This screenshot shows the “The system cannot execute the specified program.” error SRP reports in the failed attempt to run Notepad.exe in a limited user account followed by execution of Gpdisable and subsequent successful execution of Notepad.exe:
Note that existing processes that have already launched children, such as Explorer and Command Prompt, cache the TransparentEnabled value and so will continue to enforce SRP. You could almost as easily override that by modifying a program like Gpdisable to reach into them and change their cached values.
The Regmon trace of the second Notepad execution looks similar to the first with the major exception that the query of TransparentEnabled is missing: Gpdisable intercepted it in user-mode and so the call never progressed into the kernel:
What other Group Policy settings are susceptible to this type of attack? System-wide security settings are enforced by core operating system components not accessible to limited users, but most of the settings in the Windows Components area of the Group Policy editor’s Administrative Templates node are ineffective in environments where end-users can run arbitrary applications such as Gpdisable:
Notably, Internet Explorer configuration, including Zones, fall into this area, as do Explorer, Media Player, and Messenger settings. The bottom lines is that full control of an end-user environment is possible only with strict lock-down of the programs users run, something that you can accomplish by using SRP in white-list mode, for example. It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.
Originally by Mark Russinovich on 12/12/2005 11:37:00 AM
Migrated from original Sysinternals.com/Blog
# re: Circumventing Group Policy as a Limited User
Hey Mark; now you're writing root kits (GRIN)... Anyway, good info as usual. It goes right back to the things we've complained about in windows for years: the GUI's of each app actually doing the checking on things. For example in the Windows NT 4 world, you could set the policy saying the user can't run regesit. But since regedit only checked the policy when it was creating its main window - things like regedit /s still worked for that user. MS still has a lot to fix in this area as you've shown. Thanks!
12/12/2005 1:34:00 PM by Jerry Ham
# re: Circumventing Group Policy as a Limited User
Can one download GPDisable? Might come in handy if an administrator enables SRP and locks himself out of everything.
12/12/2005 3:27:00 PM by Adam Leinss
# re: Circumventing Group Policy as a Limited User
Where is Gpdisable????
12/12/2005 4:25:00 PM by Mousehack
# re: Circumventing Group Policy as a Limited User
Nice one Mark! Stimulating as usual. Surely the failure here is with the security policy in effect. A policy that blocks only "known" apps from running is bound to fall on it's back or you'll run yourself ragged catching up on new apps to stop. As you briefly stated, a "whitelist" policy would make GPDisable unable to run.
12/12/2005 4:25:00 PM by austin osuide
# re: Circumventing Group Policy as a Limited User
Can one download????
12/12/2005 4:26:00 PM by Mousehack
# re: Circumventing Group Policy as a Limited User
Yup, I carry around a cmd.exe and regedit.exe I modified that ignores GP. Great for quick troubleshooting on a locked down machine.
12/12/2005 11:24:00 PM by legionx
# re: Circumventing Group Policy as a Limited User
The first reference to gpdisable in the post now links to the zip file for download.
12/13/2005 6:42:00 AM by Mark Russinovich
# re: Circumventing Group Policy as a Limited User
Speaking of group policy...it seems you can prevent the running of cmd.exe via Group Policy, but Group Policy has no effect on running command.com, the 16-bit version of the command interpreter.
12/13/2005 12:32:00 PM by Adam Leinss
# re: Circumventing Group Policy as a Limited User
Another way to circumvent some policies is to unplug the computer form the network while it boots so it bypasses any computer policies, logon with cached credentials then plug the cable back-in.
I never really used this to circumvent security policy, but rather to get around a GPO Software Deployment assigned to compters of a specific OU. The software deployment hung at ever boot, so logging on with cached credentials with the cable unplugged was a workaround.
I wonder if this could also be used to bypass some security policies...
12/14/2005 12:17:00 AM by Patrick Rouse
# re: Circumventing Group Policy as a Limited User
I've been doing some security testing on deployment citrix servers lately, to check that they're locked down sufficiently. CMD.EXE is disabled, and COMMAND.COM's NTFS permissions are set to deny local users. Regedit is also disabled. I've found that I can run .bat and .cmd files though.
I've been wondering how I can use this wonderful bit of code in a batch script to gain a command shell, but have been drawing a blank thus far. Any suggestions?
12/14/2005 5:14:00 AM by Sean D
# re: Circumventing Group Policy as a Limited User
"but rather enabled by design decisions made by the Microsoft Group Policy team."
I would suspect that is because the internal Microsoft IT Dept has no respect for employee privacy. The Group Policy teams didn't want to make the rope that would be used to hang them.
12/14/2005 9:43:00 AM by Adam Gates
# re: Circumventing Group Policy as a Limited User
Nice, altough I think that some people will not read it until the end and won't understand it and will post in a tech site something like "new vulnerability allows to circumvent windows group policies"
12/14/2005 10:54:00 AM by Diego Calleja
# re: Circumventing Group Policy as a Limited User
Sean D - not sure about cmd or bat files... but I just tried this - I locked down cmd.exe and calc.exe and ACL'd command.com and was still able to launch calc.exe with a simple wshshell.run command launching gpdisable, specifying calc.exe.
12/14/2005 11:45:00 PM by Wes
# re: Circumventing Group Policy as a Limited User
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
12/16/2005 2:30:00 PM by Eric Wood
# re: Circumventing Group Policy as a Limited User
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
1/8/2006 11:32:00 PM by Eric Wood
# re: Circumventing Group Policy as a Limited User
Great article Mark! Do you know if in windows vista the engine of software restriction will change?
1/15/2006 1:27:00 PM by Márcio Schneider
# re: Circumventing Group Policy as a Limited User
Wow. This site is great. I have no words to said more than thanx.
1/15/2006 6:09:00 PM by Dennis
# re: Circumventing Group Policy as a Limited User
Hello!
I'm admin. How can i protect my network from this exploit?
1/18/2006 1:43:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
I'm admin. How can i protect GP from this exploits?
1/18/2006 1:45:00 PM by krneki
# re: Circumventing Group Policy as a Limited User
krneki, read the last paragraph.
2/1/2006 9:41:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
Ive been using SRP for a few months and found it worked great for internet-outward facing programs and other nasty's that try to get a grip of HKLM (such as Limewire/AUX Magnet Key??). Now Mark's gone and blown this away...sweet.
So for a white-list, which executables are in need of and/or safe to lock down??
If I use SRP on system files Im gonna get problems, so I'd would be nice if someone knowledgable could start a SRP whitelist....? Or do we just apply a Basic User rule to /Program Files/
"Where is Gpdisable????"
My first thought when I saw this post was that some nasty script writer would like to implement Mark's work into something else....just a thought.
2/27/2006 10:45:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
SAFER is inherintly unsafe if the the default rule is allowed. At best, it is a security management solution where an admin can send out a disallow rule to block naive user from accidentally click on a malware. The technique Mark described will not work if the default rule is disallowed and only a limited set of allowed programs and DLLs are permitted to run via allow rules (path, hash, or certificate). You can even make all internet facing applications, like IE, to run as basic user by creating a basic user level rule on these applications.
3/4/2006 2:14:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
http://www.eff.org/sony/
The settlement process has begun in The Electronic Frontier Foundation class action lawsuit against Sony BMG for the flawed digital rights
management(DRM) that Sony BMG released in millions of CDs over the last several years.
DMusic has been working with EFF to notify as may people as possible so they can get some redress against Sony BMG pursuant to the class action settlement, or alternatively, choose to seek compensation against Sony BMG individual in their own lawsuit.
Music fans who bought the affected CDs can submit claims for clean music. Many customers are also eligible for extra downloads or a small cash settlement.
SO PLEASE CHECK OUT http://www.eff.org/sony/ for more details about the settlement, including a list of the CDs affected. AND MAKE sure you don't stick an infected CD in your computer - it will plant malicious spyware that is difficult to remove!
3/12/2006 3:28:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
Policy is not applied at all if a DC cannot be reached. Unplugging the network and logging on with cachedcredentials prevents GP processing and therefore the previous refresh of policy remians in effect. There is never an application of policy form a local cache.
3/22/2006 8:06:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
"I wonder if this could also be used to bypass some security policies... "
Downloading the "regtools.vbs on" http://dougknox.com/security/scripts_desc/regtools.htm will allow a off-line computer (if vbs is allowed) to turn on all registry editing tools. You can then change many restrictions set by GP's and make the changes you wish and you'll likely find that many of the changes in the registry stays when you login again and teh GP is returned.
Another approch in some systems when restrictions are enforced by scripts is to use Mark's Autoruns to kill the entries that run startup scripts when you are login with a connection to the network. Not uncommon on larger corporations networks as far as I've seen.
5/26/2006 2:21:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
Marcus Ranum's "Six Dumbest Ideas in Computer Security" treatise point #1: "Default Permit" illustrates a foundational flaw in the common approach to Software Restriction Policies: the default policy is to run unrestricted with exceptions (as Mark made in this example "notepad.exe" was denied).
Had the SRP been implemented in reverse following a best practices approach of "Default Deny" (e.g. like security professionals use on firewalls) instead of "Default Permit", Mark's lovely little gpdisable.exe tool would not have been allowed to hook those DLLs programatically. And Mark noted this flaw above: "...if you don’t apply SRP correctly by using it to define the executables users can run..."
Once again, great attention to detail, Mark, but ... Everybody please note that if your environment is susceptible to this attack, you have further contributed to the flaw of doing it all wrong and backwards using "Default Permit". Instead, be diligent to "certify" all approved applications in your environment instead of the lazy "Default Permit" approach.
On the other hand, if you implemented SRP correctly using "Default Deny", you could probably kiss goodbye your signature-based Anti-Virus software (or any anti-malware software for that matter), which also is yet another example of the flawed "Default Permit" mindset (i.e. allow all programs to execute except known viruses that match a predefined "black list"). If you coupled the "Default Deny" SRP with a limited user approach , you could definitely go without that AV software.
Soapbox of the day ...
-Tim MalcomVetter, CISSP
10/1/2006 10:07:00 AM by malcomvetter
Active Directory Group Policy settings are widely used to secure Windows systems because they can be customized to target and deploy to specific computers and users in an Active Directory-based network. In a previous blog post I warned that one of the risks of having end-users with local administrative privilege is that they can override group policy settings at will and I promoted limited-user accounts as the secure alternative. However, Windows administrators should be aware that if a user, even one running with a limited account, can execute just one program of their choice that they also can circumvent many group policy settings, including ones aimed specifically at tightening security such as Software Restriction Policies and Internet Explorer Zones.
The vulnerability within many group policy settings is that the applications at which they are directed enforce the settings. For example, Explorer limits execution of certain applications if Group Policy dictates and Internet Explorer implements Zone security. The Windows architecture sets security permissions on a process that allows the owner of the process full control over the process, which you can verify in the Permissions dialog that you access from the properties dialog of a process in Process Explorer :
That means that users can alter the code or data of their own processes, including Explorer and Internet Explorer, and by manipulating the code or data related to Group Policy enforcement they can bypass Group Policy settings.
Software Restriction Policies (SRP) are another example of Group Policy settings that can be subverted by limited users if you allow them to run an arbitrary executable – in other words, if you don’t apply SRP correctly by using it to define the executables users can run (whitelisting) instead of simply singling out executables that you don’t want them to run (blacklisting). When a user launches a process it’s the parent process that checks SRP to see if the execution of the child should be allowed or blocked, allowing the owner of the parent process to manipulate the process into bypassing or negating SRP processing. There are many ways of accomplishing that, including writing a program that reaches into the parent’s address space and changes the Registry path strings that refer to SRP storage or overwriting the code that reads SRP Registry settings.
I’ve written a simple application, Gpdisable , that demonstrates the ease with which SRP can be disabled by even a limited user. The program uses the DLL injection techniques described by Jeff Richter in Programming Applications for Microsoft Windows (Microsoft Press) to load a DLL into all the processes on the system to which the user running it has access. The DLL places a hook on the NtQueryValueKey API so that it intercepts any calls of the API made by those processes or the DLLs they’ve loaded. The Windows SRP code uses NtQueryValueKey to query the Registry value HKLM\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers\TransparentEnabled, which if present and non-zero indicates that SRP is turned on. Here’s a Regmon trace of Cmd.exe, the Command Prompt, reading the value in response to an attempted execution of Notepad.exe, which I’ve disallowed using SRP:
Users don’t have permission to modify keys under HKLM, including the SRP settings, but Gpdisable fools the SRP code by returning an error value, STATUS_OBJECT_NAME_NOT_FOUND, whenever it sees a value named “TransparentEnabled” passed to NtQueryValueKey:
This screenshot shows the “The system cannot execute the specified program.” error SRP reports in the failed attempt to run Notepad.exe in a limited user account followed by execution of Gpdisable and subsequent successful execution of Notepad.exe:
Note that existing processes that have already launched children, such as Explorer and Command Prompt, cache the TransparentEnabled value and so will continue to enforce SRP. You could almost as easily override that by modifying a program like Gpdisable to reach into them and change their cached values.
The Regmon trace of the second Notepad execution looks similar to the first with the major exception that the query of TransparentEnabled is missing: Gpdisable intercepted it in user-mode and so the call never progressed into the kernel:
What other Group Policy settings are susceptible to this type of attack? System-wide security settings are enforced by core operating system components not accessible to limited users, but most of the settings in the Windows Components area of the Group Policy editor’s Administrative Templates node are ineffective in environments where end-users can run arbitrary applications such as Gpdisable:
Notably, Internet Explorer configuration, including Zones, fall into this area, as do Explorer, Media Player, and Messenger settings. The bottom lines is that full control of an end-user environment is possible only with strict lock-down of the programs users run, something that you can accomplish by using SRP in white-list mode, for example. It's also important to note that the ability of limited users to override these settings is not due to a bug in Windows, but rather enabled by design decisions made by the Microsoft Group Policy team.
Originally by Mark Russinovich on 12/12/2005 11:37:00 AM
Migrated from original Sysinternals.com/Blog
# re: Circumventing Group Policy as a Limited User
Hey Mark; now you're writing root kits (GRIN)... Anyway, good info as usual. It goes right back to the things we've complained about in windows for years: the GUI's of each app actually doing the checking on things. For example in the Windows NT 4 world, you could set the policy saying the user can't run regesit. But since regedit only checked the policy when it was creating its main window - things like regedit /s still worked for that user. MS still has a lot to fix in this area as you've shown. Thanks!
12/12/2005 1:34:00 PM by Jerry Ham
# re: Circumventing Group Policy as a Limited User
Can one download GPDisable? Might come in handy if an administrator enables SRP and locks himself out of everything.
12/12/2005 3:27:00 PM by Adam Leinss
# re: Circumventing Group Policy as a Limited User
Where is Gpdisable????
12/12/2005 4:25:00 PM by Mousehack
# re: Circumventing Group Policy as a Limited User
Nice one Mark! Stimulating as usual. Surely the failure here is with the security policy in effect. A policy that blocks only "known" apps from running is bound to fall on it's back or you'll run yourself ragged catching up on new apps to stop. As you briefly stated, a "whitelist" policy would make GPDisable unable to run.
12/12/2005 4:25:00 PM by austin osuide
# re: Circumventing Group Policy as a Limited User
Can one download????
12/12/2005 4:26:00 PM by Mousehack
# re: Circumventing Group Policy as a Limited User
Yup, I carry around a cmd.exe and regedit.exe I modified that ignores GP. Great for quick troubleshooting on a locked down machine.
12/12/2005 11:24:00 PM by legionx
# re: Circumventing Group Policy as a Limited User
The first reference to gpdisable in the post now links to the zip file for download.
12/13/2005 6:42:00 AM by Mark Russinovich
# re: Circumventing Group Policy as a Limited User
Speaking of group policy...it seems you can prevent the running of cmd.exe via Group Policy, but Group Policy has no effect on running command.com, the 16-bit version of the command interpreter.
12/13/2005 12:32:00 PM by Adam Leinss
# re: Circumventing Group Policy as a Limited User
Another way to circumvent some policies is to unplug the computer form the network while it boots so it bypasses any computer policies, logon with cached credentials then plug the cable back-in.
I never really used this to circumvent security policy, but rather to get around a GPO Software Deployment assigned to compters of a specific OU. The software deployment hung at ever boot, so logging on with cached credentials with the cable unplugged was a workaround.
I wonder if this could also be used to bypass some security policies...
12/14/2005 12:17:00 AM by Patrick Rouse
# re: Circumventing Group Policy as a Limited User
I've been doing some security testing on deployment citrix servers lately, to check that they're locked down sufficiently. CMD.EXE is disabled, and COMMAND.COM's NTFS permissions are set to deny local users. Regedit is also disabled. I've found that I can run .bat and .cmd files though.
I've been wondering how I can use this wonderful bit of code in a batch script to gain a command shell, but have been drawing a blank thus far. Any suggestions?
12/14/2005 5:14:00 AM by Sean D
# re: Circumventing Group Policy as a Limited User
"but rather enabled by design decisions made by the Microsoft Group Policy team."
I would suspect that is because the internal Microsoft IT Dept has no respect for employee privacy. The Group Policy teams didn't want to make the rope that would be used to hang them.
12/14/2005 9:43:00 AM by Adam Gates
# re: Circumventing Group Policy as a Limited User
Nice, altough I think that some people will not read it until the end and won't understand it and will post in a tech site something like "new vulnerability allows to circumvent windows group policies"
12/14/2005 10:54:00 AM by Diego Calleja
# re: Circumventing Group Policy as a Limited User
Sean D - not sure about cmd or bat files... but I just tried this - I locked down cmd.exe and calc.exe and ACL'd command.com and was still able to launch calc.exe with a simple wshshell.run command launching gpdisable, specifying calc.exe.
12/14/2005 11:45:00 PM by Wes
# re: Circumventing Group Policy as a Limited User
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
12/16/2005 2:30:00 PM by Eric Wood
# re: Circumventing Group Policy as a Limited User
For the blogger that mentioned unplugging the network cable during the boot process as a method to "get around" the application of computer policy. That's not entirely correct. What you're getting around is the policy update mechanism. Policy is applied from a local cache. If the network is unavailable then the computer will simply detect that and jump straight to the application of the cached policies. Plus, after the boot process policy will reapply at specific intervals even if no change has occurred.
1/8/2006 11:32:00 PM by Eric Wood
# re: Circumventing Group Policy as a Limited User
Great article Mark! Do you know if in windows vista the engine of software restriction will change?
1/15/2006 1:27:00 PM by Márcio Schneider
# re: Circumventing Group Policy as a Limited User
Wow. This site is great. I have no words to said more than thanx.
1/15/2006 6:09:00 PM by Dennis
# re: Circumventing Group Policy as a Limited User
Hello!
I'm admin. How can i protect my network from this exploit?
1/18/2006 1:43:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
I'm admin. How can i protect GP from this exploits?
1/18/2006 1:45:00 PM by krneki
# re: Circumventing Group Policy as a Limited User
krneki, read the last paragraph.
2/1/2006 9:41:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
Ive been using SRP for a few months and found it worked great for internet-outward facing programs and other nasty's that try to get a grip of HKLM (such as Limewire/AUX Magnet Key??). Now Mark's gone and blown this away...sweet.
So for a white-list, which executables are in need of and/or safe to lock down??
If I use SRP on system files Im gonna get problems, so I'd would be nice if someone knowledgable could start a SRP whitelist....? Or do we just apply a Basic User rule to /Program Files/
"Where is Gpdisable????"
My first thought when I saw this post was that some nasty script writer would like to implement Mark's work into something else....just a thought.
2/27/2006 10:45:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
SAFER is inherintly unsafe if the the default rule is allowed. At best, it is a security management solution where an admin can send out a disallow rule to block naive user from accidentally click on a malware. The technique Mark described will not work if the default rule is disallowed and only a limited set of allowed programs and DLLs are permitted to run via allow rules (path, hash, or certificate). You can even make all internet facing applications, like IE, to run as basic user by creating a basic user level rule on these applications.
3/4/2006 2:14:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
http://www.eff.org/sony/
The settlement process has begun in The Electronic Frontier Foundation class action lawsuit against Sony BMG for the flawed digital rights
management(DRM) that Sony BMG released in millions of CDs over the last several years.
DMusic has been working with EFF to notify as may people as possible so they can get some redress against Sony BMG pursuant to the class action settlement, or alternatively, choose to seek compensation against Sony BMG individual in their own lawsuit.
Music fans who bought the affected CDs can submit claims for clean music. Many customers are also eligible for extra downloads or a small cash settlement.
SO PLEASE CHECK OUT http://www.eff.org/sony/ for more details about the settlement, including a list of the CDs affected. AND MAKE sure you don't stick an infected CD in your computer - it will plant malicious spyware that is difficult to remove!
3/12/2006 3:28:00 AM by Anonymous
# re: Circumventing Group Policy as a Limited User
Policy is not applied at all if a DC cannot be reached. Unplugging the network and logging on with cachedcredentials prevents GP processing and therefore the previous refresh of policy remians in effect. There is never an application of policy form a local cache.
3/22/2006 8:06:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
"I wonder if this could also be used to bypass some security policies... "
Downloading the "regtools.vbs on" http://dougknox.com/security/scripts_desc/regtools.htm will allow a off-line computer (if vbs is allowed) to turn on all registry editing tools. You can then change many restrictions set by GP's and make the changes you wish and you'll likely find that many of the changes in the registry stays when you login again and teh GP is returned.
Another approch in some systems when restrictions are enforced by scripts is to use Mark's Autoruns to kill the entries that run startup scripts when you are login with a connection to the network. Not uncommon on larger corporations networks as far as I've seen.
5/26/2006 2:21:00 PM by Anonymous
# re: Circumventing Group Policy as a Limited User
Marcus Ranum's "Six Dumbest Ideas in Computer Security" treatise point #1: "Default Permit" illustrates a foundational flaw in the common approach to Software Restriction Policies: the default policy is to run unrestricted with exceptions (as Mark made in this example "notepad.exe" was denied).
Had the SRP been implemented in reverse following a best practices approach of "Default Deny" (e.g. like security professionals use on firewalls) instead of "Default Permit", Mark's lovely little gpdisable.exe tool would not have been allowed to hook those DLLs programatically. And Mark noted this flaw above: "...if you don’t apply SRP correctly by using it to define the executables users can run..."
Once again, great attention to detail, Mark, but ... Everybody please note that if your environment is susceptible to this attack, you have further contributed to the flaw of doing it all wrong and backwards using "Default Permit". Instead, be diligent to "certify" all approved applications in your environment instead of the lazy "Default Permit" approach.
On the other hand, if you implemented SRP correctly using "Default Deny", you could probably kiss goodbye your signature-based Anti-Virus software (or any anti-malware software for that matter), which also is yet another example of the flawed "Default Permit" mindset (i.e. allow all programs to execute except known viruses that match a predefined "black list"). If you coupled the "Default Deny" SRP with a limited user approach , you could definitely go without that AV software.
Soapbox of the day ...
-Tim MalcomVetter, CISSP
10/1/2006 10:07:00 AM by malcomvetter