+ possible data loss via a symlink attack
The hardcopy (C-a h) in screen works in the following way:
│ hardcopydir directory
│
│ Defines a directory where hardcopy files will be placed. If unset,
│ hardcopys are dumped in screen's current working directory.
(from the screen(1) man page).
First, using screen's current working directory is insecure,
even though this is documented.
Moreover, the problem gets worse because
* the created file is not protected against read access by
other users;
* it is subject to a symlink attack; and if the target file of
the symbolic link already exists, it will be overwritten!
Note: If the file does not exists yet, the umask is honored.
But if the file already exists (possibly belonging to another
user, with -rw-rw-rw- (666) permissions), the owner and
permissions are preserved, which can be a way to even bypass a
077 umask (the kernel may offer protection for some directories
like /tmp, but not all of them, and software should not rely on
such protection anyway).
The screen-exchange feature (">" in copy mode) is also insecure:
│ > sets the (second) mark and writes the contents of the paste buffer
│ to the screen-exchange file (/tmp/screen-exchange per default) once
│ copy-mode is finished.
The default file is under /tmp (poor default choice) and not protected
against read access by other users. However, a symlink attack does not
seem to be possible: I get an error "No write to links, please." if
/tmp/screen-exchange is a symbolic link.
user debian-release@lists.debian.org usertag 1100699 + bsp-2025-03-ca-montreal thank you [...] Okay, so this bug is.... interesting. First, the "screen-exchange" issue has been reported upstream ... in 2009: https://savannah.gnu.org/bugs/index.php?25296 That bug report refers to: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=433338 which is marked as fixed in 2007. It is, presumably, not fixed? I couldn't find an upstream issue with hardcopy, so I guess that needs to be forward upstream. That said, I wonder about your disclosure process. I am not sure screen has any sort of disclosure process, but those should have been submitted upstream, privately, or at least shared with the Debian security team. `reportbug` would have told you to do the latter if you would have tried to lay down that `security` tag while filing the bug report (as opposed to later like this). screen is used by thousands of sysadmins all across the world, and it's a critical piece of infrastructure, we need to be more careful. Now, onto the actual vulns. That might be right, but even looking at that code there's a TOCTOU problem with it: someone could theoritically sweep in a symlink between the check time and the use time. And regarding the hardcopy: I haven't checked that codepath yet, but at this point, I wonder... Is it worth keeping screen in Debian at all? It's an extremely old codebase, with many issues. I suspect those security issues are one of many remaining issues. I'm also worried about escape codes, for example. Wouldn't our time be put to better use by shipping a screen-compatible tmux profile? I would tend to use this as an opportunity to remove screen(1) from Debian altogether, personally. (And I speak as someone who's been struggling to switch to tmux for years.) a.
Well, in the changelog, the fix is just: Don't create /tmp/screen-exchange with default mode 0666. Closes: #433338. This is far from being enough. can easily be guessed (note that this is a simple attack here, not even based on a race condition). In such a case, I think that it is better to disclose the issue so that the user does not use the insecure commands. Concerning the security tag, I think I now understand what happened: When I got the following question Do any of the following apply to this report? [...] 9 security This problem is a security vulnerability in Debian. [...] I chose 9 as usual. But the fact is that "security" was selected by default, and choosing 9 had the effect to remove this tag!!! reportbug did not behave like that in the past, so that I did not pay attention to this change. For historical users of reportbug, this is very misleading. It will probably be some time before I get used to this new behavior... I hadn't looked at the code. I thought that screen opened the file in an atomic way with O_NOFOLLOW (in addition to avoiding the race condition, this seems simpler). I'm wondering too, but I've never really used tmux until now. I don't know what you mean by that, but there should be a HOWTO to tell users how to switch from screen to tmux. In particular, each user may have his own .screenrc file, so that a default profile might not be very useful. The most complex things may be the equivalent of hardstatus / termcapinfo / caption.
On 2025-03-29 02:38:26, Vincent Lefevre wrote: [...] Oh yeah. There's no way there can be a full, easy transition. What I'm suggesting is a more "basic" conversion, where "control-a" works as expected. I've been working on a blog post to explain my transition... Essentially, I'm learning "control-b" now, because I can't really reconfigure tmux everywhere, but since this is Debian, *we* could deploy some *other* package that could provide a better compatibility shim, as far as it's possible in tmux... A.
On Fri, 28 Mar 2025 14:59:50 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= <anarcat@debian.org> wrote: i switched to tmux many years ago, but i think you should give users a lot of warning before removing screen (NEWS.Debian in screen, release-notes and then remove a future stable release etc?). i believe screen does have some features not in tmux at all, so you should expect that removing it will cause complaints, and maybe failed upgrades for anyone doing dist-upgrade inside screen. Debian's own release-notes recommend using screen for upgrades (and adding tmux is still an MR -- there was quite a bit of scepticism that tmux was stable enough to always replace it).
Control: severity -1 normal Many commands write to the working directory. Why is it specifically unacceptable for screen to do this? (I do think that something like ~/.local/screen would be a better default.) However, the hardcopy function is intended to append to an existing file. So it shouldn't be unconditionally replaced. I'm not sure what would be a reasonable rule for when it's "safe" to append to an existing file. Should we just check file ownership after opening it? Right. I think a similar symlink check ought to be applied as for screen-exchange. (But even that check ought to be improved to use O_NOFOLLOW when writing to any shared directory.) [...] So far as I can, see this is intentional: this file is meant to be shared with other users. Ben.
Control: severity -1 grave No, I changed my mind while composing that reply and looking further at the code, but I forgot to remove this. Ben.
Hi, After checking with the security team, we have decided to add the trixie-ignore tag. I also would expect that the issues reported should get a CVE assigned, such that they can be tracked outside of Debian too. This should ideally be addressed upstream. We can try to remove screen from forky, but somebody would need to figure out what would be required. It's a key package and as I recall seeing used by d-i. As mentioned before in this bug, also "used" by the release-notes. Paul
Control: clone -1 -2 Control: retitle -1 screen: screen-exchange insecure default path/permissions (/tmp/screen-exchange) Control: found -1 5.0.1-1 Control: found -1 5.0.1-1.1 Control: retitle -2 screen: hardcopy file handling in shared directories may be insecure Control: severity -2 important Control: tags -2 - security Hi, There are two separate issues combined in this one report: * screen-exchange permissions/location (CVE-tracked; reported upstream) * hardcopy file handling (no upstream report) Splitting into two bugs. Cheers, Peter Dey