This is one of those situations where the author's simplification makes his assessment dangerously misleading. In the case of DEP+ASLR, there's rarely any value in doing it partway. If every executable image in your process does not have DEP+ASLR, then the protection is often worthless because either the attacker will be able to generate executable pages or will have enough predictable surface for a ROP chain. However, to make that assessment against an application you also have to verify what the files are and when/where they're actually loaded. And of course, you have to look at how the rest of the application runs to verify it doesn't undermine the protection provided by ASLR+DEP (e.g. Java historically allocated all memory RWX, making DEP pointless).<p>Since I know Chrome well I can use it as an example assessment. The first thing he mentions is xinput1_3.dll, and he correctly notes that this is used only when a gamepad is connected. What he doesn't mention is it's used only on Windows XP, which has no ASLR support. Since DEP is essentially worthless without ASLR, this file doesn't really have any negative security impact. Of course, it would be best if this DLL simply had ASLR+DEP enabled, but unfortunately it's part of Microsoft's DX library and MS doesn't see the point in changing it (for the reasons I've described).<p>As for the oddly named installer files, they look like differential updaters, which are temporary files created during an update. They don't handle any malicious data because all of the data is embedded in the executable file and the whole binary's signature is verified before it's run. I'm not sure if there's something preventing ASLR+DEP on these files. I'd have to check with the Omaha project <a href="http://code.google.com/p/omaha/" rel="nofollow">http://code.google.com/p/omaha/</a> to verify, since they're a separate project and I just don't know it as well as Chrome.
Why look at Firefox 11 when Firefox 17 is the current release?
3 out of 36 is the current result for Firefox, much better than 13 out of 34.<p>No DEP, No ASLR: /Mozilla Firefox/maintenanceservice_installer.exe<p>No DEP, No ASLR: /Mozilla Firefox/webapp-uninstaller.exe<p>No DEP, No ASLR: /Mozilla Firefox/uninstall/helper.exe
Respective linker flags are:<p><pre><code> ASLR -> /DYNAMICBASE
DEP -> /NXCOMPAT
</code></pre>
From Wikipedia:<p><pre><code> Vista, Windows Server 2008, Windows 7, and Windows Server
2008 R2 have ASLR enabled by default, although only for
those executables and dynamic link libraries specifically
linked to be ASLR-enabled.
</code></pre>
That's by default. You can also force ASLR to be applied to any app by installing EMET and configuring it respectively -<p><pre><code> http://www.microsoft.com/en-us/download/details.aspx?id=30424
</code></pre>
EMET also allows changing DEP protection from Opt-In to Opt-Out, which is obviously a good thing.<p>[1] ASLR -- <a href="http://en.wikipedia.org/wiki/Address_space_layout_randomization" rel="nofollow">http://en.wikipedia.org/wiki/Address_space_layout_randomizat...</a><p>[2] DEP -- <a href="http://en.wikipedia.org/wiki/Data_Execution_Prevention" rel="nofollow">http://en.wikipedia.org/wiki/Data_Execution_Prevention</a>
tl;dr: Even common Windows apps with massive user bases are still horrible about using even the most basic security features. Please use EMET on Windows to force these protections.<p><a href="http://en.wikipedia.org/wiki/Data_Execution_Prevention" rel="nofollow">http://en.wikipedia.org/wiki/Data_Execution_Prevention</a><p><a href="http://en.wikipedia.org/wiki/Address_space_layout_randomization" rel="nofollow">http://en.wikipedia.org/wiki/Address_space_layout_randomizat...</a><p><a href="http://www.microsoft.com/en-us/download/details.aspx?id=30424" rel="nofollow">http://www.microsoft.com/en-us/download/details.aspx?id=3042...</a>
"The main binary is unprotected from DEP. Likely for backwards compatibility with sloppy plugins."<p>I think IE uses SetProcessDEPPolicy instead of /NXCOMPAT.