I don't know if anyone has reviewed the Windows WDEG Security - Mitigation log after this recent update, but this is what is being generated on every Adobe Reader startup: Tried various fixes including removing the existing RdfCEF.exe rule in WDEG to no avail. The WDEG blocking does not appear to have any impact on Adobe Reader DC operation.
What is interesting about this issue is "Disable Win32K system calls" is supposedly a WDEG app level only mitigation. It is definitely not set on in the default RdfCEF.exe rule in WDEG. So I will have to check the optional Powershell based WDEG mitigations to see if one of those is the culprit although I doubt it.
I'm wondering if the Adobe team has attempted to enable the Win32k filter which Chrome uses. I know that they had adopted Chrome's sandbox a while back, then went even further to have an AppContainer (beta) option. The next logical step would be for Adobe to try enabling the Win32k filter which may potentially be "baked in" and therefore occurs upon execution. I haven't noticed this yet so I can't confirm just yet.
I don't use Chrome and don't have it installed. What I did notice is that RdfCEF.exe starts up at the same time that Reader starts. It runs at medium integrity level and spawns a child process running at low integrity level. So that might have something to do with it. Again, since the Disable Win32k system calls is app controlled and is not enabled for RdfCEF.exe, cannot see why the mitigation is being triggered in the first place. As you noted, I wonder if there is a way an app can enable/disable WDEG mitigations. If so, that would be scary indeed. It would also imply that one or more WDEG app level mitigations have opt-in capability.
I can confirm now that I am getting the exact same entries in event viewer for RdrCEF.exe as well. What I meant to say is that Adobe utilized the same sandbox code from the Chromium project for Adobe's own sandbox code. The CEF stands for Chromium Embedded Framework (https://en.wikipedia.org/wiki/Chromium_Embedded_Framework). So it looks like Adobe also pulled in Chrome's recent built-in usage of Win32k Lockdown mitigation.
Which means this is a bug in my book and Adobe is inadvertently blocking its own Win32k system calls.
I also found this "tidbit" in regards to RdrCEF.exe: https://securityinaction.wordpress.com/tag/rdrcef-exe/
It get worse ............. As I posted previously when reader is opened off line, the child process spawned from RdrCEF.exe loads with low integrity. However when viewing a .pdf from your browser add-on/plug-in, RdrCEF.exe loads untrusted as shown in the below screen shot: Now the question is why is something clearly Chrome related being loaded when IE11 is being used? This has to be spyware related is the only conclusion I can come up with. There might be a way to stop this however. I didn't mention this previously, but I did reinstall this lastest Reader DC version. I have Eset's HIPS monitoring any .exe startup activity from %AppData%/Local/Temp directory. I remember receiving an alert during the Reader installation about it wanting to install Chrome "core" installation components although I had specifically unchecked all options presented on the installer startup screen. So I might try a reinstall specifically blocking this Chrome "core" baloney and see if it will allow the rest of Reader DC to install properly.
Problem solved. I am just blocking RdrCEF.exe startup with Eset's HIPS. Adobe Reader AppContainer instance runs just fine w/o it.
There is one other likely use of RdrCEF.exe. First, this is the first Abobe Reader DC update after the Meltdown/Spectre debacle. Next, look closely at the code being run as posted in my PE screen shot. My guess if these are related to Spectre - variant 1 mitigations. Also, it appears Adobe is taking the "hatchet" approach and blocking any Win32k system calls from RdrCEF.exe as further security against speculative execution interception. All this makes sense in light of Abode Reader's cloud interface. Since I only use Adobe Reader for reading non-sensitive .pdf files primarily downloaded/viewed from the Internet, I am going to continue to block RdrCEF.exe. For anyone using Adobe Reader via its cloud or that contain sensitive data, they may want to keep RdrCEF.exe fully functional.
Blocking execution of RdrCEF.exe seems to have zero negative effects and essentially prevents Chrome (outdated, version 59) from running inside of Adobe Reader. An added bonus: Adobe Reader seems to start instantaneously now! Seems as though when a trusted PDF is loaded, it is loaded within a Low IL AppContainer. PDF's which originate from the web (likely mark of the web) load within another sub-process (Protected Mode / Protected View) Untrusted IL AppContainer which is further restricted.
Yeah, it appears Adobe forgot to disable it when the AppContainer option is enabled. Also appears the Chrome framework's primary purpose was for sandboxing purposes. I assume once Adobe makes AppContainer non-beta, they will get rid of the Chrome framework.
@WildByDesign here is something to check out. Leave it to Comodo to come up with a "doozy." Check out this .pdf: https://www.comodo.com/ctrlquarterlyreport/2017summary/Comodo_2017Report.pdf . Below is a screen shot of what occurred for me and I have never seen anything like it. IE11 spawned a "virtualized" 32 bit process running at low IL. I then got an Eset HIPS alert that IE11 x(86) wanted to modify Adobe Reader. This in itself not suspect because IE11 x(64) child process does the same. However, that IE11 instance is running in AppContainer. To date, I have never see this IE11 x(86) spawned child process behavior when reading a .pdf via IE11. The only time I have observer IE11 x(64) spawn a x(86) child process is when a URL exists in "Trusted Web Sites" section and the default EPM setting of "off" exists. I currently have no URLs loaded in Trusted Web Sites. Note: I do not have Hyper-V installed in Win 10 x(64) 1709. So it is beyond me how IE11 x(86) can start virtualized? -EDIT- Just realized I have WDEG SimExec mitigation enabled for IE11. Perhaps that forces 32 bit processes to run virtualized? If so that is neat! It would also explain why IE11 x(86) process not running in AppContainer. Appears it is "either -or" there. This also brings up another interesting option to explore. That is running Abode Reader DC virtualized via use of WDEG SimExec mitigation versus AppContainer.
Appears WDEG SimExec mitigation has no effect on Adobe Reader DC in regards to running virtualized. So I assume MS just forces the IE11 x(86) to open as such. Another glitch I noticed is this recent version of Adobe Reader DC does not run with CFG enabled.
There are two underlying problems here. First, CFG has to be instrumented into the binary itself at compile time. So for exampled, enabling the CFG mitigation in WDEG on a binary which was not instrumented with CFG at compile time would not technically be running with CFG protection despite what Process Hacker or Process Explorer may show. A good way to show the instrumentation details of CFG is via peview.exe within Process Hacker (Tools - Inspect executable file...) There will be a CFG tab only if a binary truly has CFG instrumented in. Adobe is not really known for utilizing CFG yet for any of their products, as far as I know. I don't know why they seem to always lag behind in security instead of taking advantage of the latest operating system security mitigations. The other problem is that Adobe Reader DC is a 32-bit application. You could, in theory, instrument CFG into a 32-bit binary, but it would be nowhere near as secure as a 64-bit binary with CFG. If you look at the "Virtual Size" of a 64-bit CFG mitigated process you will notice that the virtual memory size is 2TB on latest Windows 10 OS. I don't have a testing build of x86 Windows 10 available at the moment, but it is nowhere near 2TB virtual size for the process memory. It's significantly lower but I just don't have access to the number off the top of my head. So the amount of entropy available to a 64-bit CFG enabled process is vastly higher whereas a 32-bit CFG enabled process can have CFG defeated much more efficiently and therefore CFG on 32-bit processes is not really worth while for the most part. 32-bit processes with CFG enabled may also have more of a negative perf impact as well.
@WildByDesign here's something interesting. Appears ADR DC dynamically creates Win firewall rules when a .pdf is opened in protected mode. Check your Win firewall event log. It will delete any existing rule and create a new one. The rule is to block any inbound traffic from ADR DC. ADR does this regardless of if you're using a third party firewall and that firewall is managing WD firewall settings. Proof that WD firewall is really never fully disabled. Also, that your third party firewall needs to allow inbound WD firewall rules.
@itman That is really quite a fascinating find. Thank you for sharing. Several interesting points there which I will have to test later as well out of curiosity.
I guess I should clarify that it is not a Win firewall rule per se that is being created. Rather, it is a Win firewall exception rule. Appears Win firewall exception rules are active regards of if a third party firewall is used and controlling Win firewall usage. So to correct what I previously stated, usage or not of Win firewall inbound rules is N/A. Also and of most interest, appears apps at least apps like Adobe Reader DC can create Win firewall exception rules at will. Now the question is if malware can do the same? Suspect that it is the case if it can acquire the necessary privileges. Do we have a major security vulnerability here?
Any program with admin privilege can make exception rule, and I don't count it as a weakness nor vulnerability. Adobe Reader itself doesn't run with admin priv, but upon installation it installs update service so it can do privileged work w/out causing UAC prompt, tho not sure if mentioned activity has actually sth to do w/ the service.
