4 ms·

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

by teddyh 1y ago

jesprenj 1y ago
Likewise in Gentoo. But in Gentoo it has SETGID for utmp group. Though I'm not sure what the implications are.
- JdeBP 1y ago
  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 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/ 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.
  - anthk 1y ago
    I set TMPDIR to $HOME/tmp because of that.
    - blueflow 1y ago
      Except for the name, TMPDIR is unrelated to utmp.
      - anthk 1y ago
        I know; but it mitigates some potential race conditions.
        blueflow 1y ago
        More info on that?
ktm5j 1y ago
Looks like it is in Fedora.
- znpy 1y ago
  I wonder if there is some selinux policy to reduce the attack surface
  - JCattheATM 1y ago
    There almost certainly is, pretty sure Fedora has an SELinux policy for all software in base.
- tmtvl 1y ago
  Likewise in Arch.
- mlichvar 1y ago
  On Fedora it is setgid screen, not root.
jmclnx 1y ago
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
- jmclnx 1y ago
  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.
  - lazide 1y ago
    Damn, Slackware. That’s a name I haven’t heard in a very long time.
perlgeek 1y ago
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 :-)
- mjevans 1y ago
  Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096 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 https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
  - sillystuff 1y ago
    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
    - mjevans 1y ago
      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.
  - foresto 1y ago

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

by teddyh 1y ago

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

jesprenj 1y ago

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

JdeBP 1y ago
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 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/ 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.
- anthk 1y ago
  I set TMPDIR to $HOME/tmp because of that.
  - blueflow 1y ago
    Except for the name, TMPDIR is unrelated to utmp.
    - anthk 1y ago
      I know; but it mitigates some potential race conditions.
      - blueflow 1y ago
        More info on that?

ktm5j 1y ago

Looks like it is in Fedora.

znpy 1y ago
I wonder if there is some selinux policy to reduce the attack surface
- JCattheATM 1y ago
  There almost certainly is, pretty sure Fedora has an SELinux policy for all software in base.
tmtvl 1y ago
Likewise in Arch.
mlichvar 1y ago
On Fedora it is setgid screen, not root.

jmclnx 1y ago

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

jmclnx 1y ago
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.
- lazide 1y ago
  Damn, Slackware. That’s a name I haven’t heard in a very long time.

perlgeek 1y ago

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

mjevans 1y ago
Related... https://bugzilla.mozilla.org/show_bug.cgi?id=1966096 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 https://support.mozilla.org/en-US/questions/1510388 ) since it seemed to be the proper place, but no one seems to look at those.
- sillystuff 1y ago
  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
  - mjevans 1y ago
    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.
- foresto 1y ago