Segfault in libxul

[q160765803]

I can add this nullcheck but be aware that in many places in window handling it is assumed mDoc exists after initial load, and that this situation caused by NoScript will likely have many more crash potentials. As far as crashes on a freed document go, a null deref is fairly safe. A UAF resulting from the same (e.g. by moving the crash point to somewhere else with this added nullcheck) would not be safe, and that would be an exploitable security bug. So, tread very carefully.

This leads to 2 questions:

1. Why mDoc can be NULLed by javscript/extensions?

2. If it is allowed to NULL mDoc, then why mDoc can be used without null-check?

[RealityRipple]

Off-topic:
The whole point of XUL is to allow JavaScript to do anything, and it's up to the extension developer to not be a moron, and the user not to install bad extensions. A mindset that has essentially vanished from the browser world, leading to ever greater laziness.

[Moonchild]

Why mDoc can be NULLed by javscript/extensions?

Extensions can do all sorts of potentially dangerous or stupid things with the APIs that are available to them. As I've said many times before, with great power comes great responsibility. The unfettered power to redefine how the browser works (and being able to reach deep into the internals of the application) comes with the big caveat that you should know what you're doing as an extension developer and make sure you understand an API completely before you make use of it. And I think that's where NoScript has erred -- APIs and functions are being called without understanding what the result of such calls is.

If it is allowed to NULL mDoc, then why mDoc can be used without null-check?

I'm pretty sure this isn't done directly, but through an uneducated call to an internal API somewhere having the end result that mDoc is nulled. Doesn't mean it should be done, but it's allowed to be done.
Similarly, it is technically allowed to, for example, shut down and restart application components, as in, there are no mechanisms in place preventing extensions from doing these things (which would also directly limit the extensibility of the application!). But doing so could leave the application in an undefined or (semi-)broken state if not done taking the normal processes that use those components into account. So the question shouldn't be "why is this allowed?" but rather "you can do this, but do you know what the consequences are?"