VSE 8.8 patch5 bugs

[Troja]

Additional,

if a product does not work, deactivating the feature must not be the solution. This sucks completely. We need a support level which is able to understand the problem and is able to figure out what is going on the provide a solution or a functioning product.

Cheers

[wwarren]

Troja wrote:

Additional,
if a product does not work, deactivating the feature must not be the solution. 

Yes, I agree.

But you made a leap here; nobody is saying that disabling a feature is a solution. Disabling a feature is a viable option that is available to you for the purpose of maintaining business continuity.

With any good Patch adoption plan there will be a business continuity plan. A plan that caters for "What if". And most often that may be uninstalling the product, then reinstalling the last known good build that was used. And depending on the issue that's impacting the business you might have enough data to refine the plan, or to engage an alternate contingency plan because other criteria was met. Disabling Access Protection for example, if it meant restoring business continuity immediately, is a viable option for anybody to consider or to have on hand in their "business continuity playbook". Maybe it isn't for you, and that's OK too, it just means you'd choose a different plan.

These aren't solutions. That comes later, perhaps much later.

[wwarren]

I took a personal day on Friday, and an initial scan of my Inbox tells me our engineering team have confirmed a bug after following the leads from the behavior you reported.

When I get into the office tomorrow and have an opportunity to digest the details of their findings I can post them here to try and bring closure to this portion of the thread.

But just so you know, if Engineering had said it wasn't a bug, after seeing your "if you dare" language, I would have absolutely taken up your gauntlet. I'm interested in sharing facts for the benefit of the community. And while we all would like to believe that what we see is "the Truth" or that our "years of experience" provide us some measure of authority, it is not so. Even I, after 15 years supporting this product 13+ of which within this company, I still get surprised to learn of nuances our engineering team have coded or designed into the product. I feel that speaks to the complexity of the software and its evolving technology (for it must evolve in order to deal with evolving malware). And in that evolution, sometimes there are issues.

... and that points back to the need for customers to do testing, which I shall belabor for the benefit of readers.

[wwarren]

Alright, the denouement is here - and there is a bug. Not too scary though once you take in all the details .

For the more formal looking view of the issue, see KB84900 (apologies if it's not published yet, but it will be soon if not already)

This issue will affect a small subset of our customer base, but our customer base is huge so it affects enough customers that we'll want to fix this promptly.

The issue is seen in Access Protection Processes to Exclude (but we knew that already from 's original post); what we did not know at the time is there are mitigating factors which reduces the prevalence and tells us ways to work around the problem until it can be fixed in code.

All criteria must be present  in order to reproduce this issue with VSE 8.8 Patch 5:

1. you have an OS version that is _not_ NT 5.x (i.e. not Windows XP, or XP x64, or Server 2003), the OS versions using a 5.x kernel are unaffected. !
2. an Access Protection rule is configured to block the eecute action (possible options are ead, rite, reate, elete, and eecute; you can enable any or all of them but if eexecute is one of them then it's affected)

NOTE: None of our AP rules that are enabled by default use the block eecute action.
i.e. potentially affected customers are those who enable non-default rules which do block eecute or who have added rules and configured them to block eecute.

3. the AP rule contains Processes to Exclude
4. the AP rule is configured to BLOCK (i.e. the check mark in the Block column is set)

The whole idea of having processes to exclude is so they don't get blocked but because of this bug, they do get blocked.

Hopefully, the info here spells out for readers whether this is an issue you need to be concerned with, and if so what it is you are needing to look for in testing to confirm if you're affected. If it does affect you, you have options...

Workarounds (as in, what can be done prior to installing a fix)

When the affected rule is one of our rules which has been enabled:

• Disable the affected rule.
• Disable the affected rule and create your own version of it. For example, create your own rule to prevent programs running files from a temp folder, that way, you have more control and cay say to block ead instead of eecute.
• Downgrading is extreme, but you can do that if you must - it is not easy as mentioned above. (Not a recommended option)

When the affected rule is one you have added:

• Disable the affected rule.
• Modify the affected rule and remove the option to block eecute. You can still maintain effectiveness of the rule by enabling the block ead option. This might require having more exclusions than had you only blocked eecute but it's an option nonetheless.
• Revisit the purpose of the rule; can the problem be solved using a different approach that doesn't require blocking eecute action.

Solution

The current plan is to release a hotfix for this issue, so we can expect to see a hotfix available for VSE 8.8 P5 in the near future. And, a cautionary plug, installing a hotfix still carries risk ().

The necessity for installing that hotfix will be High Priority, in my opinion, because I feel it important that anyone be able to craft AP rules to block eecute access attempts while allowing "safe" processes to take that action. I may have considered this Critical or even Mandatory but those don’t really stick due to the mitigating factors and workarounds (Ratings are explained here: KB51560).

FYI: Patch 6, which is already in development with the goal to provide support for Windows 10, will also solve this issue.

[jmaxwell]

Do we know that this behaviour is the cause of the problems reported in this thread ?

I thought that we'd have seen some feedback from affected users by now...

Jim

[wwarren]

jmaxwell wrote:

Do we know that this behaviour is the cause of the problems reported in this thread ?

I thought that we'd have seen some feedback from affected users by now...

Jim

Hi Jim,

For the specific issue of processes to exclude that are added to an AP rule and those exclusions are not working? We've confirmed it is only AP rules that block the Execute action that are affected, and Windows 5.x is unaffected.

If you saw a different issue described in this thread from anyone, then my prior write-up is not relevant to those.

[jmaxwell]

Thanks - given how specific the conditions affecting the AP issue you've posted about are I'm not sure enough info. was posted about the original posters various problems to know if they were caused by this identified problem so I guess we'll need to wait and see what the post (hopefully) back.

Jim

[bakerrl]

Hi William,

So I understand this.  Upgrading to VSE V8.8 P5 would block any process that I enter in the Processes to Exclude list correct?

[jmaxwell]

No - you need to read the McAfee KB article to understand the very specific circumstanced that will result in the reported issues.

Jim

[bakerrl]

That is not what McAfee Support said when I called them.  Which is why I wanted clarification from William.

McAfee Support said any any process that I enter in Processes to exclude of (default or User Defined) would still be blocked.

Roy