Binary Behavior "Administrator approved" Policy Appears Non-Functi

[Guest]

All,

I am still working out Policies to allow McAfee VirusScan Professional 8 to
run with my desired XP Professional computer's settings for the Internet and
Local Intranet Security Zone settings.

McAfee uses an embedded Interent Explorer control to support their web
interface and their primary McAfee Security Center screen uses Microsoft's
Vector Markup Language (VML) binary behavior and will come up just fine with
my current Local Intranet Security Zone settings, if I "Enable" that zone's
"Binary and script behaviors" policy option. However, I would like to set
this option to its "Administrator approved" setting.

Need and Desired Security Architecture: You see I set my Internet Security
zone to high and then place those sites I want to trust to run JavaScript and
signed ActiveX controls in my Local Intranet security zone. This means I may
have many third party sites added that require this to view PDFs and just to
show scripted web pages. However, I do not want them to use all Binary
Behaviors, rather just Trusted Sites security zone web sites will have this
privilege. My XP Professional computer is standalone and not part of any
Windows Active Directory domain. I currently use a combination of registry
settings set by a script and no special machine specific local policies to
secure my computer.

I have used Regmon to verify the following successful reading of the
registry entry that should enable any security zone set to "Admin approved"
to operate successfully:
---
10.44895678 mghtml.exe:3536 EnumerateValue HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\AllowedBehaviors\#default#VML SUCCESS 0x1
----
Unfortunately, the McAfee Security Center screen comes up blank after just
displaying its heading when its "Binary and script behaviors" policy option
is set to "Administrator approved" and the above registry value set to 0x1 as
proved by the above RegMon output.

The article excerpt I used to to know what to do was:
----
If you are a desktop administrator you can decide which Binary Behaviors to
allow in the Locked-down Local Machine Zone. To enable a behavior in the
Locked-down Local Machine Zone, you can add it to the list of
administrator-approved behaviors as follows, replacing the namespace and
behavior variables as appropriate to your environment:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft
\Windows\CurrentVersion\Internet Settings\AllowedBehaviors

#%Namespace%#%Behavior%=dword:00000001

Behaviors that are defined in this list will also be used for any other zone
where the Binary Behavior restriction setting is configured to
“Admin-Allowed†(65536).

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2brows.mspx#EOAA
----

What am I forgetting to do.

Please note again that if I set the "Binary and script behaviors" policy
option to "Enable" the McAfee Security Center screen renders successfully
with no problems. So I know this is the only option preventing the proper
rendering of the screen.

 

[macroman]

Binary Behavior "Administrator approved" Policy IS Non-Functional

Mike:

I just encountered your 1-year-old post, and hope you can provide me any information that you have discovered in the interim. This is of interest to me because I have had similar problems - McAfee SecurityCenter fails to operate properly when "Binary and Script Behaviors" is set to Administrator-Approved. Observing the Registry behavior when using this setting, it initially appeared that VML was required, since #default#VML was an 'AllowedBehaviors' setting that was checked (the only setting in my system. Well, after a lengthy investigation, it is evident that the problem is a bit more complicated. And, unfortunately, there is no obvious full answer - only a work-around.

First, SecurityCenter makes just one check for Binary Behavior settings. This can be verified by setting the "Binary and Script Behaviors" setting to PROMPT via a Registry modification:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3]
"2000"=dword:00000001

