GCC MUDFLAP Arbitrary Code Execution

Not so long ago, stealth made a blog post about this extremely entertaining vulnerability. Here is the buggy code from GCC 4.4.2 as seen at libmudflap/mf-runtime.c source code file.

options [] =
  {
      ...
    {"viol-gdb",
     "violations fork a gdb process attached to current program",
     set_option, (unsigned)viol_gdb, (unsigned *)&__mf_opts.violation_mode},
      ...
/* __mf_violation */

void
__mf_violation (void *ptr, size_t sz, uintptr_t pc,
                const char *location, int type)
{
  char buf [128];
  static unsigned violation_number;
     ...
  /* How to finally handle this violation?  */
  switch (__mf_opts.violation_mode)
    {
     ...
    case viol_gdb:

      snprintf (buf, 128, "gdb --pid=%u", (unsigned) getpid ());
      system (buf);
      /* XXX: should probably fork() && sleep(GDB_WAIT_PARAMETER)
      instead, and let the forked child execlp() gdb.  That way, this
      subject process can be resumed under the supervision of gdb.
      This can't happen now, since system() only returns when gdb
      dies.  In that case, we need to beware of starting a second
      concurrent gdb child upon the next violation.  (But if the first
      gdb dies, then starting a new one is appropriate.)  */
      break;
    }
}

So, in case of ‘viol-gdb’ option, it will simply execute the command stored in ‘buf’ array using system(3) library routine. However, since it doesn’t provide an absolute path to GDB binary the function will attempt to find the first available binary file named ‘gdb’ using PATH environment variable. Also, from its documentation, we can read that this flag enables this pointer debugging that is instrumented on runtime by libmudflap library, controlled through “MUDFLAP_OPTIONS” environment variable.
By now, you should have noticed that you can use this option in the previously mentioned environment variable:

-viol-gdb                violations fork a gdb process attached to current program

Using this, and the all time classic $PATH environment technique you can execute arbitrary files with the privileges of the binary compiled with that option. You should only be able to trigger a violation to execute any binary named ‘gdb’ that will be retrieved through $PATH environment variable.
As stealth said in his original post, since this flag was made for security reasons applications such as daemons or SUID root binaries might be compiled with it.