GNU Emacs: new critical remote shell injection vulnerability
-
@lxo @LorenzoAncora Rather - ironically, the CVE website performs arbitrarily code execution on your computer (a SEVERE vulnerability) and if your web browser doesn't have that severe vulnerability, nothing displays?
@Suiseiseki cve.org is popular and safe to use. JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements. It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites. Therefore, its presence on the CVE site is standard practice for modern web functionality.
Please see: https://ieji.de/@LorenzoAncora/114098428234129692
-
@Suiseiseki cve.org is popular and safe to use. JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements. It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites. Therefore, its presence on the CVE site is standard practice for modern web functionality.
Please see: https://ieji.de/@LorenzoAncora/114098428234129692
@LorenzoAncora >cve.org is popular and safe to use.
You write that, but then I see the following Obfscript;
https://cmp.osano.com/AzyhULTdPkqmy4aDN/46057d56-0263-4cca-abac-9adddada4f3b/osano.js
https://www.cve.org/assets/index-mLL8icbW.js
Those are sufficiently large programs that would be quite trivial to slip proprietary malware in and have such go unnoticed.
Any attacker wouldn't even need to compromise the computer cve.org is running on to attack visitors - they could compromise cmp.osano.com instead.
It seems more JavaScript programs are loaded too, although which ones are not revealed until you run proprietary JavaScript (free and nonfree JavaScript are mixed into the same file), which I refuse to do.
>JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements.
JavaScript absolutely destroys accessibility and seems to be primarily used to spy on the user, which doesn't exactly "comply with EU safety regulations".
>It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites.
97.69% of web browsers have a SEVERE vulnerability and a little less than 98.3% of public websites attack people with proprietary software and spyware huh?
>its presence on the CVE site is standard practice for modern web functionality.
Just because attacking the user is standard practice doesn't mean a website that doesn't function without JavaScript is acceptable.
The only JavaScript your website needs and should have is as follows;
<script>
/* AGPLv3-or-later */
document.body.innerHTML = 'We have detected that you have JavaScript enabled in your browser, please disable it to continue. Please be aware that your browser is severely compromised as it is automatically running malicious JavaScript.'
</script> -
@LorenzoAncora >cve.org is popular and safe to use.
You write that, but then I see the following Obfscript;
https://cmp.osano.com/AzyhULTdPkqmy4aDN/46057d56-0263-4cca-abac-9adddada4f3b/osano.js
https://www.cve.org/assets/index-mLL8icbW.js
Those are sufficiently large programs that would be quite trivial to slip proprietary malware in and have such go unnoticed.
Any attacker wouldn't even need to compromise the computer cve.org is running on to attack visitors - they could compromise cmp.osano.com instead.
It seems more JavaScript programs are loaded too, although which ones are not revealed until you run proprietary JavaScript (free and nonfree JavaScript are mixed into the same file), which I refuse to do.
>JavaScript is a web standard that helps ensure compliance with EU safety regulations and accessibility requirements.
JavaScript absolutely destroys accessibility and seems to be primarily used to spy on the user, which doesn't exactly "comply with EU safety regulations".
>It is implemented by 97.69% of web browsers and utilized by 98.3% of all public websites.
97.69% of web browsers have a SEVERE vulnerability and a little less than 98.3% of public websites attack people with proprietary software and spyware huh?
>its presence on the CVE site is standard practice for modern web functionality.
Just because attacking the user is standard practice doesn't mean a website that doesn't function without JavaScript is acceptable.
The only JavaScript your website needs and should have is as follows;
<script>
/* AGPLv3-or-later */
document.body.innerHTML = 'We have detected that you have JavaScript enabled in your browser, please disable it to continue. Please be aware that your browser is severely compromised as it is automatically running malicious JavaScript.'
</script>@Suiseiseki the scripts do not appear to contain malware:
https://www.virustotal.com/gui/url/0e7795408fa7cc6e918cbb0526bc804fece03f7b7685bebdc971670910088feahttps://www.virustotal.com/gui/url/b698d39b69b283657a4120248b211baeeb6be9b9f46a0bf873bfbcb5cbf622ac
All JavaScript files you've linked to are minified (compressed), not obfuscated. Almost all websites use compression to improve loading times. You can simply use the auto-format of your text editor to read minified scripts with minimal effort.
-
@Suiseiseki the scripts do not appear to contain malware:
https://www.virustotal.com/gui/url/0e7795408fa7cc6e918cbb0526bc804fece03f7b7685bebdc971670910088feahttps://www.virustotal.com/gui/url/b698d39b69b283657a4120248b211baeeb6be9b9f46a0bf873bfbcb5cbf622ac
All JavaScript files you've linked to are minified (compressed), not obfuscated. Almost all websites use compression to improve loading times. You can simply use the auto-format of your text editor to read minified scripts with minimal effort.
so you run trojans from two malicious web sites to "prove" that another web site is not malicious. that's as reasonable as asking both coca-cola and pepsi whether their softdrinks are healthy to drink. they don't seem to be affecting only browsers, but also users' brains
that it makes the site completely inaccessible to, per your own numbers, 2.31% of browsers, where web standards recommend graceful degradation instead of big bold red letters stating "don't feel welcome" to those with specific accessibility needs that both major brands of browsers can't tend to, is a big "screw you" to me and others
that it renders computers unusable to access this very site, computers whose manufacturers have abandoned, by refusing to patch known security vulnerabilities that can be exercised with remotely-supplied javascript and refusing to allow owners to patch them by themselves, computers that would still be perfectly usable to visit web sites that actually took the trouble to abide by web standards instead of jumping on the "you must enable javascript" "screw you" mindless bandwagon, adds insult to injury, and more litter to the pile
that a web site that ought to be as security conscious as it goes, and reports vulnerabilities even on browsers, that enable web sites to induce remote execution of arbitrary code on visitors' computers, demands visitors to open up their computers to such risks is not only contradictory to its mission, it's a "screw you" to security education as well.
CC: @Suiseiseki@freesoftwareextremist.com
-
so you run trojans from two malicious web sites to "prove" that another web site is not malicious. that's as reasonable as asking both coca-cola and pepsi whether their softdrinks are healthy to drink. they don't seem to be affecting only browsers, but also users' brains
that it makes the site completely inaccessible to, per your own numbers, 2.31% of browsers, where web standards recommend graceful degradation instead of big bold red letters stating "don't feel welcome" to those with specific accessibility needs that both major brands of browsers can't tend to, is a big "screw you" to me and others
that it renders computers unusable to access this very site, computers whose manufacturers have abandoned, by refusing to patch known security vulnerabilities that can be exercised with remotely-supplied javascript and refusing to allow owners to patch them by themselves, computers that would still be perfectly usable to visit web sites that actually took the trouble to abide by web standards instead of jumping on the "you must enable javascript" "screw you" mindless bandwagon, adds insult to injury, and more litter to the pile
that a web site that ought to be as security conscious as it goes, and reports vulnerabilities even on browsers, that enable web sites to induce remote execution of arbitrary code on visitors' computers, demands visitors to open up their computers to such risks is not only contradictory to its mission, it's a "screw you" to security education as well.
CC: @Suiseiseki@freesoftwareextremist.com@lxo you're welcome. If you need the screenshot of something else just ask, I'll gladly use the latest build of Mozilla Firefox on my up-to-date Linux to take a screenshot for you.
CVE.org is supported by the Cybersecurity and Infrastructure Security Agency (CISA) and by MITRE, a 65 years old corporation specialized in national defense, financial systems and cybersecurity.
Its staff has 25 years of experience. If this website isn't safe, we're all doomed.
CC: @Suiseiseki , @tennoseremel
-
@lxo you're welcome. If you need the screenshot of something else just ask, I'll gladly use the latest build of Mozilla Firefox on my up-to-date Linux to take a screenshot for you.
CVE.org is supported by the Cybersecurity and Infrastructure Security Agency (CISA) and by MITRE, a 65 years old corporation specialized in national defense, financial systems and cybersecurity.
Its staff has 25 years of experience. If this website isn't safe, we're all doomed.CC: @Suiseiseki , @tennoseremel
even if it were still safe now, it is one take-over away from becoming nonsafe, and all the wrong things it's teaching now will become vulnerabilities that the future hostile owner will be able to exploit. it's negligent security malpractice.
CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
-
even if it were still safe now, it is one take-over away from becoming nonsafe, and all the wrong things it's teaching now will become vulnerabilities that the future hostile owner will be able to exploit. it's negligent security malpractice.
CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh@lxo I understand your concerns, but MITRE and CISA's oversight ensures CVE.org's security and integrity. Regular audits, bug reporting programs and frequent updates help mitigate future risks.
Alexandre, living in irrational fear of interactive webpages isn't healthy. We live only once, mate!
I'm currently satisfied and use their services with gratitude. If I had anything to say about their ethics, I would tell them personally.
I advise you do the same. -
@lxo I understand your concerns, but MITRE and CISA's oversight ensures CVE.org's security and integrity. Regular audits, bug reporting programs and frequent updates help mitigate future risks.
Alexandre, living in irrational fear of interactive webpages isn't healthy. We live only once, mate!
I'm currently satisfied and use their services with gratitude. If I had anything to say about their ethics, I would tell them personally.
I advise you do the same.@LorenzoAncora @lxo @tennoseremel If MITRE and CISA was actually carrying out sufficient oversight, they would require that the page work without JavaScript.
Living in irrational trust of webpages that serve malicious software and trying to convince rational people to run such malware isn't healthy.
You do not need JavaScript to write an interactive website - rather the best interactive websites don't use JavaScript and instead use HTML5+CSS+fastCGI; https://git.savannah.gnu.org/cgit/ -
@lxo I understand your concerns, but MITRE and CISA's oversight ensures CVE.org's security and integrity. Regular audits, bug reporting programs and frequent updates help mitigate future risks.
Alexandre, living in irrational fear of interactive webpages isn't healthy. We live only once, mate!
I'm currently satisfied and use their services with gratitude. If I had anything to say about their ethics, I would tell them personally.
I advise you do the same.the oversight has already failed, evidently, to have allowed such a contradictory web site to use their name. everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy. your attitude of blind trust on the good intentions and harmlessness of common malpractice is anachronistic and unfit. your attempts to ridicule concerns that prove right time and again are an irresponsible embarrassment to serious security professionals, and to anyone paying attention to world politics without hiding the head in the sand.
as for living in irrational fear... should I remind you that it was you who brought into my timeline a report of a security problem related with allowing third parties to run arbitrary code on our computers? are you suggesting that nobody should take those reports seriously?
or are you one of those believers that the leopards will never bite your face?
CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
-
the oversight has already failed, evidently, to have allowed such a contradictory web site to use their name. everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy. your attitude of blind trust on the good intentions and harmlessness of common malpractice is anachronistic and unfit. your attempts to ridicule concerns that prove right time and again are an irresponsible embarrassment to serious security professionals, and to anyone paying attention to world politics without hiding the head in the sand.
as for living in irrational fear... should I remind you that it was you who brought into my timeline a report of a security problem related with allowing third parties to run arbitrary code on our computers? are you suggesting that nobody should take those reports seriously?
or are you one of those believers that the leopards will never bite your face?
CC: @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh@lxo
> everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy.
Not sure what this is about.
@LorenzoAncora @Suiseiseki @tennoseremel -
@LorenzoAncora @lxo @tennoseremel If MITRE and CISA was actually carrying out sufficient oversight, they would require that the page work without JavaScript.
Living in irrational trust of webpages that serve malicious software and trying to convince rational people to run such malware isn't healthy.
You do not need JavaScript to write an interactive website - rather the best interactive websites don't use JavaScript and instead use HTML5+CSS+fastCGI; https://git.savannah.gnu.org/cgit/@Suiseiseki HTML5 alone cannot replace JavaScript because it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations, which are essential for creating dynamic, accessible and interactive pages.
FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests and can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
CC: @tennoseremel @lxo
-
@lxo
> everyone is seeing how easy it is to turn a whole country with a quarter-millennium tradition of laic democracy into a self-destructing theocracy.
Not sure what this is about.
@LorenzoAncora @Suiseiseki @tennoseremelheh, I guess this means my assessment that everyone is seeing it is wrong, for at least one person isn't
CC: @Suiseiseki@freesoftwareextremist.com @LorenzoAncora@ieji.de @tennoseremel@lor.sh
-
@Suiseiseki HTML5 alone cannot replace JavaScript because it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations, which are essential for creating dynamic, accessible and interactive pages.
FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests and can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
CC: @tennoseremel @lxo
@LorenzoAncora @tennoseremel @lxo >it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations
You do not need any of those things.
If you wanted things to be asynchronous on the same page for a laugh, there's something called iframe.
>FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests
JavaScript requires multiple web requests just to load the JavaScript and then continuous web requests to do each operation, so really JavaScript loses again.
FastCGI really only needs a single request back and forth for every operation.
You can hand optimize the software on the FastCGI end with assembly if you want to minimize how computationally expensive each operation is.
Generally sequentially processing operations on one computer in an efficient manner (doing mostly the same operation over and over again is pretty cache efficient) uses less power than doing the operations in an inefficient way across 1000, 10,000 or millions of computers.
JavaScript is a way to just dump the processing onto the client (and as the client is the one who has to pay for the power, usually the JavaScript is left completely unoptimized).
>can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
I'm not sure about the validity of this claim, as fastCGI usually takes user input as POST fields, which is usually properly escaped, unlike a lot of client side JavaScript, which seems to send JavaScript objects, or JSON blobs to the server. -
@LorenzoAncora @tennoseremel @lxo >it lacks the capability to handle events, manipulate the DOM in real-time, or perform asynchronous operations
You do not need any of those things.
If you wanted things to be asynchronous on the same page for a laugh, there's something called iframe.
>FastCGI, executing server-side, is computationally more expensive because it requires multiple web requests
JavaScript requires multiple web requests just to load the JavaScript and then continuous web requests to do each operation, so really JavaScript loses again.
FastCGI really only needs a single request back and forth for every operation.
You can hand optimize the software on the FastCGI end with assembly if you want to minimize how computationally expensive each operation is.
Generally sequentially processing operations on one computer in an efficient manner (doing mostly the same operation over and over again is pretty cache efficient) uses less power than doing the operations in an inefficient way across 1000, 10,000 or millions of computers.
JavaScript is a way to just dump the processing onto the client (and as the client is the one who has to pay for the power, usually the JavaScript is left completely unoptimized).
>can be more vulnerable to remote code execution and misconfigurations than client-side JavaScript.
I'm not sure about the validity of this claim, as fastCGI usually takes user input as POST fields, which is usually properly escaped, unlike a lot of client side JavaScript, which seems to send JavaScript objects, or JSON blobs to the server.@Suiseiseki iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content, allowing criminals to inject malware, steal information, or conduct fraud, whereas client-side JavaScript is sandboxed within the isolated context of the webpage with same-origin policy restrictions.
Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.
CC: @tennoseremel @lxo
-
heh, I guess this means my assessment that everyone is seeing it is wrong, for at least one person isn't
CC: @Suiseiseki@freesoftwareextremist.com @LorenzoAncora@ieji.de @tennoseremel@lor.sh@lxo no Alexander, even saints met opposition.
When you don't see much opposition, it only means nobody else thought sharing their informed opinions and discuss honestly with you was worth their time. In other words, that nobody else believed in your ability to think rationally, understand different perspectives and thus improve. -
@lxo no Alexander, even saints met opposition.
When you don't see much opposition, it only means nobody else thought sharing their informed opinions and discuss honestly with you was worth their time. In other words, that nobody else believed in your ability to think rationally, understand different perspectives and thus improve.WTH are you even talking about? what are you making about me? turn this around and see how much opposition you are (not) seeing to the nonsense you're pushing that untrusted JavaScript (download from third parties) can be executed safely, but iFrames (that carry JavaScript also from third parties, for that matter) can. does it follow that, because you're not seeing opposition, it's because (as you put it so fake-politely) nobody else was willing to waste time as I was to share informed opinions and discuss honestly with you, or to believe your ability to think rationally? I see your point, I regret wasting my time with you already. hopefully what I wrote in this thread may have a positive effect on others.
CC: @quasi@peister.org @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh
-
@Suiseiseki iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content, allowing criminals to inject malware, steal information, or conduct fraud, whereas client-side JavaScript is sandboxed within the isolated context of the webpage with same-origin policy restrictions.
Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.
CC: @tennoseremel @lxo
@LorenzoAncora @tennoseremel @lxo >iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content,
So iframes without JavaScript is bad, but a page full of malicious proprietary JavaScript without iframes is good? Huh.
Have you considered that JavaScript is always the "malicious remote content"?
>allowing criminals to inject malware, steal information, or conduct fraud
Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
>whereas client-side JavaScript is sandboxed within the isolated context of the webpage
Have you considered that there's always a sandbox bypass?
>with same-origin policy restrictions.
Last time I checked those can be applied to iframes just as well.
>Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.
In reality, I find that cgit is far more responsive and loads faster and has better privacy than JavaScript-based git hosts, which are much slower and really hit the CPU hard - increasing electrical consumption substantially.
If you want to reduce CO₂ emissions, one effective move would be to eliminate JavaScript. -
WTH are you even talking about? what are you making about me? turn this around and see how much opposition you are (not) seeing to the nonsense you're pushing that untrusted JavaScript (download from third parties) can be executed safely, but iFrames (that carry JavaScript also from third parties, for that matter) can. does it follow that, because you're not seeing opposition, it's because (as you put it so fake-politely) nobody else was willing to waste time as I was to share informed opinions and discuss honestly with you, or to believe your ability to think rationally? I see your point, I regret wasting my time with you already. hopefully what I wrote in this thread may have a positive effect on others.
CC: @quasi@peister.org @Suiseiseki@freesoftwareextremist.com @tennoseremel@lor.sh@lxo web apps for real-time collaboration, social media, video conferencing, online banking, trading, e-learning, auctions, e-commerce and so on, all need client-side JavaScript. It's just a *necessity* to meet the minimum quality standards.
Internet offers endless variety: if you don't trust a website, the best thing you can do is not visiting it.
Alex, my social feed stays always open for you, hoping for pleasant conversations in future. Take care.
-
@LorenzoAncora @tennoseremel @lxo >iFrames are discouraged by most web dev guidelines, as they can embed malicious remote content,
So iframes without JavaScript is bad, but a page full of malicious proprietary JavaScript without iframes is good? Huh.
Have you considered that JavaScript is always the "malicious remote content"?
>allowing criminals to inject malware, steal information, or conduct fraud
Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
>whereas client-side JavaScript is sandboxed within the isolated context of the webpage
Have you considered that there's always a sandbox bypass?
>with same-origin policy restrictions.
Last time I checked those can be applied to iframes just as well.
>Client-side processing grants improved responsiveness, better privacy and faster loadings, also reducing the carbon footprint by avoiding unnecessary web requests.
In reality, I find that cgit is far more responsive and loads faster and has better privacy than JavaScript-based git hosts, which are much slower and really hit the CPU hard - increasing electrical consumption substantially.
If you want to reduce CO₂ emissions, one effective move would be to eliminate JavaScript.@Suiseiseki @LorenzoAncora @tennoseremel @lxo There is also zero reason why a first-party site couldn't embed malicious data directly, such as image data malformed specifically to exploit bugs in a codec library used by some common browsers.
There is no reason, either, to assume that iframes cannot be controlled by the same first-party and used to obviate unnecessary JavaScript interactions.
> Exploitation, information exfiltration etc require JavaScript to pull off - meanwhile you cannot do any of that with just HTML.
Technically, other flaws in a browser implementation may permit it. This is the result of unsafe programming practices. -
@lxo web apps for real-time collaboration, social media, video conferencing, online banking, trading, e-learning, auctions, e-commerce and so on, all need client-side JavaScript. It's just a *necessity* to meet the minimum quality standards.
Internet offers endless variety: if you don't trust a website, the best thing you can do is not visiting it.
Alex, my social feed stays always open for you, hoping for pleasant conversations in future. Take care.
@LorenzoAncora @lxo @quasi @Suiseiseki @tennoseremel > It's just a *necessity* to meet the minimum quality standards.
Funny that. I actually consider my bank's site to have actively degraded every single update they made since adding JavaScript to it. The original version was also considerably faster to use.
