From Newsgroup: alt.comp.freeware
JJ <
jj4public@gmail.com> wrote:
VanguardLH wrote:
What I couldn't tell from the CVE reports mentioned by Shadow is whether
or not the memory reuse vulnerability was in Javascript interpreter in
Firefox, as Shadow and yeti surmised rather blindly, or in some other
part of Firefox. As you say, disabling Javascript in web docs won't
affect Javascript employed elsewhere. Plus, the CVEs only mention some
memory pointer reuse, and never mentioned Javascript at all nor the
vulnerability was only within the scope of Javascript employed in
malicious web docs.
It's likely both. Disability API requires JS to access, and memory
management is beyond the reach of JS code.
Unless I'm mistaken, I thought proper and automatic memory management
was supposed to be a thing in JS. So, the defect is in the API that is
part of Firefox, not in the web doc's JS that accesses the API, and
disabling JS only has scope on the web docs. When the CVE mentions
memory reuse after release, didn't seem JS could do that. In C, you
code the malloc() and free(), so devs were responsible for memory
management. The JS engine does the alloc and free, and the JS engine
decides when to release (garbage collection). Automatic memory
management in JS is supposed to avoid memory related issues that were
too often ailments in poorly coded C.
While the API was mentioned, it's possible the JS engine had a defect in
its memory management. The JS engine devs can't get everything perfect. However, you'd think the CVEs would target the JS engine as the cause,
and not an API which could be written in anything, like C.
The first CVE may be a bug in Disability API object destruction routine. The second CVE may be a long standing bug in Firefox's general memory
management.
I always suspect that, Firefox's memory management has a problem which kept piling up little by little getting ready to blow up. If you use Firefox as your main browser, you might be aware of its long standing memory leak problem. Most notably, when browsing search results and accessing result items back and forth in Google Maps.
Unlike some users, I never leave the web browser running 24x7. I use
it, then I exit it. Even in Firefox Android, I use its Quit menu entry
to unload it rather than let Android leave it running in the background
until whenever its memory is needed for a newly loaded app. I don't
have more than a dozen tabs open at a time. So, I never encountered a
big memory footprint with Firefox, but then my use wouldn't tax it.
When I saw someone complaining about Firefox's memory footprint size,
they left Firefox running all the time, even when not using it, had
hundreds of open tabs, and left it configured to run background jobs
after it supposedly exited.
I remember when Mozilla belatedly moved to isolated processes to better stabilize Firefox that there was a swarm of user reactions regarding
memory consumption. But once you learned about Electrolysis in Firefox,
those concerns faded, so the ever growing memory footprint of Firefox
got rather forgotten. The big change masked the little problem.
With uBlock Origin still usable in Firefox, you could define it to block
3rd-party scripts, but not 1st-party scripts.
IMO, the uBlock Origin's colored filter UI design is flawed. We have to
block the domain name in order to block 1st party scripts of the current site. The "1st-party" setting alone doesn't do anything. I kept the old uMatrix (also based on uBlock) along side uBlock Origin, since it provides much finer control on this matter. I only use uBlock for URL based filter.
I guess I wasn't clear. I wanted 3rd-party scripts blocked, but I did
want 1st-party scripts to run. If 1st-party script filtering didn't
work in uBO, I wouldn't have noticed it.
Are you using uBO's Expert mode to get its grid on what to block? That
isn't perfect, so you still had to define rules to tweak behavior. Its
Expert mode with the grid looks like what you get in uMatrix. I thought uMatrix got rolled into uBO, but the layout is different.
I recall uBO had a Javascript option which blocked all JS regardless of
source. You toggled the option to default to blocking JS, and then used
Expert mode when you wanted to all 1st-party scripts (and perhaps some 3rd-party scripts necessary for proper rendering or behavior of the web
doc to a minimum operational level).
Even uMatrix won't get you full control. You might want to allow
1st-party JS, but disable some JS events, like onclick. For example, <domain>##+js(ra.js, onclick, input[type="<name>"]). But doing so
requires learning a LOT more about Adblock Plus filter syntax. The grid
views in uBO Expert mode or uMatrix will help, but you need filters for
further granularity.
Some sites want to add their search engine to your web browsers, and
many web browsers will do so without asking the user for permission.
So, I added the following to my user rules:
! Block suggestion to add site's search engine to web browser. ##link[type="application/opensearchdescription+xml"]
Unfortunately uBO Lite to support Manifest v3 became severely crippled. However, Adguard's Adblocker MV3 extension does let me define user
rules, so I migrated by rule to there. Adguard Adblocker extension also
lets me see a log to help in defining user rules. uBO Lite fell behind
too far, so I moved to Adguard Adblocker. In Firefox, both MV2 and MV3
are supported ... for now. No promise for the future. uBO is still
usable in Firefox Desktop. Don't remember if Firefox Android (aka
Fennix) supports both Manifest versions, so you could still use uBO with
it instead of the crippled uBO Lite. All the Android web browsers are
severely crippled compared to the desktop cousins that it is misleading
to share a product name to draw an unaware community to use on multiple platforms.
I also used to block 3rd-party web fonts which
allow the font foundaries (most Google) to track where you visited,
perhaps even which page, when you visited, and how often. Problem was
the pages could get rather difficult to figure out what a placeholder
icon would do when clicked on unless I dug into code, and that's way too
much trouble.
That! I hate that too. Moreover most sites which use them for icons,
they only need less than 25% of the font characters. Wasting more
resources than what they try to save. The final result has bigger
waste ratio.
The sites using 3rd-party fonts do NOT have to redirect clients to the
font foundaries to retrieve them. The site could cache those web fonts,
so they become 1st-party fonts. If they cache them locally, my
3rd-party font filter wouldn't block them since they are 1st-party.
Instead every site I visited that employed 3rd-party web fonts was
offloading the fonts and the bandwidth to retrieve them at the font
foundaries who are more than willing to track you went getting their
fonts (your IP address to get the fonts, where you visited that
redirected you to their fonts, when you visited, how often, etc).
Arguing with site admins to cache the web fonts at their own server was fruitless. Rarely could you reach anyone that was involved in
configuring the web server, and, when you did, they didn't care, because
they were instructed to reduce load on the server as part of scaling up
their service to accomodate more and more users. They were already
using CDNs, so using font foundaries was an extension of that behavior.
but when I go there it says I need to login. I also went to
bugzilla.mozilla.org to search on 2000597, but got the same denial.
I can do a search to find bug tickets without logging in, but not
this one nor 1996570 or 1999700 for the other CVE. If you can
login, do those bug tickets report the Javascript engine is the
culprit when a web doc's script or Firefox uses the Disability API?
The details of crucial bugs are usually kept confidential or at least
have strict public access to prevent it from being misused.
That's what I figured. They didn't want to provide instructions or a
POC (Proof of Concept) that aholes could utilize to attack users of
prior versions of Firefox. Yet it didn't seem JS in web docs was the
issue, but vulnerabilities within Firefox itself. Getting a Bugzilla
account isn't a laborious task, so it isn't much of a hurdle to get at
the content. It isn't like you have to pay to participate. I quit
using Firefox a while ago, so no point for me to create a Bugzilla
account to see if I could then view the CVE-related bugs on a program
that stopped using.
--- Synchronet 3.21b-Linux NewsLink 1.2