home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   alt.comp.freeware      Generic free software discussions      39,996 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 39,761 of 39,996   
   VanguardLH to jj4public@gmail.com   
   Re: Mozilla finishes 2025 with an almost   
   03 Jan 26 09:48:17   
   
   From: V@nguard.LH   
      
   JJ  wrote:   
      
   > VanguardLH wrote:   
   >   
   >> When disabling Javascript, does that also mean all extensions (aka   
   >> add-ons) are also disabled?   
   >   
   > Firefox's `javascript.enabled` doesn't trully disable JS globally.   
   > It's only for all scripts (all embedded, external, and inline) on all   
   > sites, including bookmarklets (since the code is executed in sites'   
   > page context). Excluding browser extensions, Developer Tools   
   > (including its Debugger), browser internal pages & windows (e.g.   
   > Settings page, Bookmarks manager window, etc.), and most browser   
   > functionalities which are not visibly presentable (e.g. download   
   > queue manager, etc.).   
   >   
   >> If no, disabling Javascript does not eliminate that abuse vector.   
   >> Does disabling Javascript only disable it in the web docs the web   
   >> browser renders, or also in all extensions added to the web browser?   
   >   
   > Except for site scripts, JS on all previously mentioned are still working,   
   > so they'll also vulnerable. After all, they're all using the same JS engine.   
   >   
   > Disabling JS via `javascript.enabled` simply removes most of the attack   
   > vectors; IMO, up to around 95%-99%; depending on how many various sites   
   > one's use (whether the sites are trusted or not). The 2nd place would be   
   > browser extensions (whether they're digitally signed or not). The 3rd place   
   > would be UserScripts or GM scripts.   
   >   
   > There's also the possibility of triggering an unpatched vulnerability by   
   > accident. Some (if not most) vulnerabilities were found in that way, instead   
   > of intentional hunt.   
      
   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.   
      
   With uBlock Origin still usable in Firefox, you could define it to block   
   3rd-party scripts, but not 1st-party scripts.  If I visit a site, yep, I   
   want their scripts to run, but not when retrieved from an unknown or   
   untrusted other party.  Alas, many if not most large-scale web sites   
   have lots of their resources off domain, like using CDN (Content   
   Delivery Network) providers to reduce the bandwidth and load at a web   
   site.  Images, scripts, and other resources could come from off domain.   
   When I had 3rd-party scripts disabled in uBO, I found lots of sites that   
   would not properly function, because I was blocking access to resources   
   the web doc needed; else, it exhibited odd behavior, or worse.  I had to   
   keep adding exclusions after analyzing the web docs to see from where a   
   web site was retrieving its off-domain scripts.  After a few years, I   
   decided that I was wasting way too much time trying to throttle the   
   functionality of way too many web sites to determine what off-domain   
   resources I would allow.  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.   
      
   To me, Shadow and yeti are just spewing FUD.  They don't know where   
   within Firefox lies the memory reuse vulnerability.  For example, one   
   CVE mentions a bug lies in the Disability API.  Maybe web doc scripts   
   can use that, but why wouldn't Mozilla also use it for the accessibility   
   settings in Firefox?   
      
   https://support.mozilla.org/en-US/kb/accessibility-features-firefox   
   "Firefox includes many features to make the browser and web content   
   accessible to all users, ..."   
      
   They don't say just web content.  That CVE mentions a bug at:   
      
   https://bugzilla.mozilla.org/show_bug.cgi?id=2000597   
      
   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?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca