User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 Firefox 3 currently sets the /NXCOMPAT linker flag to enable Data Execution Prevention for itself under Vista. However, this doesn't work under XP, because XP doesn't recognize the /NXCOMPAT header bit. Firefox ought to call SetProcessDEPPolicy to enable Data Execution Prevention on itself if the call exists. It was added to XP 32 in Service Pack 3. It is not possible, barring nasty hacks with spawning a child process, to enable DEP in Firefox on an "OptIn" system66 under XP 32 SP2 or XP 64 SP2. SetProcessDEPPolicy plus /NXCOMPAT covers as much ground as realistically possible. (/NXCOMPAT covers Vista RTM, which didn't have SetProcessDEPPolicy.) Reproducible: Always Steps to Reproduce: 1. Set XP's Data Execution Prevention to "OptIn", the default. 2. Run Firefox under XP 32 SP3. 3. Cause Firefox to execute code from a data page. Actual Results: The code works. Expected Results: An exception should occur. http://msdn.microsoft.com/en-us/library/bb736299(VS.85).aspx It might be wise to continue to allow ATL thunk emulation so that "IE tab" can still work with ActiveX plugins for IE that don't like NX.

We should get this done for 1.9.1.x; it won't help people on SP2, but as mentioned in comment #0, we should cover as much ground as possible.

I really mean "badly wanted for 1.9.1.2" with my nomination, but we don't have wanted-1.9.1 or wanted-1.9.1.2 or wanted-1.9.1x or blocking-any-of-those, so this is as close as I could make it.

blocking 1.9.1 maybe? Well someone will sort it out I hope :)

This dynamically loads and calls SetProcessDEPPolicy if it is available.

I'll concur with gal here. Getting heap DEP working on as many windows variants as possible should be very high priority. (Also consider workaround N+1: if you can't convince the loader and heap-setup code to do it, you might still be in a condition that VirtualProtect could force it page-by-page inside jemalloc. Maybe? Worth considering?)

Comment on attachment 388698 [details] [diff] [review] Call SetProcessDEPPolicy if available, rev. 1 [Checkin: Comment 10 & 13] Code looks fine. A comment explaining what this is doing or a reference to this bug# might be a good idea.

Does this actually enable the ATL thunk workaround at the original comment suggested?

(In reply to comment #8) > Does this actually enable the ATL thunk workaround at the original comment > suggested? I don't think PROCESS_DEP_DISABLE_ATL_THUNK_EMULATION is required because /NXCOMPAT also disables the ATL thunk emulation. http://support.microsoft.com/kb/948468

I think we should definitively take this for 3.5.2. This would have stopped/disarmed the issue published 3 days ago.

Comment on attachment 388698 [details] [diff] [review] Call SetProcessDEPPolicy if available, rev. 1 [Checkin: Comment 10 & 13] a1912=beltzner

What is the best/simplest way for QA to verify this bug for Firefox 3.5.2? (I find the original STR to be a bit too technical -- steps to perform step 1 and a test URL for step 3 would help...)

I don't think there is a way to test this without writing a test extension or finding an exploitable JIT bug.

You could back out the fix for the heap spray attack and then use the shell code in that bug to test this.

Comment on attachment 388698 [details] [diff] [review] Call SetProcessDEPPolicy if available, rev. 1 [Checkin: Comment 10 & 13] Approved for 1.9.0.14, a=dveditz for release-drivers

Here an example of how the bug can be reproduced (for anyone interested, even though the bug is marked 'resolved'): 1) Start Firefox. 2) And now (after Firefox is initialized, which is important if we are to test whether Firefox calls SetProcessDEPPolicy) attach the OllyDbg debugger to the Firefox process (this should automatically pause the process). 3) Insert some valid assembly code (e.g. a simple 'nop' will do) in the .data section (use View -> Memory to find the .data section). 4) Set the EIP register to the starting offset of the code inserted at step 3. (View -> CPU. Then press CTRL+G or right-click -> Go to -> Expression. There insert the offset. Then CTRL+NUMPAD* or right-click -> New origin here.) 5) Press F8 or Debug -> Step over. 6) If OllyDbg displays 'Access violation when executing ...' in the status bar, the bug is indeed fixed. Using these steps, the bug should not be reproducable with Firefox 3.5.2. Hope someone finds this interesting/useful.

Checking in toolkit/xre/nsAppRunner.cpp; /cvsroot/mozilla/toolkit/xre/nsAppRunner.cpp,v <-- nsAppRunner.cpp new revision: 1.219; previous revision: 1.218 done