Memory Exploit Mitigation Heap Stacks blocking Office/Acrobat

[John Woodling]

Windows 7 SP1 Enterprise
Patched to May Security patches for all programs
Symantec Endpoint Protection 14.0.3897.1101
Exploit/IPS definitions June 8th, R1 and June 12th R2.

Blocked Attack: Memory Heap Spray attack against C:\Program Files (x86)\Adobe\Acrobat 2015\Acrobat\Acrobat.exe
Blocked Attack: Memory Heap Spray attack against C:\Program Files (x86)\Microsoft Office\Office15\WINWORD.EXE

Since late last week I have been seeing issues with memory exploit/IPS signatures shutting down legitimate programs before they can load, some common examples below:

Adobe Acrobat
Microsft Office Word
Microsoft Office Excel
Internet Explorer

This is when opening the program, not when opening a document or when browsing to a webpage. This seems to only impact windows 7

 

So far I have experienced this on the following IPS definition versions:

June 8th R1

June 12th R2

The June 8th R61 definitions stopped the issue

Support told me to upgrade Office 2013 to 2016 throughout my entire organization and to not use IE, we do not have this option.

Any other users experiencing this? If so have you found a safe version of IPS defintions to use until this is fixed?

[ℬrίαη]

Maybe same issue?

https://www.symantec.com/connect/forums/attack-data-execution-protection-execution-non-executable-memory#comment-12039751

[John Woodling]

Same exact issue.

 

My tickets are 14635966 and 14682531 in case you need reference.

 

Support told me to upgrade all affected programs to the latest version as the solution. Any help would be appreciated.

[ℬrίαη]

I don't work for Symantec, I'm only a customer. Best advice I can offer is request the ticket get escalated. I've also seen issues around this and was told to upgrade.

[Donald Otto]

Brian, thanks for referencing my post in this.

 

John, I'll follow-up with a bit more information below on what we've seen so far. I've also passed this post over to our SE so that they have an additional set of cases to reference.

Systems impacted: both Windows 7 and Windows 10

Patch versions: some with May patches, some with June

SEP Versions: Definitely 14.0.3929.1200 and 14.0.3897.1101, haven't dug into others yet but it appears to be version-agnostic

SEP IPS Definitions: Still haven't established a pattern here on our end. I'll take your word on those definitions.

Date of first occurrence: June 7 @ 7:08 AM

 

We've also found that in some cases, disabling that one signature hasn't been enough - users still experience general slowness with Office apps opening, or software not launching. We tested disabling MEM entirely, which seemed to resolve this, but there is the major drawback of losing all of those protections which are still working. Hopefully this helps, and feel free to shoot me a direct message if you want to discuss environment specifics. We've noticed one common piece of software among impacted machines.

 

Hopefully this issue gets sorted out soon for both our sakes.

[John Woodling]

We have started to see the issues in Windows 10 as well and only had the option of disabling memory exploit mitigation. I went into the policy and set the policy to only log the actions, which should have allowed the programs and logged the attack. It still caused MS Office 2013, Adobe Acrobat, IE, Chrome, and Firefox to hang and throw the memory heap. Some of the applications would open after about 4 to 5 minutes but not consistently.

Once the applications are open the appeared to run adequately but I did not do much testing due to how widespread the issue was.

We are on the May patch level for all applications as well. This issue started to occur prior to patch Tuesday, last Thursday rouhgly, so I would find it hard to believe that it is because we are only one patch cycle behind.

 

 

[Donald Otto]

That's exactly what we're seeing as well. At the advice of our SE, we disabled both Heap Spray and SEHOP mitigations across the board, but that didn't seem to work. We're likely going to have to disable MEM entirely until this is resolved.

 

Patches don't deploy wide-scale for us until 2-3 weeks of testing are complete. I've had May patches on my systems since the third week of May without issue. Out of ~2600 workstations, only 100 or so are seeing this issue. Of those 100, about a quarter have June patches.

