[Re: [yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch] On 14.11.30 (Sun 13:21) akuster808 wrote:
> > > On 11/30/2014 11:45 AM, Joe MacDonald wrote: > >[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. :-) > > To be honest, this package should be in one in core or meta-openembedded. I agree, but I'd like to see it moved to core if anywhere, since currently meta-selinux still doesn't have any layer dependencies beyond core. I'm not sure that's viable in the long term, but I think there's value in making selinux as light as possible for anyone wanting to use it. -J. > > - Armin > >-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 <[email protected]> > >>>--- > >>> > >>>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 <[email protected]> > >>>+ > >>>+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
signature.asc
Description: Digital signature
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
