2

I have an object file — foo.so — provided by a vendor. That object file was statically linked with a publicly available library — bar_1.0.a. There is a new version of the library bar_1.1.a that fixes a critical bug, but the vendor is not supplying a new version of foo.so, so I can't take advantage of the bug fix.

Because I don't have access to the source code to foo.so, I cannot recompile against the new version of bar. I do have access to the source code for bar, so I can build that at will. The symbols in bar have not changed between 1.0 and 1.1, only some of the implementation.

I would like to know if there is a way to replace/override the statically linked bar_1.0.a library in foo.so with bar_1.1.a without having access to the source code of foo.so. Or, if that is not possible, can I somehow force foo.so to dynamically link against bar_1.1.so even though it is statically linked with bar_1.0.a?

I know that there are various LD_* environment variables that affect dynamic linking, but I don't believe that will help in this case.

Sean Bright
  • 118,630
  • 17
  • 138
  • 146
  • I believe you are looking for Interception or Swizzling. You shadow all the exports `foo.so` and you get yourself loaded first. You provide an updated routine for the vulnerability. Otherwise, you pass the call into the original `foo.so`. Tools like Valgrind use a similar technique for some systems calls (calls like malloc and free). I think the static library `bar.a` is going to make things especially painful. – jww Jan 27 '17 at 02:03

0 Answers0