+ 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

Hi folks,

Please don't :)  If this package is considered orphaned, I'm happy to
adopt.

For the screen-exchange part of this bug, upstream already suggested a
solution: https://savannah.gnu.org/bugs/index.php?25296

     If you set the screen exchange files to something different than the
     "public" file, you should make sure that it's not a public writeable
     directory. The same is true for all files screen writes, like screen
dumps.
     $(HOME)/screen-exchange would be a good idea.

     IMHO the debian folks should just put
        bufferfile $HOME/screen-exchange
     in their /etc/screenrc file and not mess with the source.

I would propose a slight variation of this - add:

     bufferfile $HOME/.screen-exchange

to our default /etc/screenrc

Plus a NEWS entry documenting the user behaviour change needed.

Cheers,
Peter Dey

It has never been clearly documented that this was a "public" file
(only in one place in the screen(1) man page, about "writebuf",
not even in Section "FILES"). And in any case, such a feature
should have not been enabled by default (since security and privacy
have become a concern), at least without a warning for the user,
and asking for confirmation.

Since /etc/screenrc is always read, I suppose that this would be fine.

Yes.

Thanks,

Upstream seems to disagree; and RedHat doesn't consider this to be a
security
issue:

     Red Hat does not consider this to be a security issue. Affected file
is
     supposed to be used to exchange information between local system
users,
     therefore open  permissions are intentional.
         -- https://access.redhat.com/security/cve/cve-2009-1214

Regardless, Screen 5.x is probably the right time to change Debian's
behaviour.
I will change the default screenrc to use $HOME/.screen-exchange in the
next
upload.

Cheers,
Peter

We believe that the bug you reported is fixed in the latest version of
screen, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1100699@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Peter Dey <debian@realmtech.net> (supplier of updated screen package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Wed, 17 Jun 2026 14:09:15 +0200
Source: screen
Architecture: source
Version: 5.0.1-3
Distribution: unstable
Urgency: medium
Maintainer: Axel Beckert <abe@debian.org>
Changed-By: Peter Dey <debian@realmtech.net>
Closes: 484655 545182 600649 611228 694178 1061448 1100699 1117241 1134721 1136895
Changes:
 screen (5.0.1-3) unstable; urgency=medium
 .
   * Set Debian default terminal type to screen5 in /etc/screenrc
     (Closes: #1134721)
   * Move default bufferfile in screenrc to $HOME/.screen-exchange
     (Closes: #1100699)
   * Added patch 98: Fix uninitialised buffer for caption/hardstatus expansions
     (Closes: #1136895)
   * Added patch 99: Fix off-by-one in resize CheckMaxSize guard
     (Closes: #1117241)
   * Fix GNU/Hurd builds (missing MAXPATHLEN define)
   * Drop 13split_info_files.patch (obsolete)
   * Stop deleting named pipes in /run/screen at startup (Closes: #545182)
   * Removing orphaned package screenie from Suggests
   * Modernise session creation timestamp handling in patches 81 & 82
     (Closes: #484655, #1061448)
   * Fix resize prompt wording for vertical splits (Closes: #600649)
   * Added patch 101: Remove duplicated permission sentence from manpage
     (Closes: #611228)
   * Added patch 102: Fix documentation for $TERM default (Closes: #694178)
Checksums-Sha1:
 2d11676b29fbef35337e58a5315afecb2859d3a2 2316 screen_5.0.1-3.dsc
 63eb25a7e99d6e1a2c00f2790817d82b7efcdf31 58936 screen_5.0.1-3.debian.tar.xz
 5e7a82072f9edab531d427a57ab98543c896eb2a 5956 screen_5.0.1-3_source.buildinfo
Checksums-Sha256:
 4e1b1e43685e5065ed3fc19cad3ad0192299bad61fe516a0edf2040b48f8c68d 2316 screen_5.0.1-3.dsc
 53a5e74a791c69dcac796c2ccbe6702dae35ee24fd42ef5e8fce8cfc25fe01a8 58936 screen_5.0.1-3.debian.tar.xz
 cdffadab4a98068d5fc727c5b4ce2b341ad8a97ef0497776ab58b1335ae5a590 5956 screen_5.0.1-3_source.buildinfo
Files:
 4e07d5b0ec0b4c968cedbe22ab74f685 2316 misc optional screen_5.0.1-3.dsc
 ed3cf18d3b0055eb74f34b4c5b883ada 58936 misc optional screen_5.0.1-3.debian.tar.xz
 fd6343aee245d55463d0646cadd9ba74 5956 misc optional screen_5.0.1-3_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEmbRSsR88dMO0U+RvvthEn87o2ogFAmo07nIACgkQvthEn87o
2og4Hw//cusHGECxxzdo3W8FOeEzsLIBc35w8sEGIC2vaAzUi8moJOqPlASaksS3
dWcy7WoLG/xcwbRXjrA9vpKQriRy+QQhf0W9FZ/+0KydGRVZGMRQVWOTpfpi6Lwh
9W+ODwhASHCjSGbeztIoMg4fHyYNxGJnl8XMVEZ+74rTuBPCMBfZ7QPjN+xosvhg
So7/NDoFBtJkiscRHSWh7ZaNmPEk2gvy0ELE6yCXiY2+iNrlrcGUg/2kPg2eEna0
ius53rZb5H3H2OR6PigMdPbX1qe5PrfXuhKhXqRWQ9Ni0tfmR1cTI50itz1W7aDL
2hUbSCkvSw0KEYTOgUOMeku3lQ3wJ58KjkMsR825s4bwMRhTslpGXWjXkq17H9C5
d8SNoMUi7E8xk+mBKKrXqpu5p9aOyspyycBxDH1JGtPjvLITlJ6awyX2USjQu7Zk
bkrPpqxSa05J8TtrKoelMi2QGC+Jbv9ZQ7VL0QTJ5DJX+EgtTMwbszONHDkgQkB6
MubWJBXzWFAnx7QU96p5jYCchZlynFVrAKTmVXlA4nC21IJXwrcyZC8GuJEUQhqI
dfraK0hoJK/4TKwaeHBnAFAz9D2l/N480vxEf56lwOeiuYeLF9Nk+KPURMG0ctbn
N2/6mLNVvP1k2nN6NAxKN06JKq+JlRnEs68l3cbYIqFuh7Gr+AA=
=+gJR
-----END PGP SIGNATURE-----