[JayboneWH]

Just another set of data points:

We started seeing this this morning (14 June 2018) with systems running the 13 June R20 definitions.  Updating them to 14 June R2 defs didn't help. 

Affected applications so far are MS Office 2013 executables patched up through May, Acrobat DC, Adobe Reader of various versions from 11.0.23 (I know, I know..) through latest DC, IE, Chrome, and ccSvcHost(!).

Affected operating systems are Win7 32- and 64-bit, and Win10 64-bit.  Not that it isn't hitting our Win8 or Win10 32-bit systems - we just don't have any of those.

[Mick2009]

Hi John,

Thanks for the post.  Continue to work with the Tech Support Engineer assigned to your open case.  The team which investigates these suspected MEM FPs will need some materials specified in the "Reporting false positives to Security Response" section of: 

Hardening Windows clients against memory tampering attacks with a Memory Exploit Mitigation policy

http://www.symantec.com/docs/HOWTO127057

 

 

[Mick2009]

Just a ping to see if there is any update on this-?

Also adding an extra note: be sure that only one security suite or product is installed and running at any one time!  If multiple products (for example, SEP and MalwareBytes) are both attempting to interact with files at the same time they can conflict and lead to MEM events.

[JayboneWH]

Not original poster, but we've also had a case open about this since last week.  It's been "under investigation" since Friday.

[Donald Otto]

We're still working through this with support. We have a piece of CMS software that integrates with a number of different applications. Upgrading that did not resolve the issue, but uninstalling it did. Based on what we're seeing, it looks like a legitimate piece of software is now having a conflict with SEP that wasn't there before, likely due to a definitions update. This would be consistent to what John indicated in his initial post regarding IPS definition versions and the issue momentarily disappearing.

[kurt w]

have the same problem since several days with

Signature Name: Attack: Memory Heap Spray

Signature ID: 61005

(  Office14\OUTLOOK.EXE ) all Windows 7 machine

[JayboneWH]

Anyone get a resolution on this yet, or hear anything?  Our case is still in limbo.

[John Woodling]

Unfortunately I am still in the submit IPS false signature positives part of all of this. I submitted what the requested and it is still not "good enough". I will try and update the thread once I have a response.

[MC-SAV]

Thank you John for starting this thread.

Today Symantec provided a work around that would allow Office and Adobe to launch. This is not a fix but allows users to run Adobe and Office. Symantec is still working on the issue.

Symantec instructed me to do the following.

From the Symantec Endpoint Protection Manager open Policies
Select Memory Exploit Mitigation
Right click on Memory Exploit Mitigation policy and select Edit
Uncheck Enable Memory Exploit Mitigation, and click OK
Wait about 10 minutes for the policy to update clients.

If you do not want to disable the Memory Exploit Mitigation for all clients, but only for the users effected then complete the following.

From the local computer launch Symantec Endpoint Protection
Select Change Settings
Select Network and Host Exploit Mitigation Configure Settings
Select the Memory Exploit Mitigation tab
Uncheck Enable Memory Exploit Mitigation

[Mick2009]

A gentle reminder: if MEM false positives are suspected, please check to ensure that only one security product is installed and running on the computer at a time. If there's more than one, they can conflict. 

Should you run more than one antivirus program at the same time?
https://www.symantec.com/docs/TECH104806
 

 

[JayboneWH]

I'm not the OP, but experiencing this issue.

Our case contact has told us that this is a known issue that many customers have been facing, and that the current workaround is to keep MEM disabled.

