GNU Emacs: new critical remote shell injection vulnerability
-
@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. -
@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.@lispi314 @LorenzoAncora @tennoseremel @lxo >Technically, other flaws in a browser implementation may permit it.
Technically yes, but every single exploit I've seen has used JavaScript. -
@lispi314 @LorenzoAncora @tennoseremel @lxo >Technically, other flaws in a browser implementation may permit it.
Technically yes, but every single exploit I've seen has used JavaScript.@Suiseiseki the exploits you can see and that are published are only a small fraction of the total. Most exploits are sold and then kept secret.
-
@Suiseiseki the exploits you can see and that are published are only a small fraction of the total. Most exploits are sold and then kept secret.
@LorenzoAncora @Suiseiseki @tennoseremel @lxo Which is a good reason to be disappointed by all the C++ browsers with C libraries lacking any formal verification being used.
It is a predictable outcome and yet practices are not being adapted accordingly.
One of the most important would be to constrain unexpected computation the browser may induce (no arbitrary code execution, such as JavaScript), since hardware vulnerabilities of various sorts may defeat even entirely correct programs' security. -
@LorenzoAncora @Suiseiseki @tennoseremel @lxo Which is a good reason to be disappointed by all the C++ browsers with C libraries lacking any formal verification being used.
It is a predictable outcome and yet practices are not being adapted accordingly.
One of the most important would be to constrain unexpected computation the browser may induce (no arbitrary code execution, such as JavaScript), since hardware vulnerabilities of various sorts may defeat even entirely correct programs' security.@lispi314 you can disable JavaScript in your browser if you want, but 98% of public websites worldwide depend on JavaScript and will not work or have reduced functionality if its disabled.
No webmaster likes to do more work, if we use JS, it means its necessary.
-
@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.@lispi314 most banks are forced to use JS in order to enforce certain verifications and security policies.
Online banking used it for the last decades, in a form or another. You just started to pay more attention to it, like most of us.
