Emacs xwidget-webkit enhancement suite | Hacker News Reader

Emacs xwidget-webkit enhancement suite

github.com

149 pointssigna1140 comments

Debian (and probably others) ship emacs with xwidget-webkit support specifically disabled for "security" reasons.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914568

The argument there sounds like "libwebkit2gtk was never built to be resilient against non-trusted content" and "has no sandboxing". I don't have enough expertise to accurately judge both claims, but the last message in that above bug tread does not like a change is being considered.

The original bug report for this issue contains the following text [0]:

    Although there is apparently some sandboxing in the use of webkit in
    emacs (I read that it uses a seperate process, although not anywhere
    authoritative), this still seems to be equivalent to shipping a
    JavaScript enabled browser without any security support.

Debian packages in stable need security team support. It seems more like a procedural argument about support (i.e., "We don't want the security team to bother with another web browser embedded in Emacs") rather than technical ("It's impossible to have sandboxed Webkit in Emacs").

From a security perspective, this addon seems like the worst of both worlds: it's WebKit, so it's commonly attacked and prodded at, and it's relatively unsupported, so 0days are likely to stick around and fester.

As much as I love the idea of this, I would probably run it as a separate user, or maybe in a chroot or restricted namespace. Unfortunately, it would be pretty inconvenient to use a text editor that can't read my files!

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843462

>"security"

Is there a reason for the scare quotes? In the Reddit thread, the author of xwwp says that the concerns are legitimate: https://np.reddit.com/r/emacs/comments/ifieb8/towards_a_seri...

Author of the fork here. Yes I'm awared of this issue, and I've submitted a patch to emacs-devel that enables sandboxing, hopeful it get merged soon.

The webpage for the library says it is suitable as the engine for web browsers and is used in a couple of browers. I think emacs is being used with an older version (>2) of the library that does not have full isolation.

https://webkitgtk.org

https://packages.debian.org/buster/epiphany-browser

This is very nice. I use Emacs extensively, even for reading email, but I do not allow Emacs to connect to the Internet directly.

Lots of design decisions in Emacs make a lot of sense for a text editor, or for a Lisp VM in the 80s, but are quite insecure if you plan to browse a potentially hostile environment.

Hackers won't target Emacs, they aim for bigger targets, software used by many people.

Emacs is so obscure that nobody bothers to work on emacs exploits, so your worry is not really justified.

An effective exploit could be very high-value, though. Almost by definition, it would target users running development environments where lots of highly sensitive and highly profitable credentials and access could likely be obtained. It's not hard to imagine someone deciding it was worth their while, if browsing from Emacs via embedded Webkit were to catch on in a meaningful way.

Unlike many other computer-using professionals (e.g. accountants), developers are used to separating production and development. Also, they use diverse "exotic" operating systems like Qubes and NixOS. Considering that, I think devs are not really an easy target.

You evince a vast excess of optimism.

Emacs is a general-purpose programming environment that also implements an editor. By design, it has no internal boundaries. Anything that can run in that environment can read and write the filesystem and process environment, open arbitrary sockets, execute arbitrary commands, and otherwise interact with the local system - and, given TRAMP, also remote systems - as the user under whose account Emacs is running. You don't need to know much of anything about the underlying system to use these capabilities. You just need to know about Emacs. And whatever you do need to know about the underlying system to perform whatever attack you have in mind, Emacs will happily help you learn.

What about RCE in such an environment does not say "game over" to you?

Sorry, please define RCE in this case? Remote computation engine?

Most probably Remote Code Execution, as in bad guy remotely injecting code to be run on target emacs instance through a putative xwidget-webkit vulnerability.

Yep.

According to Stack Overflow's 2019 survey [1], most developers (by far) use Windows (45.8%), followed by macOS (27.5%) and Linux (26.6%). Most of those Linux developers will be on mainstream distros I guess, after all, BSD is only at 0.1%.

Maybe those numbers look completely different for people who use Emacs as their browser, no idea, but I'd doubt it, I'd still expect esoteric distros like Nix or Qubes to be a small minority.

And since most companies aren't Google or otherwise really, really good at security, and people are lazy, I'd expect to find a lot of passwordless SSH keys with access to prod servers and the like on those machines. And if not, there will be some other way to penetrate prod, if you own the machine and are determined. There will be some way to access secrets, too, in most places – there are companies that store them in git along with their code, since Github is very secure etc.

[1] https://insights.stackoverflow.com/survey/2020#technology-de...

I think you're too optimistic; computer people might understand dev/prod and use some more exotic systems, but I'll bet most are using 1 workstation for accessing dev and prod, and a majority of those are running Ubuntu/Debian/RHEL (something "normal" enough to target easily).

I'm still pretty impressed by dev-targetted malware like this: https://securitylab.github.com/research/octopus-scanner-malw...

In most places dev/prod is a bureaucratic distinction and not a security boundary, because all developers have access to either.

Frankly, I disagree.

