[
https://issues.apache.org/jira/browse/YARN-6721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16340132#comment-16340132
]
Jim Brennan commented on YARN-6721:
-----------------------------------
The segmentation fault in container-executor reported in -YARN-7796- appears
to be due to a binary compatibility issue with the -fstack-check flag that was
added in this patch.
Based on my testing, a container-executor (without the patch from this Jira)
compiled on RHEL 6 with the -fstack-check flag always hits this segmentation
fault when run on RHEL 7. But if you compile without this flag, the
container-executor runs on RHEL 7 with no problems. I also verified this with
a simple program that just does the copy_file.
This redhat link suggests that there are problems with stack-check:
[|https://access.redhat.com/security/vulnerabilities/stackguard]
[https://access.redhat.com/security/vulnerabilities/stackguard]
{noformat}
To avoid stack guard page jumping, every stack allocation primitive needs to
implement freshly allocated memory probing with the stack guard gap size
granularity. The existing gcc -fstack-check implementation aims to do exactly
that, but currently it is not working correctly. Before the gcc -fstack-check
implementation is fixed and all of the exposed binaries are rebuilt, we have a
combination of kernel and glibc mitigations that addresses all known
reporter-provided exploits available:{noformat}
I've also verified this with a simple test program that just does the file_copy
call.
{noformat}
[jbrennan02@imposeenclose test]$ ./copy_file_test-rhel7 /etc/services /tmp/foo
copy /etc/services to /tmp/foo
[jbrennan02@imposeenclose test]$ ./copy_file_test-rhel7-stack-check
/etc/services /tmp/foo
copy /etc/services to /tmp/foo
[jbrennan02@imposeenclose test]$ ./copy_file_test-rhel6 /etc/services /tmp/foo
copy /etc/services to /tmp/foo
[jbrennan02@imposeenclose test]$ ./copy_file_test-rhel6-stack-check
/etc/services /tmp/foo
copy /etc/services to /tmp/foo
Segmentation fault
The RHEL 6 versions were compiled on this system:
[jbrennan02@goalssoles test]$ hostname
goalssoles.corp.ne1.yahoo.com
[jbrennan02@goalssoles test]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 6.8 (Santiago)
[jbrennan02@goalssoles test]$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18)
The RHEL 7 versions were compiled on this system:
[jbrennan02@imposeenclose test]$ hostname
imposeenclose.corp.ne1.yahoo.com
[jbrennan02@imposeenclose test]$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
[jbrennan02@imposeenclose test]$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-16)
Compiled with: gcc [-fstack-check] -o copy_file_test<suffix>
copy_file_test.c{noformat}
I propose that we remove the -fstack-check flag, and possibly replace it with
-fstack-protector, although that does not provide the same protection.
> container-executor should have stack checking
> ---------------------------------------------
>
> Key: YARN-6721
> URL: https://issues.apache.org/jira/browse/YARN-6721
> Project: Hadoop YARN
> Issue Type: Improvement
> Components: nodemanager, security
> Reporter: Allen Wittenauer
> Assignee: Allen Wittenauer
> Priority: Critical
> Labels: security
> Fix For: 3.0.0-beta1
>
> Attachments: YARN-6721.00.patch, YARN-6721.01.patch,
> YARN-6721.02.patch
>
>
> As per https://www.qualys.com/2017/06/19/stack-clash/stack-clash.txt and
> given that container-executor is setuid, it should be compiled with stack
> checking if the compiler supports such features. (-fstack-check on gcc,
> -fsanitize=safe-stack on clang, -xcheck=stkovf on "Oracle Solaris Studio",
> others as we find them, ...)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
