From https://www.openwall.com/lists/oss-security/2023/12/21/9 a new CVE has been reserved against the sudo package.

''' Our recent paper<https://arxiv.org/pdf/2309.02545.pdf> [AsiaCCS'24] describes a potential vulnerability where stack/register variables can be flipped via fault injection, affecting execution flow in security-sensitive code. There are mitigation strategies you may be interested in incorporating into your code:

Take this vulnerable code, for example:

int auth = 0;

//password check code that sets auth variable

if(auth != 0)

return AUTHSUCCESS;

else

return AUTHFAILURE;

The idea is that any bit can be flipped in auth, and it will result in a mis-authentication. We prove this is a potential vulnerability in OpenSSH, OpenSSL, MySQL, and SUDO. To mitigate this, it is important to have tight logic such that a single-bit flip will not result in unintended execution. For example:

int auth = 0xbe405d1a;

// password check code that sets auth variable to 0x23ab9701 is successful

If(auth == 0x23ab9701)

return AUTHSUCCESS;

else

return AUTHFAILURE;

In this case, the auth variable must be corrupted into the exact authentication pattern, which is fairly improbable.

We issued CVE-2023-42465 for SUDO for this vulnerability.

Here is the patch implemented in v1.9.15.

https://github.com/sudo-project/sudo/commit/7873f8334c8d31031f8cfa83bd97ac6029309e4f

Paper link: https://arxiv.org/abs/2309.02545

Caner Tol Worcester Polytechnic Institute https://vernamlab.org<https://vernamlab.org/> '''

In Sudo through 1.9.17p2 before 3e474c2, a failure of a setuid, setgid, or setgroups call, during a privilege drop before running the mailer, is not a fatal error and can lead to privilege escalation.

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to Sudo by entering a password of seven characters or fewer. The impact could vary depending on the compiler and processor architecture.

An attacker can leverage sudo's -R (--chroot) option to run arbitrary commands as root, even if they are not listed in the sudoers file. Sudo versions 1.9.14 to 1.9.17 inclusive are affected.

Admin Framework. A logic issue was addressed with improved checks.

A vulnerability was found in sudo. Exposure in how sudoedit handles user-provided environment variables leads to arbitrary file writing with privileges of the RunAs user (usually root). The prerequisite for exploitation is that the current user must be authorized by the sudoers policy to edit a file using sudoedit.

Sudo before 1.9.13p2 has a double free in the per-command chroot feature.

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudoedit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

selinuxeditcopytfiles in sudoedit in Sudo before 1.9.5 allows a local unprivileged user to gain file ownership and escalate privileges by replacing a temporary file with a symlink to an arbitrary file target. This affects SELinux RBAC support in permissive mode. Machines without SELinux are not vulnerable.

A heap-based buffer overflow was found in the way sudo parses command line arguments.

As per the researcher this vulnerability:

