Export from excel to pdf

[Tim_McColgan]

We are seeing an issue since we upgraded to client E80.83.5080. When a user saves an Excel file and chooses the File Type of PDF, an error will show up in Excel saying the document has not been saved. However, the strange thing is, the file will (sometimes) save. It seems that it saves when you try the save as PDF process after the first time with the same file. 

No matter what, it is not consistent, removing the computer out of the Sandblast OU with all policies on - fixes the computer and they are able to save as PDF without issue. 

Has anyone seen this? Can you point me into a direction to get this fixed? 

FYI management server is running r77.30

OS build 5
OS kernel version 2.6.18-92cpx86_64
OS edition 64-bit

[PhoneBoy]

The best way to get the version info is using the command cpinfo -y all

The above doesn't say, for instance, what jumbo hotfix you're running of R77.30 (which is, at minimum, JHF 143, but likely higher)

In any case, this is probably a client-side issue and may need the TAC to troubleshoot.

Have you opened a case by chance?

[Tim_McColgan]

Thanks Dameon, yes TAC case opened today thanks. For what it is worth here is the full version info: 

This is Check Point CPinfo Build 914000182 for GAIA
[FW1]
HOTFIX_R77_30
HOTFIX_GEYSER_HF_BASE_861
HOTFIX_R77_30_JHF_T143_ERB
HOTFIX_FLUORINE
HOTFIX_R77_30_JUMBO_HF Take: 302

FW1 build number:
This is Check Point Security Management Server R77.30 - Build 013
Installed Plug-ins: R77.20 Add-on, R77.30 Add-on, Endpoint Security Management R77 Plug-in, Capsule Docs DLP Add-on, Endpoint Security Management R77.30 Plug-in, Endpoint Security Management R77.30.03 Sandblast Plug-in
This is Check Point's software version R77.30 - Build 115

[SecurePlatform]
HOTFIX_R77_30_JUMBO_HF Take: 302

[CPinfo]
No hotfixes..

[SmartPortal]
HOTFIX_R77_30_JUMBO_HF Take: 302

[Reporting Module]
HOTFIX_R77_30
HOTFIX_R77_30_JUMBO_HF Take: 302
HOTFIX_COPPER_GA_148

[CPuepm]
HOTFIX_R77_30
HOTFIX_R77_30_JHF_T143_ERB
HOTFIX_FLUORINE
HOTFIX_R77_30_JUMBO_HF Take: 302

[SmartLog]
HOTFIX_R77_30
HOTFIX_ERBIUM
HOTFIX_R77_30_JUMBO_HF Take: 302

[SFWR77CMP]
HOTFIX_R77_30

[R7520CMP]
HOTFIX_R77_30

[R7540CMP]
HOTFIX_R77_30

[R7540VSCMP]
HOTFIX_R77_30

[R76CMP]
HOTFIX_R77_30

[R75CMP]
HOTFIX_R77_30

[NGXCMP]
HOTFIX_R77_30

[V40CMP]
HOTFIX_R77_30

[EdgeCmp]
HOTFIX_R77_30

[SFWCMP]
HOTFIX_R77_30

[FLICMP]
HOTFIX_R77_30

[CON66CMP]
No hotfixes..

[SFWR75CMP]
HOTFIX_R77_30

[PItpi]
No hotfixes..

[PIscrub]
No hotfixes..

[PIuepmars]
No hotfixes..

[PIcapsule]
No hotfixes..

[PIsandbox]
No hotfixes..

[PIsandblastR77_30_03]
No hotfixes..

[CPUpdates]
BUNDLE_CPINFO Take: T33
BUNDLE_R77_30_JUMBO_HF Take: 302

[DIAG]
HOTFIX_R77_30

[rtm]
No hotfixes..

[Willem_Goethals]

We have the same issue with exports from Visio to PDF. The file is handled by the Threat Extraction blade and therefore cannot be saved as it seems to be "open in another program", even though the file is not necessarily emulated. If we provide an exception for example for c:\temp and export the file there, we see this clearly in c:\ProgramData\CheckPoint\Logs\TELog.log:

