Hacker News Reader

Comment by neilv | Hacker News Reader

My `~/.screenrc` has a comment at the top, which says I created it on "05-May-1994" (before I switched to ISO 8601 dates).

I'm no longer using `screen` on an HP 2392A dumb terminal and PP 14.4kbps modem. But `screen` is still coming in very handy, when working on servers, and for some kinds of developing&running long-running programs on the workstation laptop.

It's also fun, on the occasion that you introduce `screen` or `tmux` to programmers who've been using lesser tools, and they become an instant convert.

Incidentally, given how old the code is, and how there's the potential for various kinds of remote exploits via text (e.g., in SSH session, or in display of user-crafted strings in a console program), I wonder how recently someone has done a rigorous security audit of `screen`.

View on HN

Related/funny: three years ago, someone found exactly such a bug because it was exploited against a Minecraft server they were running in screen (probably without the perpetrator understanding the root cause): https://lists.gnu.org/archive/html/screen-devel/2021-02/msg0...

This is horrifying.

It's because of stuff like this that I escape all non ASCII characters whenever I log or print anything.

I just checked my .screenrc and while I don't have a date in it, the file was last modified in 2010. But that's around the time that I switched to tmux. I've been _very_ happy with tmux over the years…

Looking over the screen 5 release notes it's hard to tell what I've missed being out of that world over the past 15 years. Does anyone have a good rundown on their current differences?

There are bugs. But Screen itself is running locally and per-user?

I could imagine attacking from one tab (window) interacting with another tab but then the user runs already a harmful application. I worry more about everything containing Electron or similar built “web applications”.

Screen has multiuser features, two people can share the same screen session

screen -x

This rocks. It is a superpower and I love it :)

It's such a great feature and even has ACLs.

I used to do training with this. Every student got a private username/password to connect to my laptop where their login shell connected to a specific window (to which only that user had access) in a shared screen session. They each had their own little environment to hack in. Then when we were doing exercises and people got stuck, I would put their screen up on the projector so we could discuss their code together.

For example, you start a `screen` session, and within one of those `screen` windows, you SSH to an untrusted remote system, and that remote system can then send arbitrary bytes to be interpreted by `screen`. If there's a bug, it's potentially remote system having arbitrary code execution capability on your local system that's running `screen`, under your UID, and then escalate from there.

This is why Linux should be taking things like the xz exploit more seriously and, at least, adopting a solution like firejail or bwrap everywhere.

It's not a perfect solution, but it's a step in the right direction towards patching the Unix model, so that programs don't have privileges they don't need.

Mobile Linux (Mer / SailfishOS) works this way to mimic app-based architectures. But, unlike Android, it still feels like regular Linux.

`screen` is trickier to sandbox/compartmentalize than some programs, because it needs permission to create and interact with ttys, most often with shells attached to them, and normally those shells can't be restricted.

I know, this is why I said it's not perfect.

Reply on news.ycombinator.com