Hacker News Reader

Comment by prosody | Hacker News Reader

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.

View on HN

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/p...

[2] https://www.cvedetails.com/product/15031/Google-Chrome.html?...

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.

Chrome probably has 1 (2?) billion users. Emacs has what? 100k at best? The financial incentive to attack Chrome is much, much higher.

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.

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.

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.

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.

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.

Five minutes might tell you there is no (eval) in the path but I don't see how thats useful.

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?

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.

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.

IRC has decades of vulnerabilities and unexpected behavior atop its simple protocol.

Sitting on irc with 100 channels full of randos,

Emacs modules that aren't irc but also process text coming through for X or Y,

misconfiguration,

mime link handling,

irc protocol handling,

sloppy bot making "hey the builtin pretty printing for python code snippet had more implications then I anticipated",

"stuff" running in emacs in between network and the irc client,

add that to "noone seems to talk about or care about security issues in Emacs",

yeah a big pile of risk that pretty tough to just write off, for me, to that point I think it's bananas.

Especially when compared to the trivial alternative of sandboxing another client that has much less surface then a fully configured single process Emacs.

You are doing what you are doing and on some level we aren't too far apart in viewing the safety of a sandboxed raw emacs+some tight set of irc+a convenient plugin X and Y vs another irc client sandboxed. But I bet you aren't doing that.

I really dislike the words "threat model" in security conversations like this.

Neither of us has actually done any of that formal process for this, so why ask for it?

Why do you dislike "threat model", it's a necessity. There can be no productive security discussion without a model present to frame and ground it in actuality. Given a determined, resourceful adversary, you're toast regardless of what you do to protect yourself.

It makes sense therefore to have a realistic model and prepare accordingly. The probability that "100 channels full of randos" are going to use any of the -aspecific, hand-wavy- vectors you mentioned to defeat my security posture (which includes an IRC client written in a memory-safe language whose code I've reviewed that is masquerading through CTCP version as something else entirely) is miniscule. I can live with that but I've also spent some time to configure Emacs according to guidelines I previously mentioned and review code that I'm using and exposing to potential attacks.

Reply on news.ycombinator.com