This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 12/06/2017 02:40 PM, Joseph Myers wrote:
On Wed, 6 Dec 2017, Florian Weimer wrote:Based on the ld.so experience, I think it is questionable that existing vulnerable applications can be fixed by increasing the guard size. Our expectation is that we have to recompile with -fstack-clash-protection to get deterministic crashes (which we are doing with glibc), or to patch them to avoid the stack jump (which we did for ld.so because the GCC support wasn't available at the time).I'd say we should continue to fix any cases of unbounded dynamic stack allocations in glibc, as being bugs (whether or not bugs with security impact), *and* expect to need to compile glibc and everything else with -fstack-clash-protection for safety (there are, after all, some quite large but bounded static stack allocations in glibc).
Yes, I was too brief. Any reachable large stack jump still needs to be fixed. But it's very hard to identify those that matter. Aldy and I actually looked at the llp_tmp jump long before the security impact was known, but I dismissed, probably because I wrongly assumed that LD_LIBRARY_PATH is ignored in AT_SECURE=1 binaries.
So -fstack-clash-protection is needed for the deterministic crashes, as a safety net, but it of course doesn't fix any actual bugs.
Thanks, Florian
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |