Previously, we did not try to trap execve() in processes where the
architecture did not match the native or one of the compat architecture.
Now the filter will kill the process instead. This is safer, though
perhaps less convenient for the user.
When the "intercept" and "intercept_verify" options are enabled and
either argv[] or envp[] contains a string larger than the page size
(usually 4096), ptrace_readv_string() would fill the buffer with
mutiple copies of the same string. Fixes GitHub issue #453.
Also make sure we never call killpg(-1, SIGHUP), which would send
SIGHUP to process 1 (init). It is possible for cmnd_pid to be -1
in certain error conditions where sudo killed the command itself.
This may explain GitHub issue #458.
We cannot perform passwd/group lookups _after_ changing the root
directory. This does mean that symbolic links in a path are not
currently handled properly when matching chroot()ed commands.
Fixes a local privilege escalation vulnerability where a user could
craft their own nsswitch.conf file to load a shared library of their
choosing and run arbitrary code. CVE-2025-32463
Reported by Rich Mirch @ Stratascale Cyber Research Unit (CRU).
This fixes a bug where a user with sudoers privileges on a different
host could execute a command on the local host, even if the sudoers
file would not otherwise allow this. CVE-2025-32462
Reported by Rich Mirch @ Stratascale Cyber Research Unit (CRU).
fwrite is not the same as write; you have to explicitly compare against the length to detect errors, and sometimes number of items is mistaken for length.
A long time ago this was changed from TCSAFLUSH to TCSADRAIN due
to some systems having problems with TCSAFLUSH. That should no
longer be a concern. Using TCSAFLUSH ensures that password input
that has been received by the kernel, but not yet read by sudo,
will be discarded and not echoed.
If the user is not allowed to run a command, we try to give them a
more useful message than "Sorry, user foo may not run sudo on bar."
However, this should only be done when running, not listing, a
command. Otherwise, it would be possible for a user with no sudo
privileges to use "sudo -l /path/to/some/command" to determine
whether an executable exists in a directory that they do not have
search access to.
The intent is to allow the user to run a command or edit a file as
themself without entering a password. It should not apply to listing
a command via "sudo -l command".
