It was discovered that the sudo noexec restriction could have been bypassed if application run via sudo executed wordexp() C library function with a user supplied argument. A local user permitted to run such application via sudo with noexec restriction could possibly use this flaw to execute arbitrary commands with elevated privileges.
The sudo allows the use of NOEXEC tag it its configuration to define that program executed via sudo can not execute any other commands. This restriction is implemented via dynamic library which is preloaded for the executed program and which implements wrappers for various exec functions.
It was discovered that the wrapping of exec functions is insufficient to block command execution via glibc APIs that internally call one of the exec functions - system() or popen() (see CVE-2016-7032 tracked via bug 1372830), and wordexp (CVE-2016-7076, tracked via this bug).
This issue was originally tracked under single CVE via bug 1372830, but the CVE assignment was split because of different versions in which problems for system()/popen() and wordexp() were fixed.
The noexec bypass using wordexp() is being fixed in 1.8.18p1 (see bug 1372830 comment 11):
* Wrapper for wordexp() was added to sudo_noexec.so which forces the use of WRDE_NOCMD flag in wordexp().
NEWS file entry:
* When sudo_noexec.so is used, the WRDE_NOCMD flag is now added
if the wordexp() function is called. This prevents commands
from being run via wordexp() without disabling it entirely.
Name: Florian Weimer (Red Hat)
Fixed now in 1.8.18p1:
Public now via upstream advisory.
Created sudo tracking bugs for this issue:
Affects: fedora-all [bug 1389496]
This issue has been addressed in the following products:
Red Hat Enterprise Linux 6
Red Hat Enterprise Linux 7
Via RHSA-2016:2872 https://rhn.redhat.com/errata/RHSA-2016-2872.html