MS17-JUL: Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure - Windows Server 2008 SP2 / 2008 R2 SP1 / 2012 / 2012 R2 / 2016 - KB4034879

This Fixlet sets a registry setting that is required to close CVE-2017-8563. It is outlined in KB4034879. I noticed that this Fixlet didn’t become relevant until after we installed the July monthly rollup (as intended), and that it was only relevant on Domain Controllers (as intended). However, after deploying the Fixlet to set the registry value to 1, the Fixlet is still relevant on our Domain Controllers. I can see in the relevance that it isn’t even looking in the registry for the setting (LdapEnforceChannelBinding).

I just opened a PMR with IBM for this (61599,082,000), but I’m curious if anyone else has noticed the same thing?

It’s a Task, the purpose is set the value of the registry key to any of the available configurations. It could be set to a different value(enable/disable/optional) once a configuration took place. For reporting purposes you might need to create a property that pulls the value of the associated registry entry.

To @josh.pena 's point, the fixlet relevancy could be that the registry value doesn’t exist, or it’s not 0, 1, or 2. That would then cause the fixlet to not be relevant after running (which is how it should be).

Hi, thank you for the suggestion, but we made that a task such that users can change their mind after deploying it, due to, say, change in security policy.

There is no “best” value for this, for different users have different environments and policies. If it is a Fixlet (instead of a Task) and says “if the value exists and is one of 0, 1 or 2, it’s fixed”, some users might not agree and argue that 0 is not acceptable, or only 2 is acceptable.

Hi, that is true, but with the relevancy always being TRUE, it doesn’t represent a true state of remediated endpoints where the registry setting has been set. The fixlet will always be relevant and if added to baselines/automated patching processes, it will run every patch cycle even though it has already been applied.

Yes exactly, cstoneba. Jason_L – do you understand our point? We want to be able to use the external site fixlet (or in this case, task) to determine whether or not the setting has been set at all. We don’t want to establish a new process for reporting compliance for just this one thing.

Hi,

The nature of this task is a “setting”, it is meant to be applied once, or when necessary, it is not recommended to include it in baselines.

What do you think is a good way to represent the “true state”? The value being 1? or 2? or any of 0, 1, 2?

Any setting should be accepted. The task relevance shouldn’t even look at the actual setting, it should simply check the existence of the valuename (LdapEnforceChannelBinding) itself.

Hi I do understand, however there is no good way to simply tell “this has been settled”, unless all users can agree on something like “this value being set to 1 is good enough”.

May I know how do you report compliance now? I mean, why is this breaking your compliance?

I’m afraid many would disagree. For instance, this value being 0 means channel binding validation is disabled, which is not acceptable by many; it being 1 could be “not good enough” for some others.

We report compliance monthly based on all items in the Patches for Windows site that follow the “monthly patch” naming scheme (e.g. “MS17-JUl *”). Our requirement (for servers) is to have 100% compliance (zero applicable patches following that naming scheme) within 30 days.

I understand your point. This is a unique scenario. Is it possible to simply introduce a parameter field in the description field of the Task for users to defined their desired value?

I think this issue could be addressed differently, for example, I think it would make sense to filter out all tasks, as “tasks” should not be included in compliance reporting. Or, the content team could update the title of this task.

1 Like

You’re right, but if we did that what would be our mechanism for ensuring we set this setting on all applicable systems? We’d have to create a custom solution, which isn’t difficult but I think is unnecessary.

For the reporting of this issue alone, I’m afraid there is nothing more the content team can do, if “this value being set to 1” is what your organisation would accept, you would have to create an analysis. Because, like I have shared, different users accept different settings on this one.

The content team will update the title of this task so that your compliance reporting is no longer broken.

1 Like

But then we (and other organizations) lose visibility into the fact that, without this registry setting, the vulnerability that the patch covers (CVE-2017-8563) is still present. Since this setting is required to enable that aspect of the patch, it needs to be included in the reporting out-of-the-box (in my opinion). Can’t you just introduce a parameter field like I suggested above?

Quoting the KB page:

To help make LDAP authentication over SSL/TLS more secure, administrators can configure the following registry setting on a Domain Controller:

I’m not sure if this implies that the vulnerability is still present without this setting.

It does seem a little unclear, but I still do think it’s required. Here’s from the FAQ on CVE-2017-8563:

In addition to installing the updates for CVE-2017-8563 are there any further steps I need to carry out to be protected from this CVE?
Yes. To make LDAP authentication over SSL/TLS more secure, administrators need to create a LdapEnforceChannelBinding registry setting on machine running AD DS or AD LDS. For more information about setting this registry key, see Microsoft Knowledge Base article 4034879.

I’d suggest that there should be Fixlets for each possible value, and allow the local operators to decide which of the Fixlets to apply.

That’s what I’m going to do, just copy the existing Task to a new Fixlet in one of my custom sites.

Thank you for the suggestion, I think this is more feasible. Still, to any applicable endpoint at least two out of the three resulting Fixlets would be relevant, users still could not put them all into a baseline.