Hi Guys, the /usr/libexec/gnome-pty-helper binary is setuid and compiled/linked with lazy bindings. I've attached here a patch to the ebuild and a patch to the sources to fix this issue (adding -Wl,-z,now to the ldflags for gnome-pty-helper). It's not the best source patch, but eh.
Created attachment 58157 [details] Patch to the vte source Patch to the vte source
Created attachment 58158 [details] Patch to vte-0.11.12.ebuild Patch to vte-0.11.12.ebuild
*** Bug 70956 has been marked as a duplicate of this bug. ***
I don't see anything wrong with this, but then again, I don't really understand what's going on. Could you briefly explain what is the problem and how do those LDFLAGS resolve it, please? Thanks.. :)
From man ld(1): now When generating an executable or shared library, mark it to tell the dynamic linker to resolve all symbols when the program is started, or when the shared library is linked to using dlopen, instead of deferring function call resolu- tion to the point when the function is first called. I'm not sure how this makes the program more secure. Afterall, if someone can slip in a different library, they can do it at invocation time as well as later on in the running of the program. gnome-pty-helper doesn't seem to be a particularly long lived process. I guess the poster should explain in more detail.
hang on, let me ask solar or vapier to explain this issue more clearly so I don't screw up the explanation.
Yes guys please do, my report of the QA notice (bug #70956) got ignored with a "well portage shouldn't complain" response. I suspect it's because a running binary could become compromised while running (in a way it couldn't be before running, e.g. by a buffer overrun) and therefore alternate libraries might be made to be used before linking is completed, but that would directly contradict what Daniel Gryniewicz said, so I don't really know :-)
Fixed in vte-0.11.13-r2. Thanks for the help :).
