__dso_handle && __cxa_finalize()

So, I'm working on another program, not the one dealing with authentication and such but the one related to email with the buggy signal handler, there have been some complications in getting a reliable exploit for it so I backed up and thought maybe I could find something easier to exploit in the signal handler, I expected to perhaps be able to screw with OpenSSL in cleanup routines but there are none.

However, the code base is quite ugly and shows all the style of a grad student who thinks they know what they're doing and I decided to fix it to improve reliability (FYI spaces = bad, tabs = good, putting as many things as you can on a single line = bad, new lines = good [they come free with the computer]).

In doing so I found another small bug that I am trying to determine if I can leverage, basically there is a static array of signed chars that I have limited control over the index, because its signed I can provide a negative index, but I only have a single char for an index so I am limited to a max of -127 bytes before the array.

In that, I can do nothing if where the index ends up doesn't have the value of 0x20, so I started digging through .data (where the compiler puts the array) and seeing what has or could have a value of 0x20 -127 bytes back and I ran across a symbol named __dso_handle, not sure of what it is I dug into GCC a little bit and here's what I found.

Basically, it's a symbol that deals with C++ destructors for static objects in shared libraries, the relevant code that uses it is in a function called __cxa_finalize() and is something like as follows:

void
__cxa_finalize (void *d)
{
   [...]
 
   if (!d)
     return;
 
   for (funcs = __exit_funcs; funcs; funcs = funcs->next)
     {
          [...]

       if (f->flavor == ef_cxa && d == f->func.cxa.dso_handle)
         {
           (*f->func.cxa.fn) (f->func.cxa.arg);
              [...]
         }
     }
 }

the argument 'd' is the __dso_handle for the shared object, interestingly enough if I could modify that then I would have the possibility of having another objects destructors called, causing any number of circumstances, most likely a double free().

It's not incredibly useful in this instance because I am dealing with a program that won't have any C++ static object destructors, but it's interesting none the less and something I will keep in mind in the future.

That's that, and that was today in my world. Good night.