GNU Emacs: new critical remote shell injection vulnerability
-
@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.
-
@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.
@LorenzoAncora @lispi314 @tennoseremel @quasi @lxo There is no legal requirement that the "verification" or "security policies" are implemented with JavaScript specifically.
JavaScript is just a cheap way to implement things (as web developers don't know HTML - only JavaScript), even though it is the worst way to implement the vast majority of functionality. -
@LorenzoAncora @lispi314 @tennoseremel @quasi @lxo There is no legal requirement that the "verification" or "security policies" are implemented with JavaScript specifically.
JavaScript is just a cheap way to implement things (as web developers don't know HTML - only JavaScript), even though it is the worst way to implement the vast majority of functionality.@Suiseiseki web developers must know HTML, CSS, JavaScript and sometimes a language like Python, PHP, Perl, ...
The law never imposed a specific language, it is superfluous, as JavaScript is and has always been the only way.
Different solutions would require too much server-side processing and some verifications cannot be implemented server-side, thus requiring JS.
-
@Suiseiseki web developers must know HTML, CSS, JavaScript and sometimes a language like Python, PHP, Perl, ...
The law never imposed a specific language, it is superfluous, as JavaScript is and has always been the only way.
Different solutions would require too much server-side processing and some verifications cannot be implemented server-side, thus requiring JS.
@LorenzoAncora >some verifications cannot be implemented server-side, thus requiring JS.
The only place verification can work is server side - as the client cannot be trusted to follow a protocol.
>as JavaScript is and has always been the only way.
Imagine not even knowing about the previous existence of Flash.
JavaScript certainly isn't the only away - as it's easier to just write a free software client that implements the functionality in a sane language (you don't even need to bother to write one - you just make an API available with some documentation and someone will write one).
Using JavaScript to verify input is like trusting a client to provide a newline-terminated string to the server - the server needs to actually verify a string is newline terminated before processing an operation that expects a newline. -
@LorenzoAncora >some verifications cannot be implemented server-side, thus requiring JS.
The only place verification can work is server side - as the client cannot be trusted to follow a protocol.
>as JavaScript is and has always been the only way.
Imagine not even knowing about the previous existence of Flash.
JavaScript certainly isn't the only away - as it's easier to just write a free software client that implements the functionality in a sane language (you don't even need to bother to write one - you just make an API available with some documentation and someone will write one).
Using JavaScript to verify input is like trusting a client to provide a newline-terminated string to the server - the server needs to actually verify a string is newline terminated before processing an operation that expects a newline.@Suiseiseki verification happens server-side, JavaScript is used for data gathering and preparation. If the JavaScript is maliciously altered by the client, the server simply rejects the request.
-
@Suiseiseki verification happens server-side, JavaScript is used for data gathering and preparation. If the JavaScript is maliciously altered by the client, the server simply rejects the request.
@LorenzoAncora >verification happens server-side,
Then then client-side JavaScript verification is clearly not needed.
>JavaScript is used for data gathering and preparation
HTML5 is perfectly capable of gathering data and preparing it for submission - it can even check the input format without JavaScript.
But instead of using the HTML5 forms, your typical web developer writes up some JavaScript abortion that performs far worse than the built-in forms. -
@LorenzoAncora >verification happens server-side,
Then then client-side JavaScript verification is clearly not needed.
>JavaScript is used for data gathering and preparation
HTML5 is perfectly capable of gathering data and preparing it for submission - it can even check the input format without JavaScript.
But instead of using the HTML5 forms, your typical web developer writes up some JavaScript abortion that performs far worse than the built-in forms.@Suiseiseki maybe I didn't explain myself: the verification of data integrity and correctness happens server-side too, not only client-side.
JavaScript is also needed to guarantee compatibility with older web browsers which don't support all HTML5 features. In addition, HTML5 forms can check the input for syntactical correctness, but cannot process nor alter collected data.
JavaScript exists for a good reason.
