4 ms·

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 E

by nextos 6y ago

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.

cheez 6y ago
can you elaborate? My understanding is this is a separate process.
- throwanem 6y ago
  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.)
  - elwell 6y ago
    Would it be insane to use chrome webdriver to do something like this; manipulating a normal chrome(/ium) instance from Emacs?
    - throwanem 6y ago
      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.
      - NotSammyHagar 6y ago
        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.
        throwanem 6y ago
        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.
        NotSammyHagar 6y ago
        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.
dmortin 6y ago
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.
- throwanem 6y ago
  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.
  - iso8859-1 6y ago
    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.
    - pokoleo 6y ago
      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.
    - yjftsjthsd-h 6y ago
      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).
    - throwanem 6y ago
      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?
confounded 6y ago
Out of interest, how do you manage/filter/block the network connections?
- nextos 6y ago
  With network namespaces [1]. Firejail and other userland tools provide nice interfaces to these. [1] https://lwn.net/Articles/580893/ https://lwn.net/Articles/580893/

by nextos 6y ago

cheez 6y ago

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

throwanem 6y ago
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.)
- elwell 6y ago
  Would it be insane to use chrome webdriver to do something like this; manipulating a normal chrome(/ium) instance from Emacs?
  - throwanem 6y ago
    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.
    - NotSammyHagar 6y ago
      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.
      - throwanem 6y ago
        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.
        NotSammyHagar 6y ago
        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.

dmortin 6y ago

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.

throwanem 6y ago
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.
- iso8859-1 6y ago
  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.
  - pokoleo 6y ago
    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.
  - yjftsjthsd-h 6y ago
    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).
  - throwanem 6y ago
    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?

confounded 6y ago

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

nextos 6y ago
With network namespaces [1]. Firejail and other userland tools provide nice interfaces to these. [1] https://lwn.net/Articles/580893/ https://lwn.net/Articles/580893/