Discussion in 'other anti-malware software' started by BoerenkoolMetWorst, May 1, 2015.
absolutely rubbish. neither nor any browser or program has a "sandbox" - some parts are running with limited rights for purpose.
and in detail all adobe programs can use that "protected mode" - example for flash (others are similar)
IE dont need a flash-exe, its starts flash directly in protected mode as firefox (since v35) is now capable with plugin-container.exe
(plugin-container.exe starts flash-plugin with such limited rights)
to replace the linked ocx-file you need to corrupt the present installation which is only possible as admin and some need to know where to screw in system registry because adobe flash protects itself against attacks (and such nonsense).
since windows 8 flash become part of windows itself. without screwing in the gpo (only available wit win8 pro or higher) it is possible to deactivate flash completely in IE. no flash at all is not really needed to discuss here, its a personal decision.
so if you corrupt the installation windows 8 will repair it as fast as possible
at least paid sandboxie users are capable to force flash-folders into a box and lock the box against outside system, internet and other access. so i do.
last - dont trust any other distributor if you dont trust the original at all, thats like wearing alu helmets.
It works on both the 32bit and 64bit version of Windows 7, because on the default configuration of Windows 7 64bit the IE just uses the 32bit Flash Player to render Flash contents.
Below are screen shots showing that the above statement is B.S.
FWIW: This guy is a top-tier researcher working for McAfee. Not a random Internet user.
Well, actually he is right.
64-bit Flash.ocx on Windows 7 is not 64-bit but 32-bit.
Some time ago I checked 64-bit IE8/11 on Win7 vs 64-bit IE10 on Win8 and I noticed the following:
- Most of the dlls used by 64-bit IE8/11 processes on Windows 7 are 64-bit, but several dlls like Flash.ocx, kernel32.dll and ntdll.dll are still 32-bit. (iirc)
- 64-bit IE10 on Windows 8 was actually only using 64-bit dlls.
(Currently I don't have a machine stand-by on which I can take some screenshots of WinDbg showing the 32-bit Flash.ocx dll in a 64-bit IE11 process)
Their are two separate directories for Flash; one for the 32 bit version and one for the 64 bit version. Both are populated in a Flashplayer download.
The screen shot I posted clearly shows the 64 bit .ocx version plug-in in my IE 10. Also the screen shot of the Flash launcher clearly shows it is 64 bit.
I interpret what the author to mean is that in an initial install of x64 WIN 7, it installs IE 9, I believe, and that version is indeed 32 bit. Well, who is still running IE 9 anymore? The first thing a person will do is if they want to use IE as their browser will be to update IE.
x64 (Windows 7)
x86 on x64 (Windows 7)
x86 on x86 (Windows 8.1)
similar for the plugin-dll (Firefox)
x64 dll and ocx are ~6megs larger than x86 (22megs <> 16megs)
thx for pointing it out, itman.
Maybe Ropchain was referring to what I show in the screen shot below. IE x64 does load both x86 and x64 .ocx modules. I have to assume though since the IE plug-in specified is x64, it is using that .ocx plug-in? However if the FlashPlayer content is x86, perhaps Flash uses the x86 .ocx instead?
I think I did see instances of this in the past. I have both versions protected by EMET. Plus it's default rule for IE includes both by coding it as Flash*.ocx for EAF+.
Sorry, at the moment I am not going to prepare a Win7 x64 vm for additional verification
I found the details this developer based his assumptions on here: http://blog.nanotoolkit.com/post/2013/10/14/IE-9-IE10-IE11-and-Three-Shades-on-Windows-X64
If you scroll down to the end of the article, you will find this:
For illustration purposes I went to youtube.com which uses Flash. Thanks to SysInternals’ Process Explorer which allows one to explore what Dlls Any Given Process has loaded I am able to Find out which .OCX (Active X) is actually IE10’s Worker Process using for brining flash to you. But as mentioned before this is an over-simplication; since the Flash OCX launches a 64-bit Flash Process that does the grunt of the work. But further exploration of that process is out of the scope of this article. Please Observe that the Flash OCX is actually under C:\Windows\SysWOW64\ which implies it is indeed a 32-bit component.
Well, this was written in fall, 2013. My observation is this is no longer the case. When I play Flash content, everything loaded is sourced in the C:\Windows\System32 directory. I verified this by opening EMET GUI and observing what was in use. I also believe Abode made Flash fully x64 compatible in 2014?
Only way to know for sure is fire up Process Explorer and look into the details of both .ocx's and see which one is active when Flash content is playing. I am sure ropchain will be doing this.
-EDIT- You can run a x86 .ocx using DllSurrogate function from a x64 process in limited conditions but I see no reason why Flash would still be doing this.
IMO it was earlier. some can verify with downloads from the adobe archive - i dont really care about, reason i wrote in my first answer.
btw not only IE is using flash, some third-party programs need it too, therefore it must be always latest build (not beta).
Below is posted a screen shot that indeed proves that the x64 Flash .ocx is running and being used. So again I say, double rubbish to all this.
Also, I have an explanation for why IE x64 loads both x86 and x64 .ocx modules. It has to due with EPM. By default EPM is not set on for all IE x64 zones. For example, it is not set on for the Trusted Zone. Also in my EMET testing I have found out that even if EPM is set on for the Trusted Zone, IE 10 will still run all urls defined in that zone with EPM off. Thank MS for that screw up. By default EPM is set on for the Internet zone. As such, no add-on that is not x64 based will be allowed to run.
However, let us say that some x86 Flash content is served up by a web site included in the Trusted Zone. I strongly suspect IE will allow the Flash x86 plug-in to run. Keep this in mind when defining web sites to run out of the Trusted Zone.
I have a better idea, use MBAE or HMPA instead, for more extensive protection.
Separate names with a comma.