This is theoretically "illegal", but it simply generates a prompt every time a Binary or Element Behavior is encountered. One will see that SecurityCenter needs just one prompt (I've seen as many as 9 for certain Microsoft pages). I'd use this trick just for testing purposes, as it gets old quickly and gives no useful information on what permission is being requested.

Secondly, why does SecurityCenter need a permission, and for what? It does NOT appear to be for VML. The reasons are as follows:

1. It runs mghtml.exe on file scui.dll, path = mcp://C:\PROGRA~1\mcafee.com\agent\scui.dll::mcccom.lpk. Embedded within scui.dll are numerous css, html, htc, and script files along with gif images. One may eyeball the innards of scui.dll by copying the file to the desktop and renaming it scui.txt, or one may use ResourceHacker to look inside. Within this file, there are NO references to the string VML, and in fact no occurrences of the string #default.

2. When I run SecurityCenter normally, there is no Registry reference to associated CLSIDs for VML (10072CEC-8CC1-11D1-986E-00A0C955B42E or 2F); in fact, there are no references to the 'Default Behaviors' key in HKLM at all, as monitored by REGMON. The CLSIDs do not appear in scui.dll, either.

3. The lone REGMON reference to the string 'VML' is in the Version Vector (I don't know the purpose of this).

4. The dll that handles Microsoft Vector Graphics Rendering (VML) (C:\Program Files\Common Files\Microsoft Shared\VGX\vgx.dll) is not accessed. Maybe there is another program that runs VML, but I'm not aware of it.

5. If one runs REGMON on a successful SecurityCenter instance with "Binary and Script Behaviors" enabled, the very first thing that is seen after the check for HKCU\...\Zones\3\2000 is the processing of an 'htc' file.

6. There is an Element Behavior (a.k.a. script behavior) called McAfeeTabs:tabstrip with the behavior found in tabstrip.htc (also in scui.dll). This appears to be the only such behavior in the dll; there is no other namespace definition (xmlns), and just tabstrip is associated with namespace McAfeeTabs.

So what is happening as far as my eye can see is that we are looking at the 'script' part of "Binary and Script Behaviors". Unfortunately, neither Microsoft nor anyone on the 'Net provides much information about how to enable these. I tried numerous combinations of namespace and behavior names, all to no avail. As far as script behaviors (i.e., Element Behaviors in Microsoft parlance) are concerned, I would be content to give them blanket approval since Binary Behaviors are much more dangerous.

A workaround for SecurityCenter is simple: Opt out of the Binary Behavior feature control for SecurityCenter:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BEHAVIORS]
"mghtml.exe"=dword:00000000

SecurityCenter will then run properly without ever checking permissions for "Binary and Script Behaviors", even if that setting is disabled. This does NOT solve the more general problems that appear to exist with Binary Behaviors, but that's an on-going investigation. I would welcome suggestions from anyone who can provide advice on how to enable either specific or all Element Behaviors.

That would then leave just Binary Behaviors to enable. However, there is a question as to whether or not Admin-Approved settings work at all for Binary Behaviors. See the October 3, 2005 post titled "Admin-Approved Binary Behavior Setting Fails" at:

http://www.microsoft.com/windows/ie...indows.inetexplorer.ie6.browser&lang=en&cr=US

macroman
XP/SP2; IE6/SP2, fully-patched.

 

[macroman]

Followup: Approved Binary Behavior IS Non-Functional

Although all this is being posted in the "blind" to a one-year-old problem, I am doing so anyway in hopes that those who encounter similar issues might find this data useful.

More research shows that there is a way to enable McAfee SecurityCenter without opting mghtml.exe out of the Binary Behavior feature control. It appears that Microsoft is focused on Binary Behaviors when it states that the AllowedBehaviors Registry entry must be in #package#behavior format. However, for Element (Script) Behaviors, it is necessary to provide the URL of the behavior, as described by Microsoft:

http://msdn.microsoft.com/library/d...hor/dhtml/reference/properties/behavior_1.asp

In the absence of any guidance on how to translate this into action for the specific McAfee element behavior (tabstrip.htc), much experimenting showed that the proper path must include the 'mcp' protocol and the DLL's inclusion of tabstrip. The namespace 'McAfeeTabs' does not need to be included; just the htc file's path. As it exists in my machine, this is:

mcp://C:\PROGRA~1\mcafee.com\agent\scui.dll::tabstrip.htc

Thus, the following '.reg' file, when imported, enables tabstrip functionality:


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\AllowedBehaviors]
"mcp://C:\\PROGRA~1\\mcafee.com\\agent\\scui.dll::tabstrip.htc"=dword:00000001


As there are quite a few htc-packaged element behaviors on various web sites, I have been looking for some method that might 'wildcard' them, either on a per-domain basis or, perhaps, entirely. Unfortunately, such an animal does not seem to exist. This is not pretty for those who actually want to restrict binary/script behaviors without totally disabling them. Granting individual permissions for the various htc files that can exist, especially the numerous ones from Microsoft, can prove to be unmanageable. Again, the main security concerns here are Binary, not Element, Behaviors. Microsoft needs to come up with separate enable/disable mechanisms for the two. I don't mind the built-in binary behaviors, but I do mind someone trying to import others into my machine.

There is another interesting issue. The value of the DWORD does not matter; only its existence is required to enable a behavior. I substituted dword:00000000, dword:00000002, and dword:FFFFFFFF for the above and had SecurityCenter come up cleanly each time. This does not correspond to Microsoft's claim that 0 disables and 1 enables, but it does correspond to the problem reported by this poster at:

http://www.ureader.com/message/1928744.aspx

Incidentally, one may remove the #default#VML entry and yet SecurityCenter still will display properly. Indeed, VML is not required to display the window - as was concluded earlier.

But the bottom line remains the same. It probably is best to opt SecurityCenter out of Behavior feature control as previously posted. If one is concerned about the security of binary behaviors, then it may be best to disable them outright and break some web pages in the process.

macroman
XP/SP2; IE6/SP2, fully-patched.