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 :)