Bug 1372830 (CVE-2016-7032)
| Summary: | CVE-2016-7032 sudo: noexec bypass via system() and popen() | ||
|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Kurt Seifried <kseifried> |
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | carnil, dapospis, dkopecek, fweimer, kseifried, pkis, security-response-team, slawomir, thoger, yozone |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | sudo 1.8.15 | Doc Type: | If docs needed, set a value |
| Doc Text: |
It was discovered that the sudo noexec restriction could have been bypassed if application run via sudo executed system() or popen() C library functions with a user supplied argument. A local user permitted to run such application via sudo with noexec restriction could use this flaw to execute arbitrary commands with elevated privileges.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-12-06 11:56:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1391937, 1391938, 1391939, 1391940 | ||
| Bug Blocks: | 1372831 | ||
|
Description
Kurt Seifried
2016-09-02 19:56:52 UTC
Acknowledgments: Name: Florian Weimer (Red Hat) Apparently upstream is aware of the problem and addressed system() and popen() cases about a year ago: https://www.sudo.ws/devel.html#1.8.15rc1 https://www.sudo.ws/repos/sudo/rev/58a5c06b5257 https://www.sudo.ws/repos/sudo/rev/a826cd7787e9 (In reply to Tomas Hoger from comment #2) > Apparently upstream is aware of the problem and addressed system() and > popen() cases about a year ago: > > https://www.sudo.ws/devel.html#1.8.15rc1 > https://www.sudo.ws/repos/sudo/rev/58a5c06b5257 > https://www.sudo.ws/repos/sudo/rev/a826cd7787e9 Ahh, maybe that's why I was vaguely familiar with this issue. True blocking still needs a seccomp filter, though. The sudo version in Red Hat Enterprise Linux 5 also lacks this commit: https://www.sudo.ws/repos/sudo/rev/cbaa1d4b0f8a Blocking wrappers for posix_spawn() and posix_spawnp() are relevant. exect() seems BSD-specific API, and execvpe() was only added in glibc 2.11, while Red Hat Enterprise Linux 5 includes glibc 2.5. (In reply to Kurt Seifried from comment #0) > The right fix is to set a seccomp filter which blocks execve in the DSO > (after enabling PR_SET_NO_NEW_PRIVS), rather than attempting to play > catch-up with glibc. As far as I can see, such seccomp approach would only be viable on Red Hat Enterprise Linux 7 or later. I'm also unsure if sudo upstream would be willing to write the code. Do you or sudo maintainer have capacity to implement this and get is merged upstream? (In reply to Tomas Hoger from comment #5) > (In reply to Kurt Seifried from comment #0) > > The right fix is to set a seccomp filter which blocks execve in the DSO > > (after enabling PR_SET_NO_NEW_PRIVS), rather than attempting to play > > catch-up with glibc. > > As far as I can see, such seccomp approach would only be viable on Red Hat > Enterprise Linux 7 or later. I'm also unsure if sudo upstream would be > willing to write the code. Do you or sudo maintainer have capacity to > implement this and get is merged upstream? A while back I wrote: https://github.com/fweimer/noexecve/blob/master/noexecve.c It's not 100% complete because it does not deal with multi-arch system calls. On x86_64, a program could still evade this by jumping to short mode and doing the i386 syscalls (which have different numbers), or call the x32 syscalls. In most cases, this will need some sort of code execution exploit in the target process because the process will not expose this sort of capability to the end user. Would this also need other tweaks for other non-x86 architectures? Would use of libseccomp be recommended to hide platform specific details? (In reply to Tomas Hoger from comment #8) > Would this also need other tweaks for other non-x86 architectures? Other architectures may have different forms of compatibility system calls, yes. > Would use of libseccomp be recommended to hide platform specific details? I don't know if it handles multi-arch system calls in the way needed. I have asked Paul Moore. The following changes were applied upstream for inclusion in 1.8.18p1: * Wrapper for wordexp() was added to sudo_noexec.so which forces the use of WRDE_NOCMD flag in wordexp(). https://www.sudo.ws/repos/sudo/rev/e7d09243e51b https://www.sudo.ws/repos/sudo/rev/7b8357b0a358 https://www.sudo.ws/repos/sudo/rev/167a518d8129 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. * seccomp support was added to sudo_noexec.so. https://www.sudo.ws/repos/sudo/rev/59d76bdc0f0c https://www.sudo.ws/repos/sudo/rev/5d88d7cda853 NEWS file entry: * On Linux systems, sudo_noexec.so now uses a seccomp filter to disable execute access if the kernel supports seccomp. This is more robust than the traditional method of using stub functions that return an error. As system()/popen() and wordexp() were fixed in different versions, the wordexp() case will be tracked under separate CVE-2016-7076 - see bug 1384982. Public now via upstream advisory. External References: https://www.sudo.ws/alerts/noexec_bypass.html 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 |