Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list] 
Message-ID: <20250513182106.414b569f@plasteblaster>
Date: Tue, 13 May 2025 18:21:06 +0200
From: "Dr. Thomas Orgis" <thomas.orgis@...-hamburg.de>
To: Matthias Gerstner <mgerstner@...e.de>
CC: <oss-security@...ts.openwall.com>
Subject: Re: screen: Multiple Security Issues in Screen
 (mostly affecting release 5.0.0 and setuid-root installations)

Moin Matthias,

regarding this bit with screen-4.9.1:

Am Mon, 12 May 2025 17:24:26 +0200
schrieb Matthias Gerstner <mgerstner@...e.de>:

> 3.c) Screen by Default Creates World Writable PTYs (CVE-2025-46803)
> -------------------------------------------------------------------
> 
> In Screen version 5.0.0 the default mode of pseudo terminals (PTYs)
> allocated by Screen was changed from 0620 to 0622, thereby allowing
> anyone to write to any Screen PTYs in the system. Security-wise this
> results in some of the issues that have been outlined in issue 3.b),
> without the information leak aspects, however.
> 
> The history of the default PTY mode in Screen is rather complex. Let's
> have a look at the situation in version 4.9.1 (and a lot of older
> versions):
> 
> - There is a 0622 default mode in the code in process.c line 207 [14].
>   This is only a fallback that should not become active unless the code
>   is compiled in unusual ways.
> - A default mode of 0620 is applied in configure.ac line 811 [15], which
>   results in a safe default when compiling Screen using autotools.
> - In acconfig.h line 81 [16] the following is stated:
>   
>   > define PTYMODE if you do not like the default of 0622, which allows public write to your pty.  
>   
>   Thus in this version there is an inconsistency between the default
>   mode on autoconf level and the default on source code level, but in
>   the end the (safe) autoconf default wins.

Are you sure the safe default wins? I also read configure.ac as such,
at a first glance … but running plain configure results in

$ grep PTYMODE config.h
 * define PTYMODE if you do not like the default of 0622, which allows 
/* #undef PTYMODE */

on a Debian 12 machine with perhaps a specific setup because of
multiuser access — exactly the situation where the world-writable ptys
are of most concern.  Configure messages:

configure: checking for ptyranges...
configure: checking default tty permissions/group...
checking for write... /usr/bin/write
checking for xterm... no
- ptys are world accessable

This system does not have xterm installed in /usr/. It is a headless
shell server. But also running the configure code on an Ubntu 22.04.5
box, with write and xterm shows this:

~$ sh -x  /dev/shm/ttygrp.sh "$(command -v write)" "$(command -v xterm)"
+ AWK=awk
+ WRITEPATH=/usr/bin/write
+ XTERMPATH=/usr/bin/xterm
+ found=
+ test -n /usr/bin/write/usr/bin/xterm
+ findfollow=
+ lsfollow=
+ find /usr/bin/write /usr/bin/xterm -follow -print
+ found=/usr/bin/write
/usr/bin/xterm
+ test -n /usr/bin/write
/usr/bin/xterm
+ findfollow=-follow
+ lsfollow=L
+ test -n /usr/bin/xterm
+ ls -lL /usr/bin/xterm
+ sed -n -e 1p
+ awk {print $4}
+ ptygrpn=root
+ test tty != root
+ XTERMPATH=
+ test -n /usr/bin/write
+ find /usr/bin/write -follow -perm -2000 -print
+ found=
+ test -n 
+ echo - ptys are world accessable
- ptys are world accessable

So the code sees

-rwxr-xr-x 1 root root 22920 Apr  9  2024 /usr/bin/write.ul
-rwxr-xr-x 1 root root 852552 Mär 11  2022 /usr/bin/xterm

and deduces that ptys should be world-accessible (see typo, btw.). Why
does it enter that code path at all? This test program fails on the
Debian 12 multiuser server, and probably everywhere:

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

int
main()
{
  struct stat sb;
  char *x,*ttyname();
  int om, m;
  FILE *fp;

  if (!(x = ttyname(0))) return 1;
  if (stat(x, &sb)) return 2;
  om = sb.st_mode;
  if (om & 002) return 0;
  m = system("mesg y");
  if (m == -1 || m == 127) return 3;
  if (stat(x, &sb)) return 4;
  m = sb.st_mode;
  if (chmod(x, om)) return 5;
  if (m & 002) return 0;
  if (sb.st_gid == getgid()) return 6;
  if (!(fp=fopen("conftest_grp", "w")))
    return 7;
  fprintf(fp, "%d\n", sb.st_gid);
  fclose(fp);
  return 0;
}

Why? Because stdin is no terminal for configure tests.* The much
simplified logic in the screen-5.0.0 configure (which is also really
small and fast, to name an improvement) does not suffer from these
quirks and just uses sane defaults.

So screens opened with screen-4.9.1 are world-writable basically
everywhere without setgid xterm or write binaries, which is rather
counter-intuitive for admins who might even remove these bits to
enhance security.

So a better workaround is to supply _both_ mode and groups, to avoid
the wonky group detection logic:

$ ./configure --with-pty-mode=0620 --with-pty-group=tty
[…]
$ grep -e PTYMODE -e PTYGROUP config.h
 * define PTYMODE if you do not like the default of 0622, which allows 
 * define PTYGROUP to some numerical group-id if you do not want the
#define PTYMODE 0620
#define PTYGROUP tty

Still, I'd rather expect, in the absence of requested group write
permissions to have the terminals as 0600, not 0622. This is really not
secure-by-default.


Alrighty then,

Thomas

* I admit that I was not sure of that, but rather hope that this would
  be ensured by autoconf, as it would introduce horrible inconsistency
  between automated and interactive builds.

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.