Re: Patchless modification of Lua source code

[Andrew Gierth <andrew@...>]

>>>>> "Sean" == Sean Conner <sean@conman.org> writes:

 Sean>   -spc (So did I use two non-comformant compilers for this
 Sean>   experiment then?)

If you invoke undefined behavior, then the compiler is allowed to do
anything, where "anything" includes things like:

 - the compiler did exactly what you expected
 - the compiler did exactly what you expected, but only because of
   defaults you don't know about, and changing those defaults to make
   something else work will cause this to fail
 - the compiler did something close enough to what you expected to
   fool you into thinking it worked, but in fact it inserted code
   to make it fail on alternate full moons
 - the compiler made the thing you were trying to do work as you
   expected, but subtly broke something somewhere else
 - error messages
 - nasal demons

 Sean> The experiment is a very small program---the function main()
 Sean> calls func1(), which calls func2(). Each function prints it's
 Sean> been called and a sample output would look like:

 Sean> 	Hello from main
 Sean> 	Hello from func1
 Sean> 	Hello from func2

 [snip various experiments]

 Sean>   Now experiemnt two, the "patchless patching exploit."

 Sean> 	% cc -c -o myfunc2.o myfunc2.c
 Sean> 	% cc -Wl,-R/lusr/home/spc/foo -o smain2 main.o myfunc2.o -L/lusr/home/spc/foo -lfuncall
 Sean> 	% ldd ./smain2
 Sean> 	        libfuncall.so =>         ./libfuncall.so
 Sean> 	        libc.so.1 =>     /usr/lib/libc.so.1
 Sean> 	        libm.so.2 =>     /usr/lib/libm.so.2
 Sean> 	        /platform/SUNW,Sun-Fire-T1000/lib/libc_psr.so.1

 Sean>   It compiled, unlike the second experiment with static
 Sean> libraries. But let's see how it runs:

 Sean> 	% ./smain2
 Sean> 	Hello from main
 Sean> 	Hello from func1
 Sean> 	Hello from myfunc2

 Sean> Wow! It worked! Even with func1() and func2() in the same
 Sean> translation unit, func1() is calling func2() from translation
 Sean> unit myfunc2. And it's not Linux! (for the record, it worked
 Sean> under Linux).

It's worth noting here that linux and Solaris have very similar shared
library implementations, because the Solaris model was the one adopted
by GNU ld. However, other models do exist (for example the Windows
model), and not all of them will behave this way.

Furthermore, the ability to override functions in libraries this way is
often seen as a bug rather than a feature, especially when doing dynamic
loading. Accordingly, there are ways to change it: either by linking the
shared library with -Bsymbolic, or providing a link map, symbol version
file, exported symbol list, or explicit declaration that hides func2()
in the library build.

(now go and look at the definition of LUAI_FUNC in luaconf.h and
consider what that means for your approach)

-- 
Andrew.