[yocto] [meta-security][PATCH] libcap-ng: port CVE-2014-3215 patch
Joe MacDonald
Joe_MacDonald at mentor.com
Sun Nov 30 19:21:22 PST 2014
[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 <joe_macdonald at 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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20141130/9f49408a/attachment.pgp>
More information about the yocto
mailing list