Keeping up with Security

[person]

Hey, just a small Q about Keeping up with security vs Firefox,
The biggest argument thrown back against using palemoon is that palemoon lags significantly behind that of firefox in patching/backporting vulns and so PM is not secure. CVE-2015-2710 is an example thrown out there..
I'm partly of the mindset that if something is not being actively exploited then people shouldn't stress over small delays in patching. tbh I have major gripes with standard settings in firefox and consider those ongoing exploits.

I've been split between the two for a long time, less so now as edging back toward a personalised ff chasing stupid settings each update and watching their buisness model go rotten is no fun though.

Can anyone allay my concerns about palemoon being too far behind? It does nag when everything goes quiet here for a while
Many thanks for the hard work and providing an alternative guys.

[Moonchild]

I'm not sure where your concerns come from.

The moment I am given access to the MozSec bugs after each 6-week release, I perform a full security audit on the bugs and code for applicability. If a vulnerability exists in Pale Moon that is addressed by these bugs, it is patched in the next release, with chemspill releases for urgent security issues pushed out asap in a point release.

CVE-2015-2710 is N/A for Pale Moon (I double-checked just now). It is a heap buffer overflow crash, that can allow arbitrary code execution if triggered. However, Pale Moon doesn't crash, and is unaffected by this problem because the applicable code isn't vulnerable in our code base.

Just because you don't see a vulnerability listed doesn't mean that it is present and not patched (you're assuming then that we are not a fork).
If it's not listed you can safely assume that it's not applicable to this browser. If you think that our code base is still that close to Firefox, then you haven't been paying attention for the past 2 years

[New Tobin Paradigm]

One thing to keep in mind is that just because there is a vulnerability in a codebase doesn't mean that there always was a vulnerability. As most know, Mozilla has been rewriting code (refactoring) at a rabid pace and has actually introduced more security flaws just by refactoring and rewriting the code badly than were previously there in the older incarnation of a chunk of code.

[person]

Cheers for taking time out to reply guys, much appreciated & reminder about point releases is reassuring.

[squarefractal]

I'm not sure where your concerns come from.

https://www.reddit.com/r/privacy/commen ... f=readnext

[–]oxychromaticdynamite 2 points 1 month ago*

They can claim all they want. There is absolutely no way they have backported patches for all the security holes, especially when in many cases the full information about the holes is still not public. In many cases they wouldn't even be able to verify if they are vulnerable or not because the PoCs are indefinitely kept private.

Practical demonstration: CVE-2015-2710 was announced on May 12 when Firefox ESR 31.7.0 was released. The patches that fixed it: one and two. Pale Moon has not applied these fixes, we can see here that it doesn't return early if the length overruns the bounds and here it doesn't check if the frame is empty.

So there is at least one critical vulnerability that Pale Moon is still vulnerable to.

[Moonchild]

Poked a reddit-goer to relay some information in that thread.

[Night Wing]

The user on Reddit, "oxychromaticdynamite" is a "know it all" who DOESN'T know it all when it comes to Pale Moon since he DOESN'T use Pale Moon.

[Moonchild]

The user on Reddit, "oxychromaticdynamite" is a "know it all" who DOESN'T know it all when it comes to Pale Moon since he DOESN'T use Pale Moon.

I actually can't even read quite a few of his comments because they show as gibberish. XD

But yes, the user obviously has no clue about how security bugs are handled by me, and instead of actually asking, just jumping to conclusions and finding "evidence" about "unpatched vulnerabilities" that aren't vulnerabilities.

If our code isn't vulnerable, then there is also no reason to add (unnecessary) extra checking code to work around a non-existing problem. I tested with the (as of yet still undisclosed) proofs of concept and crash tests, and Pale Moon happily doesn't overflow the buffer and doesn't crash, no matter how hard I've tried

So yes, it's correctly asserted that there is no overflow check where Mozilla added one when they patched their code, but it should be noted that that is because there is no overflow danger (and I have a good idea when Firefox became vulnerable to this, which is not an issue for us). It could still be patched as a defense-in-depth precaution, in case it may - theoretically - become vulnerable in the future, if that would make overly concerned people happy - making it a direct reflection of the "security state of Pale Moon" is BS, however, since DiD is precautionary "just in case our code is going to change in such a way that it becomes a hazard". It's certainly not something that "is a security hazard" in its current state or considered critical.

We neither can nor are obligated to apply all patches that exist for a different product. In fact, blindly doing so may break our product with a relatively high degree of certainty in quite a few cases.

[LimboSlam]

Way to tell him MC! I think I'll use this whenever someone says, "pale moon is not secure enough because it has unpatched security holes" and "palemoon is not a good browser for security purposes because they haven't patched the recent exploits found."

We neither can nor are obligated to apply all patches that exist for a different product. In fact, blindly doing so may break our product with a relatively high degree of certainty in quite a few cases.

[squarefractal]

Although not exploitable, a defense-in-depth patch has been applied for that code:
https://github.com/MoonchildProductions ... 08acab3a41