- is exploitable by any local user (normal users and system users, sudoers and non-sudoers), without authentication (i.e., the attacker does not need to know the user's password);

- was introduced in July 2011 (commit 8255ed69), and affects all legacy versions from 1.8.2 to 1.8.31p2 and all stable versions from 1.9.0 to 1.9.5p1, in their default configuration.

This could lead to privilege escalation.

A flaw was found in sudo before version 1.8.28. When sudo is configured to allow a user to run commands as an arbitrary user via the 'ALL' keyword in a 'Runas' specification, it is possible to run commands as root.

Apple macOS Catalina is vulnerable to a stack-based buffer overflow, caused by improper bounds checking by the privileged sudo process. By sending an overly long string to the stdin of getln() in tgetpass.c., a local attacker could overflow a buffer and execute arbitrary code on the system.

Last updated 25 August 2025

Sudo before 1.9.13 does not escape control characters in sudoreplay output.

Sudo before 1.9.13 does not escape control characters in log messages.

Last updated 25 August 2025

Sudo before 1.6.6 contains an off-by-one error that can result in a heap-based buffer overflow that may allow local users to gain root privileges via special characters in the -p (prompt) argument, which are not properly expanded.

Quoting first paragraph from [1]: https://bugzilla.redhat.com/showbug.cgi?id=173008

for issue description: ====================== When starting a program via "su - user -c program" the user session can escape to the parent session by using the TIOCSTI ioctl to push characters into the input buffer. This allows for example a non-root session to push "chmod 666 /etc/shadow" or similarly bad commands into the input buffer such that after the end of the session they are executed.

References: [1] https://bugzilla.redhat.com/showbug.cgi?id=173008 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628843

sudo 1.8.12 will be released shortly [1] which includes sanity checks for the TZ environment variable.

This issue was previously discussed here: http://www.openwall.com/lists/oss-security/2014/10/15/24

There is an associated Debian bug: https://bugs.debian.org/772707 From http://www.sudo.ws/alerts/tz.html

Summary:

Prior to sudo 1.8.12, the TZ environment variable was passed through unchecked. Most libc tzset() implementations support passing an absolute pathname in the time zone to point to an arbitrary, user-controlled file. This may be used to exploit bugs in the C library's TZ parser or open files the user would not otherwise have access to. Arbitrary file access via TZ could also be used in a denial of service attack by reading from a file or fifo that will block.

Beginning with sudo 1.8.12, TZ is only passed through by default if it is considered "safe". The TZ variable is now considered "unsafe" if any of the following are true:

o It consists of a fully-qualified path name that does not match the location of the zoneinfo directory.

o It contains a ".." path element.

o It contains white space or non-printable characters.

o It is longer than the value of PATHMAX.

Sudo versions affected:

Sudo versions prior to 1.8.12 are affected.

Details:

Unix systems support a user-specified time zone value stored in the TZ environment variable. On many systems, the value of TZ is ignored for set user ID processes (such as sudo) if it does not pass certain sanity checks. However, while the value may be ignored, it is not actually removed from the environment. As such, a program run via sudo will inherit the (possibly malicious) value of TZ.

A user with sudo access may take advantage of this to exploit bugs in the C library functions which parse the TZ environment variable. The TZ handling in most C libraries (including GNU libc and the tzcode used by BSD and others) supports reading arbitrary files.

By setting TZ to a fully-qualified path name, a command run via sudo may be used to read (but not disclose the contents of) files that the user would not otherwise be able to open. This is generally benign for regular files, but it may be possible to change the behavior of the system by reading from device special files. For instance, it may be possible to hijack the output from a terminal device file, consume kernel log messages or cause a tape drive to change position. It may also be possible to cause a command run by sudo to hang if TZ is set to the value of a named pipe or a device special file that blocks on read.

Impact:

A user with sudo access may be able to exploit parsing bugs in the time zone parsing functions of the system's C library functions. The user may also be able to read arbitrary files, potentially causing changes in system behavior when reading certain device special files or simply causing the program run via sudo to block.

Fix:

The bug is fixed in sudo 1.8.12.

[1]: http://seclists.org/oss-sec/2015/q1/486

A vulnerability in functionality for adding support of SHA-2 digests along with the command was found. The sudoers plugin performs this digest verification while matching rules, and later independently calls execve() to execute the binary. This results in a race condition if the digest functionality is used as suggested (in fact, the rules are matched before the user is prompted for a password, so there is not negligible time frame to replace the binary from underneath sudo). Versions affected are since 1.8.7.

CVE assignment:

http://seclists.org/oss-sec/2015/q4/327

sudoedit in Sudo before 1.8.15 allows local users to gain privileges via a symlink attack on a file whose full path is defined using multiple wildcards in /etc/sudoers, as demonstrated by "/home///file.txt."

A flaw was found in the way sudo read the device number of the tty from field 7 (ttynr) from "/proc/[pid]/stat". A local attacker could use this flaw to escalate his privilege to root.