Page 1 of 1

PM x64 33.x crash with noscript

Posted: Sun Mar 24, 2024 2:07 pm
by cartel
both 33 versions do it. 32.5.2 doesnt
been using noscript over 10 years and never had issues before
PM will not crash when noscript is disabled

https://9xbuddy.in/process?url=https%3A ... 1456915718

this link I click
Image

windows 7

Faulting application name: palemoon.exe, version: 6.6.0.8791, time stamp: 0x65b36ab8
Faulting module name: xul.dll, version: 6.6.0.8791, time stamp: 0x65b36c84
Exception code: 0xc0000005
Fault offset: 0x0000000000849dff
Faulting process id: 0xf28
Faulting application start time: 0x01da6cb65d63a83c
Faulting application path: C:\Program Files\Pale Moon\palemoon.exe
Faulting module path: C:\Program Files\Pale Moon\xul.dll

Image

then to top it off I get these popovers without noscript and when I try to inspect element it redirects the developer tools to debugger.

https://forum.palemoon.org/download/fil ... =18545&t=1

the popover spam is blocked by noscript and I am protected




the tiktok link is blocked

Image

I allow it the video plays:

Image

the popover spam is blocked by noscript and I am protected

Re: PM x64 33.x crash with noscript

Posted: Sun Mar 24, 2024 2:24 pm
by cartel
I tried to get help at PM forum but was stonewalled:
by Moonchild » Sat Mar 02, 2024 11:31 am
Cartel you've been around here for a very long time now with almost 500 posts to your name.
Why on earth are you still not understanding we... do... not... support... installations... with... NoScript?
It is well-known it causes stability issues, not in the least because it can block browser-internal scripts literally breaking the application. Yes that includes appcrashes. Undefined behaviour with blocked components or components having been yanked out from under a running script driving the UI can also lead to exploitable security issues (??).
I been using noscript for over 10 years, closer to 15 years and its been something I cant live without.
I never had a virus in all this time.
The alternative umatrix just doent cut it and is confusing and annoying.

I guess I have no choice but to not update my browser anymore

Re: PM x64 33.x crash with noscript

Posted: Mon Mar 25, 2024 2:15 pm
by therube
Use SeaMonkey (where NoScript still works).
Use older version of PM (where NoScript still works).

Wait, if it ever happens, until PM changes something to where NoScript works again (without crashing on video).
And a link to the PM threads would have been nice.

Even the thread where they were some were offering to pay for a "fixed" NoScript (& even if they, instead of being glad that NoScript exists, still harped on it).


I'm glad NoScript exits - in all its incarnations.
Thank you. :-).

Re: PM x64 33.x crash with noscript

Posted: Wed Apr 17, 2024 1:55 am
by cartel

Re: PM x64 33.x crash with noscript

Posted: Fri May 31, 2024 3:10 pm
by therube
Just so you know, if you change the NoScript's "GUID" (in install.rdf, in noscript...xpi), NoScript will install in current PaleMoon.


"Install" does not change any potential negative consequences (like PM crashing), but at least it can be used, till then ;-).


Something like this does the trick:

STEVENscript-5.1.9rc1+THERUBE (to bypass PM block on NoScript ;- )).xpi:

Code: Select all

   <em:id>{73a6fe31-595d-460b-a920-fcc0f8842121}</em:id>
   <em:name>STEVENScript 5.1.9rc1+HACK</em:name>
Here, [link removed by barbaz]
SHA1: B7EADF321D136CB948E20CC676FDBA06B4D4D329



BTW, don't bother going to the PM forums for help ;-).

Re: PM x64 33.x crash with noscript

Posted: Fri May 31, 2024 11:57 pm
by barbaz
therube wrote: Fri May 31, 2024 3:10 pm Just so you know, if you change the NoScript's "GUID" (in install.rdf, in noscript...xpi), NoScript will install in current PaleMoon.


"Install" does not change any potential negative consequences (like PM crashing),
... but OP started this thread because they do get the crash, so in their case the block list entry for NoScript is 100% called for, so how does this help? Image

Crashes can greatly increase attack surface. Are you REALLY sure this crash isn't exploitable?

The only reason to circumvent the block list is if you're trying to troubleshoot/diagnose/fix the crash & want to reproduce it without disabling the block list. That change is *not* for end-users who just want to use NoScript. I removed the link to the ready-modified XPI, since the only people for whom such change might be constructive would find it trivial to do it themselves.

Even if the crash can be stopped, are we sure NoScript Classic would even work in current Pale Moon? UXP has surely changed a lot in the last years, has anyone actually tested NoScript Classic in current Pale Moon? A false sense of security is worse than no sense of security.