xorl %eax, %eax

GCC MUDFLAP Arbitrary Code Execution

leave a comment »

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 [] =
     "violations fork a gdb process attached to current program",
     set_option, (unsigned)viol_gdb, (unsigned *)&__mf_opts.violation_mode},
/* __mf_violation */

__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.)  */

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.

Written by xorl

November 1, 2009 at 23:07

Posted in vulnerabilities

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s