A Slint fanboy from Berlin.

  • 0 Posts
  • 5 Comments
Joined 1 year ago
cake
Cake day: June 12th, 2023

help-circle



  • Plugins are a code execution vulnerability by design;-) Especially with binary plugins you can call/access/inspect everything the program itself can. All UI toolkits make heavy use of plugins, so you can not avoid those with almost all UI applications.

    There are non-UI applications with similar problems though.

    Running anything with network access as root is an extra risk that effects UI and non-UI applications in the same way.


  • Usig anything as root is a security risk.

    Using any UI application as root is a bigger risk. That’s because every UI toolkit loads plugins and what not from all over the place and runs the code from those plugins (e.g. plugins installed system wide and into random places some environment variables point to). Binary plugins get executed in the context of the application running and can do change every aspect of your program. I wrote a small image plugin to debug an issue once that looked at all widgets in the UI and wrote all the contents of all text fields (even those obfuscated to show only dots in the UI) to disk whenever some image was loads. Plugins in JS or other non-native code are more limited, but UI toolkits tend to have binary plugins.

    So if somebody manages to set the some env vars and gets root to run some UI application with those set (e.g. using sudo), then that attacker hit the jackpot. In fact some toolkits will not even bring up any UI when run as root to avoid this.

    Running any networked UI application as root is the biggest risk. Those process untrusted data by definition with who knows what set of plugins loaded.

    Ideally you run the UI as a normal user and then use sudo to run individual commands as root.