QA Notice: the following files contain executable stacks Files with executable stacks will not work properly (or at all!) on some architectures/operating systems. A bug should be filed at http://bugs.gentoo.org/ to make sure the file is fixed. --- --- RWX usr/bin/ssh --- --- RWX usr/bin/scp --- --- RWX usr/bin/ssh-add --- --- RWX usr/bin/ssh-agent --- --- RWX usr/bin/ssh-keygen --- --- RWX usr/bin/ssh-keyscan --- --- RWX usr/bin/sftp --- --- RWX usr/sbin/sshd --- --- RWX usr/lib/misc/ssh-keysign --- --- RWX usr/lib/misc/sftp-server
How did you get these markings? it almost looks as if it was built with a non gentoo toolchain. It should look something like this. (what arch?) # qlist -e openssh | scanelf -F%e\ %F -Be -f - RW- R-- RW- /usr/bin/scp RW- R-- RW- /usr/bin/ssh RW- R-- RW- /usr/bin/sftp RW- R-- RW- /usr/bin/ssh-agent RW- R-- RW- /usr/bin/ssh-add RW- R-- RW- /usr/bin/slogin RW- R-- RW- /usr/bin/ssh-keyscan RW- R-- RW- /usr/bin/ssh-keygen RW- R-- RW- /usr/lib/misc/sftp-server RW- R-- RW- /usr/sbin/sshd
yeah, we need more info ... you cant just post output and have us read your mind :P ive never seen openssh with exec stacks
Ahh hardware = sparc here. Yeah sparc has some headers which mark some sections of the ELF incorrectly. I think to address this the headers need to be fixed.
not an openssh-specific issue, all of sparc is full of this stuff not a pressing issue since i dont think sparc has hardware support for this ?
Any one known what headers are specifically affected?
my guess is gcc or glibc (prob gcc) since every glibc/gcc library has exec stacks
Kumba I think it's the linux-headers problem with elf.h, but I'm going to have to ask the PaX author to try to explain it a bit more and he has poked at the problem a tad more than any of us and may be able to suggest future development paths for us/sparc.
1. sparc has non-exec page (and hence, stack) support, sparc64 support has been in mainline linux for over a year now, sparc32 support is only in PaX. 2. GNU_STACK markings come from the linker, and ultimately, non-marked .o files or .o files that explicitly specify an executable GNU-stack section (so it's not a header problem most likely). i don't know which is the case here, but since so many apps are affected, i'd agree with spanky that it's either gcc or glibc, in particular, the .o files that are implicitly linked into every ELF executable and library. you can check them out by grepping for the GNU-stack header in the readelf -e output. 3. as for fixing this, i guess the problem will turn out to be .o files that are assembled from .S files that don't carry any GNU-stack marking, so the fix will be simple (and upstream should do it eventually). 4. in the meantime, you can just run execstack -c on the executables, that will clear the executable stack marking.
> 1. sparc has non-exec page (and hence, stack) support ok, i'll update severity as such > you can check them out by grepping for the GNU-stack > header in the readelf -e output. latest version of scanelf supports scanning of .o files for missing .note.GNU-stack sections :)
*** Bug 120160 has been marked as a duplicate of this bug. ***
*** Bug 120161 has been marked as a duplicate of this bug. ***
*** Bug 119964 has been marked as a duplicate of this bug. ***
*** Bug 120170 has been marked as a duplicate of this bug. ***
Is this bug still vaild?
seems to be fixed now. ive updated the documentation as such. GNU ld (GNU Binutils) 2.20.1.20100303 GNU C Library stable release version 2.11.2, by Roland McGrath et al. gcc (Gentoo 4.3.4 p1.1, pie-10.1.5) 4.3.4 linux 2.6.34-gentoo-r1 TYPE PAX PERM ENDIAN STK/REL/PTL TEXTREL RPATH BIND FILE ET_EXEC ---xe- 0755 BE RW- R-X RWX - - LAZY /bin/bash
