3 ms·
> It uses CVE-2019-9810 for getting code execution in both the content process as well as the parent process and CVE-2019-11708 to trick the parent process into
by est31 7y ago
> It uses CVE-2019-9810 for getting code execution in both the content process as well as the parent process and CVE-2019-11708 to trick the parent process into browsing to an arbitrary URL.
I wonder why is the privileged parent process even allowed to execute unsigned Javascript from the network? IIRC it already has eval support turned off. I get that it's hard to get rid of privileged Javascript completely (Servo thankfully made the choice early on to not do that at all), but is there any feature that requires downloading & executing Javascript from the network in the privileged parent process?
- kevingadd 7y agoSigned javascript isn't really a concept that exists anywhere. I'd love it if it did, it's a gaping hole in the internet security model. Mainline FF loads lots of unsigned user-controlled JS as-is (prefs.js, for example) so the closest thing you get is signing on entire extension bundles. There is the Subresource Integrity mechanism (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) as a stopgap for this but it doesn't really provide something useful in this case because the load target has to be known in advance and you can't provide a hash for top-level content in the URL.
- est31 7y agoAdd ons must be signed by Mozilla I think. Also, add ons that have privileged access require a special signature that Mozilla only uses for their own add ons. That's what I meant with signed Javascript. Anyway, this wasn't my main point. It's why you load and execute Javascript from the network in the first place in the content process. It feels to me that banning JS loading would have helped here a great deal and would make exploitation of similar bugs much harder.