599611 - Enable Structured Exception Handling Overwrite Protection (SEHOP) for firefox.exe

Status: RESOLVED WONTFIX

(Firefox :: Installer, enhancement, P5)

Description

[Masatoshi Kimura [:emk]]

Attachment: reg file to enable sehop for firefox.exe

This will improve malware protection on Windows 7. IE9 enables it by default.

Comment 1

[Masatoshi Kimura [:emk]]

Attachment: reg file to enable sehop for 32-bit firefox.exe on 64-bit Windows

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Feels like something we should do - :rs, opinions?

Comment 3

[Robert Strong (they/them - no direct email)]

I only looked at this briefly and am concerned about doing this late in the cycle. If we do this we should should do it as early as possible  and I can throw together a patch within the next 24 hours so the affects can be evaluated in beta 7.

Comment 4

[Benjamin Smedberg]

I am concerned about the effects of this on plugins, especially those which use JITs and may actually dynamically generate SEH tables. I'm pretty sure our own JITs don't. We do use static SEH in various places, but I presume that isn't affected by this.

Can somebody provide a MSDN/Microsoft link explaining what exactly the technical effects of this setting are?

In any case, not a blocker.

Comment 5

[Masatoshi Kimura [:emk]]

The technical detail is here:
http://www.uninformed.org/?v=5&a=2&t=txt
This page is linked from MSKB.
http://support.microsoft.com/kb/956607

Comment 6

[Masatoshi Kimura [:emk]]

Note that SEHOP is enabled by default in Windows Server 2008/2008 R2. If it causes any problems, they should have occured also on Win2k8.

Comment 7

[Marco Castelluccio [:marco]]

(In reply to Masatoshi Kimura [:emk] from comment #5)
> The technical detail is here:
> http://www.uninformed.org/?v=5&a=2&t=txt
> This page is linked from MSKB.
> http://support.microsoft.com/kb/956607

There are two compatibility issues (described in the 5th paragraph of the first link). The second shouldn't apply to us (the problem should appear with applications that hook ntdll!KiUserExceptionDispatcher and with antivirus software that classify the hooking of that function as malware), the first could harm if "the application invalidates the exception handler chain" legitimately (Cygwin and Skype for example don't work for this reason).

Is it enough if we test SEHOP with most used plugins (Flash, Java, etc.)?

Comment 8

[[Baboo]]

The attached reg files just activate SEHOP for firefox.exe so OOP plugins wouldn't be affected?

Comment 9

[Ian Melven :imelven]

(In reply to [Baboo] from comment #8)
> The attached reg files just activate SEHOP for firefox.exe so OOP plugins
> wouldn't be affected?

Right - i don't think this should be done for the plugin container - i believe the plugin authors should test their plugins with SEHOP and set it for their plugin process after verifying compatibility. 

I think we should definitely try to get this turned on for firefox.exe - but of course we need to verify it doesn't break anything.

Comment 10

[Ian Melven :imelven]

i've been running Nightly on Windows 7 with SEHOP turned on for about a week now and haven't noticed any issues so far, fwiw.

i suggest we make a patch for the installer that creates these two registry keys (so it will work on 32 and 64 bit Windows 7) and do a full try run, including the performance tests.

Comment 11

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Try doesn't use the installer, so it won't show you anything.

Comment 12

[Ian Melven :imelven]

(In reply to Kyle Huey [:khuey] ([e-mail]) from comment #11)
> Try doesn't use the installer, so it won't show you anything.

oh yeah :( thanks for pointing that out. trying to think of other ways to do this - i guess i could run the whole test suite on a Windows 7 box locally but this is a little painful unless i find a machine to use other than my main dev laptop. i thought about having firefox create the keys itself, but we would then need to restart the process after they've been created. i also couldn't find a good way to determine if SEHOP is actually enabled for a process via procexp etc...

Comment 13

[Ian Melven :imelven]

Just a note that i've now been running with SEHOP enabled for about a month and haven't noticed any issues. It was suggested that I work with releng to get the registry keys created on a machine I can run the full test suite including talos/performance tests on - I don't currently have time to push on this but will keep it on my long term to do list, anyone else should feel free to pick this work up :)

Comment 14

[Florian Bender]

Is this on anybody's radar?

Comment 15

[Tom Ritter [:tjr]]

We set this for the sandboxed process now, dodn't we Bob? I think we can resolve this.

Comment 16

[Tom Ritter [:tjr]]

*sandboxed processes

Comment 17

[Bob Owen (:bobowen)]

It's set for all the sandbox policies yes, but it looks like this bug is about setting the registry to enable it for all processes.

Comment 18

[Tom25519]

On my Windows 11 Enterprise 22H2 (10.0.22621.1413) VM, use Get-ProcessMitigation PID (e,g Get-ProcessMitigation 8080) command in powershell, it shows that SEHOP have been enabled by default almost all process type (at least parent process, RDD process, utility process, content process, extension process, network (socket?) process, GPU process), does this bug still need to keep open?

Comment 19

[Gian-Carlo Pascutto [:gcp]]

See last comment.

Comment 20

[Bob Owen (:bobowen)]

As I understand it this bug is only relevant to windows 7, because after that SEHOP is on by default.
It is on in all the sandboxed child processes on win7, this would force it on for all firefox.exe processes.
While will still have limited support for win7 on ESR115, I don't think we're going to put in the effort to see if this can be enabled without issues on all firefox processes at this point.