Multiple security issues in GNU Screen

Note: In Debian, GNU screen is not installed with setuid-root privileges.

Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.

Looks like it is in Fedora.

I wonder if there is some selinux policy to reduce the attack surface

Likewise in Arch.

Slackware 15:

lrwxrwxrwx 1 root root 12 Feb 11 2022 /usr/bin/screen -> screen-4.9.0

-rwxr-xr-x 1 root root 455016 Feb 1 2022 /usr/bin/screen-4.9.0

no suid

And the package in Debian Stable (aka bookworm) is too old to be affected by the vulnerabilities in 5.0.0.

I used to hate that Debian always was behind on software versions, but now I use different package sources for the few applications where I really don't want to rely on old software (like browsers), and otherwise doing great with the old stuff :-)

If one is in group utmp, one can mess with the login accounting database: the table of currently active logins, the log of log-ons/log-offs, and the table of per-user last logins.

https://jdebp.uk/FGA/unix-login-database.html

The login accounting system that Linux-based operating systems have inherited from Unix really has never reconciled its initial real-terminal-login-only superuser-managed design with the fact that non-superuser programs that allocate pseudo-terminals (e.g. any local terminal emulator, NeoVIM, tmux, screen) want to (over)write entries for those pseudo-terminals in the login accounting database to make the output of the "who" command (and its ilk) more complete.

The best approach I've seen was to re-think the idea; have the pseudo-terminal-using programs run entirely unprivileged and use a client-server model where only the server actually has access to the database files.

Laurent Bercot did this. It fixes many holes, including that the log of log-ons/log-offs is made truly append-only (modulo superuser access to the underlying files). But it has the same architectural problem that any client in the group can overwrite any currently active login record if it knows the record ID, which by design (and the Single Unix Specification) there's an API for enumerating.

* https://skarnet.org/software/utmps/

Both the BSDs and M. Bercot have improved the situation with pututxline(), but it's still not out of the woods yet.

On Fedora it is setgid screen, not root.

Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096

If you're running Firefox on Debian please make sure you manually update it since the package repo's been down for a while. I filed a 'support' ticket first ( https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.

I set TMPDIR to $HOME/tmp because of that.

The repo appears to be working for installing/updating packages. Mozilla should allow file listing which should fix the 404s, and make this repo behave as expected when manually browsed (Apparently hosted on a Google webserver; maybe Google forbids this?).

  apt-get changelog firefox
  Get:1 store: firefox 138.0.3~build1 Changelog
  Fetched 129 B in 0s (0 B/s)
  firefox (138.0.3~build1) UNRELEASED; urgency=medium
 
    * N/A
 
   -- Mozilla <release@mozilla.com>  Mon, 12 May 2025 12:40:33 -0000

  date
  Tue May 13 08:56:09 AM PDT 2025

Or, to really prove it to yourself, you can re-download the package:

  apt-get install --download-only --reinstall firefox

This is about Mozilla's builds of Firefox for Debian, not Debian's builds, right? So regular Debian users who run the default Firefox (firefox-esr) would be unaffected.

Correct, but that's firefox-esr not firefox. At one point I found it necessary to switch as there was an issue with security updates, but that might have been an issue in that particular system's configuration that I since resolved.

Except for the name, TMPDIR is unrelated to utmp.

I will have to look into that more tomorrow. My only Debian desktop is a laptop at family's house and currently asleep. It mentioned an error with the repository but my first troubleshooting step was to try to manually verify I could _get_ to the repo in a browser.

I know; but it mitigates some potential race conditions.

More info on that?

There almost certainly is, pretty sure Fedora has an SELinux policy for all software in base.

To be clear for the sake of other readers, Debian's firefox-esr package is Firefox.

It's simply a release from Mozilla's Extended Support Release channel, as distinct from the Rapid Release channel that you are apparently using. Not a different project/product.

https://support.mozilla.org/en-US/kb/choosing-firefox-update...

FWIW, Slackware 15 was updated to screen to screen-4.9.1.

This update fixes security issues:

* attacher.c - prevent temporary 0666 mode on PTYs.

* avoid file existence test information leaks.

* socket.c - don't send signals with root privileges.

Debian stable users missed heartbleed entirely. I think the glacial pace is underrated.

Glacial page bedrock of an OS with optional sandboxed more-up-to-date userspace packages and runtimes that can be layered on top of the host system was the dream of flatpak/snap/appimage, right?

Yes, though that comes with its own headaches since the data those sandboxed applications are supposed to touch are the only actually valuable data on my computer. (How many versions of OpenSSL are currently running on my Silverblue system? I literally couldn't tell you.) My spreadsheet is only vouched for by some random dude on Flathub and it can steal all my financial information. But at least it can't add a printer, or delete a system file that I can freely download from the Internet at any time.

Damn, Slackware. That’s a name I haven’t heard in a very long time.

> Debian stable users missed heartbleed entirely

Missed it? Not at all, Debian pioneered that style of bugs years before!

https://github.com/g0tmi1k/debian-ssh

And the default SELinux config was broken for like 15 years IIRC. It's always pick your poison.

This a decent observation, but I would add that some other Flatpak app that you run might be correctly sandboxed from accessing your financial information, and this is the real benefit of such a system.