Stealing source code is a valuable enough goal, and doable cross platform with the file system APIs.

If exfiltrating source code was easy to detect, ssh secret keys are stored in consistent locations across machines and are comparatively small. Stealing these would be quite lucrative.

Clearly you've never worked at a startup. SSH'ing to the web server and editing code live is horrifyingly common.

NixOS is insecure -- unlike Windows, MacOS, iOS, and Android, it has no application sandboxing.

Not sure anybody uses Qubes.

That's way too optimistic. Other people said it's too dangerous to run random stuff in your desktop as a dev. And emacs users are not too unlikely.

It’s not even about being targeted specifically. It’s about the complete loss of sandbox and safety guarantees. There is a lot of LHF here.

Why would the sandbox be lost? Can't webkit's normal sandbox still operate here?

This feature uses webkit2gtk [1] which is the base for multiple full web browsers [2] and supports webkit2's normal web process isolation [3]. Is the sandboxing disabled for some reason?

[1] https://emacs.stackexchange.com/questions/48670/the-status-o...

[2] https://wiki.archlinux.org/index.php/List_of_applications#We...

[3] https://webkitgtk.org/ & https://blogs.gnome.org/mcatanzaro/2016/02/01/on-webkit-secu...

LHF?

low-hanging fruit presumably.

OTOH emacs is used by a lot of people with access to sensitive data and/or industrial secrets, so the potential for malicious exploits is disproportional to its footprint

Funny, I use emacs and I do access lots of sensitive data in my day job :)

Out of interest, how do you manage/filter/block the network connections?

With network namespaces [1].

Firejail and other userland tools provide nice interfaces to these.

[1] https://lwn.net/Articles/580893/

can you elaborate? My understanding is this is a separate process.

It isn't; you gain access to this functionality by building Emacs to use libgtk+ and instantiating the widget via a Lisp interface. (Not sure that's the right library. It might be different these days; I've been building my own Emacsen for a long time now, and I deliberately don't build with GTK or any other widget library since in my early experience that was a fertile source of Emacs-crashing bugs - which, of course, serves also to demonstrate that widgets live in the Emacs process and not outside it.)

Would it be insane to use chrome webdriver to do something like this; manipulating a normal chrome(/ium) instance from Emacs?

No, but it wouldn't work the same. Browsing via a Webkit widget is nice because the browser UI (which is just Webkit, without any of the standard browser chrome) lives inside an Emacs buffer, and you interact with it within Emacs' own UI paradigm as well as from Lisp. I think only Lisp interaction would be possible via webdriver.

It'd be more like the old integration between js2-mode and MozRepl (RIP), where you can drive the browser and send code for evaluation, but the browser isn't part of Emacs in the way xwidget-webkit allows.

Without knowing about the implementation, I can speculate (always dangerous ;-)) that the web browser exploit potential is loading a web page, the elements, html, js, images, nested loading of other stuff. So the danger is some kind of crash in the code that evaluates these resources and then stack-overflow kind of deal gets your machine to do something, kind of like a regular browser risk, and there's no hardening against it. This sounds like a capability I want for emacs though, I wonder if there's some way to make it safer; I could create a separate account and ssh in from my main session and run emacs. If I set my display variable to display from fakeme to real me what xwindows risks do I incur? I've never understood that level.

Yeah, I think the attack surface would be in the integration. The Emacs developers are very good in general, but I don't know if they're well placed to address the security concerns of a browser integration, especially in such an otherwise laissez-faire platform as Emacs. Webkit should be pretty secure, I'd expect, but that only helps until you get to where Webkit and Emacs interact in Emacs' own process space.

You make a good point about X. I don't know a great deal about its security either, and most of what I do know comes from jwz's various salty comments about the risks of poorly implemented screen lockers. Based on that, and for whatever it's worth, the strong impression I have of X server security is that, for any client permitted to connect in the first place, there is likewise little to none of it.

It's been a while since I looked in detail at Emacs' xlib integration. But it's evidently comprehensive enough for EXWM to exist, and looking at the EXWM readme, I find it's based on a pure-Lisp X protocol implementation. So I assume that anything an X client can ask an X server to do, you can ask an X server to do from within Emacs, and you don't even need that Emacs to have been specially compiled with support for the protocol - you just need it to evaluate some Lisp, and you're off and running.

I think I'll stick with eww for the foreseeable future.

So on regular old linux with xwindows like ubuntu or whatever, suppose I want to use this new deal and also I now don't trust X as well as emacs itself. I create another user that can't SU, and I vnc into a new session, and run dangerous-emacs. You could make the history and text files readable from your main user.

So now VNC is your trust boundary. I should try eww again too.

Wow - Ive used other Browser integrations but none have been with complete. Well done, I'll definitely give it a spin!

Why is this fork linked instead of the root repository?

It seems that the fork has added a fair bit of functionality. Using Ace-Jump, Sections, and History, at first glance

Ah, I see. I should have read the whole of both READMEs!

Reply on news.ycombinator.com