user debian-rele...@lists.debian.org
usertag 1100699 + bsp-2025-03-ca-montreal
thank you
On 2025-03-17 15:48:56, Vincent Lefevre wrote:
> Package: screen
> Version: 4.9.1-1
> Severity: grave
> Justification: user security hole
>
> + possible data loss via a symlink attack
[...]
> The screen-exchange feature (">" in copy mode) is also insecure:
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.
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.
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.
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?
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.
--
VBscript: la simplicité du C, la puissance du BASIC
- Mathieu Petit-Clair
