3 ms·

What are the security considerations of living in Emacs? Web browsers have battle tested sandboxes, and using individual native applications for everything leve

What are the security considerations of living in Emacs? Web browsers have battle tested sandboxes, and using individual native applications for everything leverages your platform's process model.

mycpuorg 6y ago
Not sure I understand your question, but in general rich web experience is close to 0. I use html2text which is good for the most part but if you receive emails with embedded javascript and you want to avoid them (a lot of phishing traps goes out of the equation with plaintext). It's a matter of your personal preference and priority. If you like the sort of things mentioned in the article you should give it a shot, at least, try taking a 2-week sabbatical from web email.
- deleted 6y ago
  [deleted]
- wahern 6y ago
  Are there any e-mail clients that actually execute JavaScript? I use mutt, Mail.app, and occasionally GMail, and none even support JavaScript execution, AFAIK, let alone execute it by default.
  - mycpuorg 6y ago
    Granted. I am not equipped to answer the question, assumption about js could be wrong too. Perhaps, I should replace javascript with HTML. The argument still holds about distractions and phishing risks etc.
WhatIsDukkha 6y ago
I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its not new code but... I generally don't do much network anything except across secure lan. I personally think using Emacs for irc or chat is bananas. Emacs can be sandboxed but mostly isn't as people do so much with it and the current model is for a single main process usually. It could evolve though and I think its inevitable that it will. Fwiw I think not just Emacs but all the ditors are more at risk from supplychain attacks and build scripts from the internet. We'll see.
- metroholografix 6y ago
  Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.
  - WhatIsDukkha 6y ago
    Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
    - metroholografix 6y ago
      It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
      - WhatIsDukkha 6y ago
        I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
        metroholografix 6y ago
        I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.
metroholografix 6y ago
Modern web browsers expose an enormous attack surface with a gazillion parsers written in C and C++. They are also constant targets due to marketshare and ease/flexibility of payload delivery. Emacs is written mostly in Emacs Lisp, a memory safe language. So security implications come down to either logic bugs, the C parts of Emacs or the C libraries, usually parsers, that Emacs links with (e.g. ImageMagick which should never be enabled by security-conscious folks and GnuTLS which Emacs supports using out-of-process and security-conscious folks that need it should do so). Let's look at some published vulnerability statistics. Google Chrome: > 550 total, 121 remotely exploitable code execution, 450+ memory corruption/overflows (potentially exploitable). Emacs: 0 unassisted remotely exploitable code exec vulnerabilities, 2 assisted ones (CVE-2017-14482, CVE-2012-3479). Finally, note how specific to exact requirements the Emacs vulnerabilities are. You had to either read an email sent to you containing the payload or open a plain text file with the payload embedded in it and clearly visible. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-741/GNU-Emacs.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... [2] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?...
- WhatIsDukkha 6y ago
  I don't totally disagree with you but- I'm not aware of any serious bugbounty programs for Emacs. Emacs exploits would be immensely valuable in the right contexts.
- oblio 6y ago
  Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.

What are the security considerations of living in Emacs? Web browsers have battle tested sandboxes, and using individual native applications for everything leverages your platform's process model.

mycpuorg 6y ago

Not sure I understand your question, but in general rich web experience is close to 0. I use html2text which is good for the most part but if you receive emails with embedded javascript and you want to avoid them (a lot of phishing traps goes out of the equation with plaintext). It's a matter of your personal preference and priority. If you like the sort of things mentioned in the article you should give it a shot, at least, try taking a 2-week sabbatical from web email.

deleted 6y ago
[deleted]
wahern 6y ago
Are there any e-mail clients that actually execute JavaScript? I use mutt, Mail.app, and occasionally GMail, and none even support JavaScript execution, AFAIK, let alone execute it by default.
- mycpuorg 6y ago
  Granted. I am not equipped to answer the question, assumption about js could be wrong too. Perhaps, I should replace javascript with HTML. The argument still holds about distractions and phishing risks etc.

WhatIsDukkha 6y ago

I think the security issues are potentially pretty significant. It's a garbage collected language with parsers that have been run a few millions times so its not new code but... I generally don't do much network anything except across secure lan. I personally think using Emacs for irc or chat is bananas. Emacs can be sandboxed but mostly isn't as people do so much with it and the current model is for a single main process usually. It could evolve though and I think its inevitable that it will. Fwiw I think not just Emacs but all the ditors are more at risk from supplychain attacks and build scripts from the internet. We'll see.

metroholografix 6y ago
Why is using Emacs for IRC bananas? What do you think can happen? Give me something concrete, not vague assertions. You can spend less than 5 minutes looking over the source of RCIRC (rcirc.el, written in Emacs Lisp) where it's crystal clear that you can't have remote code execution in that Emacs Lisp code.
- WhatIsDukkha 6y ago
  Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.
  - metroholografix 6y ago
    It's useful in that it demonstrates a reduced attack surface. You can immediately see that there are no command injection possibilities. Additionally, there is no potential for integer overflows, memory corruption, undefined behavior, compiler optimizing your safety checks away and so on. A parser bug in Emacs Lisp will signal an error inside Emacs which will end up in either a debugger popup buffer or a message in * Messages*. So using Emacs for IRC is pretty much the same order of bananas as using a .NET or Java client. Do you think that's bananas too?
    - WhatIsDukkha 6y ago
      I wouldn't run any irc client without firejail these days... I think Emacs should change enough that thats more viable then it is today. Really you are only poking at one set of vulnerabilities anyway? Why argue for more complacency? There is plenty of that, it never needs a champion.
      - metroholografix 6y ago
        I'm not arguing against firejail, just trying to understand your threat model. Security exists on a spectrum and there are multiple trade-offs one has to think about. Do you run Python scripts that interact with the network in firejail? I've outlined areas of Emacs where exploitable vulnerabilities could lurk. But in my view, it's far from being a "bananas" situation.

metroholografix 6y ago

Modern web browsers expose an enormous attack surface with a gazillion parsers written in C and C++. They are also constant targets due to marketshare and ease/flexibility of payload delivery. Emacs is written mostly in Emacs Lisp, a memory safe language. So security implications come down to either logic bugs, the C parts of Emacs or the C libraries, usually parsers, that Emacs links with (e.g. ImageMagick which should never be enabled by security-conscious folks and GnuTLS which Emacs supports using out-of-process and security-conscious folks that need it should do so). Let's look at some published vulnerability statistics. Google Chrome: > 550 total, 121 remotely exploitable code execution, 450+ memory corruption/overflows (potentially exploitable). Emacs: 0 unassisted remotely exploitable code exec vulnerabilities, 2 assisted ones (CVE-2017-14482, CVE-2012-3479). Finally, note how specific to exact requirements the Emacs vulnerabilities are. You had to either read an email sent to you containing the payload or open a plain text file with the payload embedded in it and clearly visible. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-72/product_id-741/GNU-Emacs.html https://www.cvedetails.com/vulnerability-list/vendor_id-72/p... [2] https://www.cvedetails.com/product/15031/Google-Chrome.html?vendor_id=1224 https://www.cvedetails.com/product/15031/Google-Chrome.html?...

WhatIsDukkha 6y ago
I don't totally disagree with you but- I'm not aware of any serious bugbounty programs for Emacs. Emacs exploits would be immensely valuable in the right contexts.
oblio 6y ago
Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.