t[140618T103944.307]p[1410:61]l[Warn]s[Engine]: *** DispatchCpepmonMessage calling (MsgId: 0, type: NewFile)
t[140618T103944.307]p[1410:61]l[Trace]s[FSEvent]: NewFile or Rename 'C:\Temp\mso113B.tmp' fields: md5: 531ea142c01f4efe6023b2f27c4fd4b1, sha1: e6cefab3a949f18163b49196b5701ed38eb3bba7, process: Process: 'C:\Program Files (x86)\Microsoft Office\Office16\VISIO.EXE', id: '8300', signer: 'Microsoft Corporation', original file name: 'VISIO.EXE', md5: '4d8596024d98709a91b14b8113831c54', creation time: '06/14/2018 08:14:58', dbindex: 3962, reason: LocalFileProcessTouchedNonLocalFile, sig id: 21253
t[140618T103944.307]p[1410:67]l[Trace]s[FSEvent]: Cpepmon message is being handled. Db index: '3962', notification type: 'NewFile', reply msg id: '0'
t[140618T103944.968]p[1410:67]l[Trace]s[FileInfo]: Backup result for file 'C:\Temp\mso113B.tmp': 'Success'
t[140618T103944.994]p[1410:67]l[Trace]s[FileInfo]: File 'C:\Temp\mso113B.tmp' has signature id '21253' with type 'pdf', eligible: 'True'
t[140618T103945.235]p[1410:67]l[Trace]s[FSEvent]: Type has no associations, path: 'C:\Temp\mso113B.tmp', type: 'pdf'
t[140618T103945.235]p[1410:67]l[Trace]s[FSEvent]: BMRule: type: 'Path', value 'c:\temp\' match 'C:\Temp\mso113B.tmp' => Action: Ignore
t[140618T103945.235]p[1410:67]l[Trace]s[FSEvent]: File should not be processed: 'PolicyExclusion', allowing. Path: 'C:\Temp\mso113B.tmp' Db index: '3962'
t[140618T103945.235]p[1410:67]l[Trace]s[FSEvent]: Reply not required, ignoring. Accessing process: '', db index: '3962'
t[140618T103945.236]p[1410:67]l[Trace]s[FSEvent]: Reply not required, ignoring. Accessing process: '', db index: '3962'
t[140618T103945.239]p[1410:67]l[Trace]s[FSEvent]: NotifyFileProcessingFinish file 'C:\Temp\mso113B.tmp', archive 'False' allow access 'True', messages in process: '0'

Emphasis mine - you see the file will be ignored, however TE still has touched it causing the error.

I will take this up with TAC since this is blocking for a lot of our customers.

[Tim_McColgan]

Glad I'm not the only one Willem, although I feel your pain. No fix from TAC yet, very possible we found a bug and a patch/bug fix will be required. This is what they have said so far. Still troubleshooting. Hope to find a better answer. 

[Steve_Lander]

We are having this issue as well on our E80.83 clients, however if we print the document and select "Microsoft Print to PDF", there is no issue with saving the document as PDF this way.

[Steve_Lander]

Testing the E80.84 client, this still hasn't been fixed when exporting or saving as to pdf.

[Willem_Goethals]

It hasn't been fixed, no, but can be bypassed by adding the Microsoft Corporation certificate to the Monitoring Settings Action of the SandBlast Agent Forensics, Remediation And Anti-Ransomware Policy (oddly enough this affects the File System Monitor (Emulate Files Written to the System) in the SandBlast Agent Threat Extraction and Emulation.

You do this by going to Monitoring Settings (Clone Action) and going for Add Location -> Certificate -> browse to excel.exe -> it will add Microsoft Corporation as an exception. 

TAC led me to this solution. Apparently some Microsoft applications require "Exclusive Lock" and refuse to continue if another application (such as SandBlast) has a lock on the file for whatever reason. I have no idea as to the security implications of this change.

[Tim_McColgan]

That would definitely be my first question. What else am I bypassing by adding an exception for Microsoft Corporation? Is it excluding scanning and protecting of all MS product i.e. Internet Explorer, Word, even Operating Systems??

[PhoneBoy]

It would be any code signed with the same certificate.

Offhand, I don't know what applications that would apply to.

[Tim_McColgan]

I was told next release end of August it will be fixed. 

[Charris_Lappas]

I was told the fix will be on E80.87.....

Shame

[Oscar_Sumano]

I saw the same issue even in E80.85, from Word and Excel to PDF.

[Tom_Kendrick]

Please install the E80.87 client for resolved issues and let me know if it's not fixed.  As far as I know, it should be.

Willem Goethals - I would not use a solution based on a MS Signed certificate. it creates a Forensics monitoring exclusion that says "when a file is touched, by an application signed by this microsoft certificate, ignore any related forensics activities".

[Willem_Goethals]

I agree that using the certificate is not a good idea, but it was the only solution proposed by TAC until the release of E80.87. I have installed E80.87 and will remove the MS certificate and test, since I am curious if it will be fixed.

[Kim_Moberg]

Hi Willem

I’ve got a similar issue with e80.90 and e80.92 when opening powerpoint. Looked in TElog on my client and I wondering too why POWERPNT.EXE also had to emulated.

We got other programs too that are slow to load.

Did it solve your issue in E80.87?

We follow microsoft release train for Windows 10 feature ver 1809 so we are forced to upgrade to minimum E80.90. We tried to downgrade to E80.86 and everything worked normal again.

Best regards

Kim

[Willem_Goethals]

Hello Kim,

The issue was resolved in E80.87, yes. We mostly had problems exporting to pdf from Visio and Excel for example. We could remove Microsoft Corporation from the anti-ransomware Monitoring Settings excluded locations. I can only assume that all Microsoft products are again subject to TE. Default exclusions are Symantec, Trend Micro and McAfee. I actually prefer it this way since we can only assume that Microsoft products -could- be harnessed for ransomware purposes.

We are in the process of testing E80.90 with positive results, except for Internet Explorer which is unusable at this stage. I intend to install E80.92 today to see if there are improvements.

[PhoneBoy]

My understanding is E80.92 has improvements for IE.

[Willem_Goethals]

We're running it right now and it seems to have resolved most issues with IE indeed. Also, no reboot needed with upgrade from E80.90 which is useful.