Further, they stated that a new version of SEP will be released in the next couple of weeks which will resolve this issue, along with a number of bugs that people have experienced with 14.2.  We were specifically told NOT to upgrade to 14.2 (we're on 14.0.1 MP2 - AKA 14.0.3929.1200) as that would not solve this issue and likely introduce other problems.

[John Owens]

Are any of you running Columbiasoft Document Locator?

[JayboneWH]

Yes.

While this issue did not hit nearly all of our workstations with the Document Locator client installed, going back and cross-checking, every single workstation that was effected before we killed MEM did have the Document Locator 6.4 (yes, I know it's old, don't ask...) client installed.

[John Owens]

Symantec is looking into this, however this is not a False Positive.  Document Locator is doing something with their memory access they shouldn't be doing.  It is indeed a Heap Spray.  Has anyone contacted Columbiasoft to look into this?

[John Owens]

Please try the following:

Go to Task Manager, head  over to the Startup tab, finding "CSSInjLoad Module" and right clicking to disable it. Then reboot. 

This should work on both Windows 7 and 10 systems.

Let me know the results.

Thanks,

John Owens

[John Woodling]

I have not contacted Document Locator yet, but I have confirmed that it is document locator in our environment causing this issue. The moment we uninstalled the program, all the problem systems stopped having issues. Your request to stop the component at start up seems to be the best workaround so far. I am going to look at exceptions as the better option hopefully.

This HEAP Spray is seen across multiple versions of document locator. One user listed an old 6.X version and we are at the 7.X version. 

You are stating that this not a false positive. Why did it start getting caught by Memory Exploitation only a few weeks ago when memory exploitation has existed since the inception of 14? HEAP Sprays are not new by any means and if this is indeed not a false positive why did it take this long to catch?

[John Woodling]

This worked as a work around for my environment. Is there a way to add an exception for memory exploitation if the exe is not listed in the program list?

[John Owens]

Hi John,

I don't believe so. I would encourage you to contact Columbiasoft for this as it is their product causing the issue. 

Thanks,

John Owens

[John Woodling]

Hi John,

Could you please provide us further information such as part of the dump file to prove this is occurring? Is there a way that when ColumbiaSoft replies that we could get them with a Symantec resource to coordinate a fix? I dont know how far we would get with saying "Symantec AV says theres a HEAP Spray for this specific component" without logs or information of the memory blocks being reserved.

Thank you,

John W

[normant]

I wish to personally thank Symantec support team for helping us diagnose the issue.  It’s refreshing to be able to work together to resolve issues for mutual customers. 

 

The  “Document Locator Common Dialog” component is an enhancement to the Common Dialog, but it’s not required for base system functionality.  This feature is depreciated with our upcoming release of Document Locator 7.2 Service Pack 4.  Please visit the Customer Center for release information - https://www.documentlocator.com/support/customer/

 

The workaround is to disable ‘Document Locator Common Dialog’ component from system startup.

On Windows 7

1. Click Start->All Programs->Startup.
2. Right-click “Document Locator Common Dialog” and delete item.
3. Reboot the PC.

On Windows 10

1. Open Task Manager.
2. Go the the Startup Tab.
3. Locate “CSSInjLoad Module” from name column.
4. Disable and Reboot.

[Donald Otto]

Norman, thanks for these insights. We were given similar advice and directions, though it was not clear what exactly that CSSInjLoad DLL did. Given that it's on track to be deprecated anyways, it would seem that this should be a reasonable path forward for most using Document Locator. 

[JayboneWH]

Thanks, Norman and John!

KillCSSinjLoad.cmd (assumes the startup item is still using the default name):

taskkill /IM cssinjload.exe /F
del "%ProgramData%\Microsoft\Windows\Start Menu\Programs\StartUp\document locator common dialog.lnk"

Runs locally, or you can either add a /S switch to the taskkill command and the appropriate remote path to run it against a remote system, or use psexec.  E.g.

psexec -c KillCSSinjLoad.cmd \\someRemoteComputer

In our testing, this forceful termiation of the cssinjload.exe will allow programs start up immediately, without the need for a reboot.

[ℬrίαη]

Symantec has a KB article up here:

https://www.symantec.com/docs/TECH250782