From: Joe MacDonald <Joe_MacDonald@mentor.com>
To: akuster808 <akuster808@gmail.com>
Cc: yocto@yoctoproject.org
Subject: Re: [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
Date: Sun, 30 Nov 2014 14:45:24 -0500 [thread overview]
Message-ID: <20141130194524.GO3886@mentor.com> (raw)
In-Reply-To: <547AA25B.4020506@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6472 bytes --]
[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.29 (Sat 20:51) akuster808 wrote:
> Joe,
>
> I went a head and updated to 7.4 which included the security fix.
> Thanks for the reminder.
Yeah, that's on my to-do list for meta-selinux, too. That's the right
course of action on this one. :-)
-J.
>
> - Armin
>
> On 11/27/2014 10:49 AM, Joe MacDonald wrote:
> >Importing the patch from meta-selinux, which itself was a backport from
> >the upstream source tree.
> >
> >Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >---
> >
> >I mentioned a while back that I had at least one patch in meta-selinux that may
> >apply to meta-security as well. I don't know if you guys are interested in this
> >or not since the primary tool to demonstrate the exploit is seunshare, but it is
> >a problem in libcap-ng itself and it is exploitable outside of the selinux
> >framework.
> >
> >-J.
> >
> > .../libcap-ng/libcap-ng/CVE-2014-3215.patch | 91 ++++++++++++++++++++++
> > recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 4 +-
> > 2 files changed, 94 insertions(+), 1 deletion(-)
> > create mode 100644 recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >
> >diff --git a/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >new file mode 100644
> >index 0000000..e9164d4
> >--- /dev/null
> >+++ b/recipes-security/libcap-ng/libcap-ng/CVE-2014-3215.patch
> >@@ -0,0 +1,91 @@
> >+libcap-ng: local privilege escalation due to capng_lock
> >+
> >+Following the discussion here:
> >+
> >+ http://openwall.com/lists/oss-security/2014/04/29/7
> >+
> >+This is known to impact SELinux tools, however the issue could be exploited by
> >+any application using the relevant functions in libcap-ng provided it is suid
> >+root.
> >+
> >+Upstream-Status: Backport
> >+
> >+Signed-off-by: Joe MacDonald <joe_macdonald@mentor.com>
> >+
> >+diff --git a/docs/capng_lock.3 b/docs/capng_lock.3
> >+index 7683119..a070c1e 100644
> >+--- a/docs/capng_lock.3
> >++++ b/docs/capng_lock.3
> >+@@ -8,12 +8,13 @@ int capng_lock(void);
> >+
> >+ .SH "DESCRIPTION"
> >+
> >+-capng_lock will take steps to prevent children of the current process to regain full privileges if the uid is 0. This should be called while possessing the CAP_SETPCAP capability in the kernel. This function will do the following if permitted by the kernel: Set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS.
> >++capng_lock will take steps to prevent children of the current process from gaining privileges by executing setuid programs. This should be called while possessing the CAP_SETPCAP capability in the kernel.
> >+
> >++This function will do the following if permitted by the kernel: If the kernel supports PR_SET_NO_NEW_PRIVS, it will use it. Otherwise it will set the NOROOT option on for PR_SET_SECUREBITS, set the NOROOT_LOCKED option to on for PR_SET_SECUREBITS, set the PR_NO_SETUID_FIXUP option on for PR_SET_SECUREBITS, and set the PR_NO_SETUID_FIXUP_LOCKED option on for PR_SET_SECUREBITS. If both fail, it will return an error.
> >+
> >+ .SH "RETURN VALUE"
> >+
> >+-This returns 0 on success and a negative number on failure. -1 means a failure setting any of the PR_SET_SECUREBITS options.
> >++This returns 0 on success and a negative number on failure. -1 means a failure to use PR_SET_NO_NEW_PRIVS and a failure setting any of the PR_SET_SECUREBITS options.
> >+
> >+ .SH "SEE ALSO"
> >+
> >+diff --git a/src/cap-ng.c b/src/cap-ng.c
> >+index bd105ba..422f2bc 100644
> >+--- a/src/cap-ng.c
> >++++ b/src/cap-ng.c
> >+@@ -45,6 +45,7 @@
> >+ * 2.6.24 kernel XATTR_NAME_CAPS
> >+ * 2.6.25 kernel PR_CAPBSET_DROP, CAPABILITY_VERSION_2
> >+ * 2.6.26 kernel PR_SET_SECUREBITS, SECURE_*_LOCKED, VERSION_3
> >++ * 3.5 kernel PR_SET_NO_NEW_PRIVS
> >+ */
> >+
> >+ /* External syscall prototypes */
> >+@@ -122,6 +123,14 @@ extern int capget(cap_user_header_t header, const cap_user_data_t data);
> >+ #define SECURE_NO_SETUID_FIXUP_LOCKED 3 /* make bit-2 immutable */
> >+ #endif
> >+
> >++/* prctl values that we use */
> >++#ifndef PR_SET_SECUREBITS
> >++#define PR_SET_SECUREBITS 28
> >++#endif
> >++#ifndef PR_SET_NO_NEW_PRIVS
> >++#define PR_SET_NO_NEW_PRIVS 38
> >++#endif
> >++
> >+ // States: new, allocated, initted, updated, applied
> >+ typedef enum { CAPNG_NEW, CAPNG_ERROR, CAPNG_ALLOCATED, CAPNG_INIT,
> >+ CAPNG_UPDATED, CAPNG_APPLIED } capng_states_t;
> >+@@ -663,15 +672,22 @@ int capng_change_id(int uid, int gid, capng_flags_t flag)
> >+
> >+ int capng_lock(void)
> >+ {
> >+-#ifdef PR_SET_SECUREBITS
> >+- int rc = prctl(PR_SET_SECUREBITS,
> >+- 1 << SECURE_NOROOT |
> >+- 1 << SECURE_NOROOT_LOCKED |
> >+- 1 << SECURE_NO_SETUID_FIXUP |
> >+- 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >++ int rc;
> >++
> >++ // On Linux 3.5 and up, we can directly prevent ourselves and
> >++ // our descendents from gaining privileges.
> >++ if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) == 0)
> >++ return 0;
> >++
> >++ // This kernel is too old or otherwise doesn't support
> >++ // PR_SET_NO_NEW_PRIVS. Fall back to using securebits.
> >++ rc = prctl(PR_SET_SECUREBITS,
> >++ 1 << SECURE_NOROOT |
> >++ 1 << SECURE_NOROOT_LOCKED |
> >++ 1 << SECURE_NO_SETUID_FIXUP |
> >++ 1 << SECURE_NO_SETUID_FIXUP_LOCKED, 0, 0, 0);
> >+ if (rc)
> >+ return -1;
> >+-#endif
> >+
> >+ return 0;
> >+ }
> >diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >index 3f225ba..1acf554 100644
> >--- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >+++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
> >@@ -8,7 +8,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
> > file://COPYING.LIB;md5=e3eda01d9815f8d24aae2dbd89b68b06"
> >
> > SRC_URI = "http://people.redhat.com/sgrubb/libcap-ng/libcap-ng-${PV}.tar.gz \
> >- file://python.patch"
> >+ file://python.patch \
> >+ file://CVE-2014-3215.patch \
> >+ "
> >
> > inherit lib_package autotools pythonnative
> >
> >
--
-Joe MacDonald.
:wq
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 501 bytes --]
next prev parent reply other threads:[~2014-11-30 19:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 18:49 [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch Joe MacDonald
2014-11-27 22:03 ` akuster808
2014-11-30 4:51 ` akuster808
2014-11-30 19:45 ` Joe MacDonald [this message]
2014-11-30 21:21 ` akuster808
2014-12-01 3:21 ` Joe MacDonald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141130194524.GO3886@mentor.com \
--to=joe_macdonald@mentor.com \
--cc=akuster808@gmail.com \
--cc=yocto@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.