Control: severity -1 normal

On Mon, 17 Mar 2025 15:48:56 +0100 Vincent Lefevre <vinc...@vinc17.net>
wrote:
> Package: screen
> Version: 4.9.1-1
> Severity: grave
> Justification: user security hole
> 
> + 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.

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

> 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

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?

> (the kernel may offer protection for some directories
> like /tmp, but not all of them, and software should not rely on
> such protection anyway).

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

> 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.
[...]

So far as I can, see this is intentional: this file is meant to be
shared with other users.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
                                                 - Maurice Wilkes, 1949

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to