The CheckPid() function was introduced to address CVE-2023-24626, to
prevent sending SIGCONT and SIGHUP to arbitrary PIDs in the system. This
fix still suffers from a TOCTOU race condition. The client can replace
itself by a privileged process, or try to cycle PIDs until a privileged
process receives the original PID.
To prevent this, always send signals using the real privileges. Keep
CheckPid() for error diagnostics. If sending the actual signal fails
later on then there will be no more error reporting.
It seems the original bugfix already introduced a regression when
attaching to another's user session that is not owned by root. In this
case the target sessions runs with real uid X, while for sending a
signal to the `pid` provided by the client real uid Y (or root
privileges) are required.
This is hard to properly fix without this regression. On Linux pidfds
could be used to allow safely sending signals to other PIDs as root
without involving race conditions. In this case the client PID should
also be obtained via the UNIX domain socket's SO_PEERCRED option,
though.
In setuid-root context the current error messages give away whether
certain paths not accessible by the real user exist and what type they
have. To prevent this only output generic error messages in setuid-root
context.
In some situations, when an error is pertaining a directory and the
directory is owner by the real user then we can still output more
detailed diagnostics.
This change can lead to less helpful error messages when Screen is
install setuid-root. More complex changes would be needed to avoid this
(e.g. only open the `SocketPath` with raised privileges when
multi-attach is requested).
There might still be lingering some code paths that allow such
information leaks, since `SocketPath` is a global variable that is used
across the code base. The majority of issues should be caught with this
fix, however.
This temporary chmod of the PTY to mode 0666 is most likely a remnant of
past times, before the PTY file descriptor was passed to the target
session via the UNIX domain socket.
This chmod() causes a race condition during which any other user in the
system can open the PTY for reading and writing, and thus allows PTY
hijacking.
Simply remove this logic completely.
As documented in libutempter:
"During execution of the privileged process spawned by these
functions, SIGCHLD signal handler will be temporarily set to
the default action."
Thus in case a SIGCHLD has been lost, we send a SIGCHLD to
oneself in order to avoid zombies:
https://savannah.gnu.org/bugs/?25089
bug #23952
Unfortunately, screen's handling of serial ports is
somewhat incomplete: You can set the baud rate and the
word length (cs7), but not the number of stop bits
and/or the parity settings.
Since the OS calls are readily available, adding this
to a future version of screen would proably be easy
enough to do inside tty.sh.
bug #61534
Screen allowed you to specify a long session name
(without any errors), but didn't run if session name
was too long.
This fix sets limit for 80 symbols and doesn't allow
to use session names longer then this limit.
Screen should print error message in case of too long
session name.
* Add the '-i' ('--install') flag; this resolves ticket #60751.
* Remove the spurious 'exec', which causes the shell script to be
replaced entirely with the 'autoreconf' process, and thus prevents
the rest of the script from being run; after this commit, the
director 'autom4te.cache' does actually get removed.
Reported-by: Tushar T <sukucorp>
