This is an auto-filled bug because this package does not respect user's CFLAGS. While SSP is really good for security purpose, I'd expect that with CFLAGS="-fno-stack-protector" the package should not have stack protection. In this case the file /usr/bin/man (and maybe some other file from this package) has stack protection. To check the SSP status you can use: checksec --file /usr/bin/man (from app-admin/checksec) hardening-check /usr/bin/man (from app-admin/hardening-check) readelf -sW /usr/bin/man | grep "__stack_chk_fail"
(In reply to Agostino Sarubbo from comment #0) > This is an auto-filled bug because this package does not respect user's > CFLAGS. > > While SSP is really good for security purpose, I'd expect that with > CFLAGS="-fno-stack-protector" the package should not have stack protection. This might not be good enough a check if your glibc is built with stack protection. For example: $ LANG=C readelf -a /usr/lib/libc_nonshared.a | fgrep stack_chk_fail has a few stack protection bits. You'll need to make sure you rebuild glibc with This means you will get at least parts of libc stack-protected. Gentoo unconditionally enables it with --enable-stack-protector=all in ebuild. You might want to use EXTRA_ECONF=--enable-stack-protector=no to get cleaner libc. > In this case the file /usr/bin/man (and maybe some other file from this > package) has stack protection. > To check the SSP status you can use: > checksec --file /usr/bin/man (from app-admin/checksec) > hardening-check /usr/bin/man (from app-admin/hardening-check) > readelf -sW /usr/bin/man | grep "__stack_chk_fail" Due to the above you will get false positive here. You can check with 'objdump -d -R /usr/bin/man' where those calls come from. Perhaps better way to make sure is to add CFLAGS=-frecord-gcc-switches and inspect intermetiate objects for passed flags.
I talked with slyfox on IRC. He helped me to understand what's wrong here because there was a chance of false-positive. I thought that use gcc[-ssp] and -fno-stack-protector in make.conf was enough (apart for ebuild that overwrite stack-protector) and I discovered that glibc handles stack-protection in a different way, with --enable-stack-protector=no, so I had to compile glibc with: EXTRA_ECONF="--enable-stack-protector=no" emerge -1 glibc Would be great to have the stack-protection controlled by a USE, or even check if gcc has ssp enabled by default or not.. TIA
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5aca3ae8606fb422955eedb5e45d50166e91c339 commit 5aca3ae8606fb422955eedb5e45d50166e91c339 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-03-09 10:46:05 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-03-09 10:46:40 +0000 sys-libs/glibc: make stack protection optional, bug #679788 The change adds new USE=ssp to optionally disable protection of glibc's internals. Before the change protection was unconditionally enabled. It's useful to disable ssp to validate if stack protection causes any damage (glibc bugs like https://sourceware.org/PR24202 or gcc bugs like https://gcc.gnu.org/PR81996). And also useful to get more predictable binaries like in https://bugs.gentoo.org/679788. Reported-by: Agostino Sarubbo Bug: https://bugs.gentoo.org/679788 Package-Manager: Portage-2.3.62, Repoman-2.3.12 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-libs/glibc/glibc-2.28-r5.ebuild | 4 ++-- sys-libs/glibc/glibc-2.29.ebuild | 4 ++-- sys-libs/glibc/glibc-9999.ebuild | 9 +++++++-- sys-libs/glibc/metadata.xml | 1 + 4 files changed, 12 insertions(+), 6 deletions(-)
Added optional USE=ssp for glibc-2.28 and above.
