On 2025-03-28 14:59:50 -0400, Antoine Beaupré wrote:
> 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?
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.
> On 2025-03-17 15:54:06, Vincent Lefevre wrote:
> > tags 1100699 security
>
> 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.
Well, the issue is triggered by a user action. Moreover, the attack
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...
> Now, onto the actual vulns.
>
> > 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.
>
> 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.
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).
> And regarding the hardcopy:
>
> > 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!
>
> I haven't checked that codepath yet, but at this point, I wonder...
>
> Is it worth keeping screen in Debian at all?
I'm wondering too, but I've never really used tmux until now.
> 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 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.
--
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
