Running old binaries that abuses setjmp/longjmp with recent glibc

[Florian Weimer]

* Viktor Ostashevskyi:

> First problem was ABI breakage introduced by GCC somewhere near
> version 4.4 regarding stack alignment
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838).
> Fortunately, this can be workarounded by rebuilding 32-bit user-space
> with '-mstackrealign'.

The actual breakage was much earlier, but if you build glibc with recent
glibcs with SSE2 enabled, there is much more SSE2 usage, so this is more
noticeable.  -mstackrealign should fix this.

> Second problem I encountered was more harder to solve and related to
> glibc itself.
> It turned out that Netscape 4.8 uses sigsetjmp/siglongjmp and alters
> contents of jmp_buf, probably in order to implement some kind of
> process-level multithreading.
> Remnants of that are still visible in Mozillas NSPR library
> (https://hg.mozilla.org/projects/nspr/file/tip/pr/include/md/_linux.h#l438)
>
> This can't work since long ago as glibc mangles stack pointer and
> program counter in jmp_buf (first mangling was added by Ulrich Drepper
> in the end of 2005).

Interesting problem.  This kind of hardening is rather desirable, though.

> As search in the web didn't help with finding any workarounds, I tried
> to create my own one: LD_PRELOAD with tiny library overriding
> *setjmp/*longjmp. Overrides actually call glibc implementations but
> demangle pointers after *setjmp and mangle them back before *longjmp.
> (see attached code).
>
> To my surprise this worked like charm and Netscape successfully started :)
>
> Now I'm wonder whether glibc can't provide such library? It has
> libBrokenLocale.so since at least 1996 (do we have ELF at 1996 at
> all?), for fixing programs that could have used locales incorrectly in
> some prehistoric time, but doesn't have anything for much newer
> applications built against glibc 2.1 in much modern times.
>
> Any ideas how this can be done in glibc?

We could perhaps add a tunable that allows the user to disable the
hardening at process startup, e.g., instead of XORing with a random
value, always XOR with zero.  The cost for that would be quite small.

Thanks,
Florian