Exploitability of Stack-based Buffer Overflows on functions ending with fclose()

Question

I have been discussing the effectiveness of GNU libc's fclose() function to thwart successful exploitation of trivial vulnerabilities due to segmentation fault when called without a valid pointer to a FILE data structure (implementations of libc on other operating systems fail silently). For instance, given a simple vulnerable function using strcpy() such as:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void
foo(const char *str)
{
  char buffer[256];
  int ret = 123456;

  FILE *fp = tmpfile();
  strcpy(buffer, str);
  if (ret != 500)
    fclose(fp);
}

int 
main(int argc, const char **argv)
{
  foo(argv[1]);
  return 0;
}

Even when compiled with most memory-protection mechanisms disabled:

cc -m32 -ggdb -fno-stack-protector -z execstack -z norelro main.c

The function, regardless of being overwritten up to EIP would never return since:

(gdb) r $(python -c "print 'A' * 286")
Program received signal SIGSEGV, Segmentation fault.
0xf7e3e307 in fclose@@GLIBC_2.1 () from /lib/libc.so.6
(gdb) ba
#0  0xf7e3e307 in fclose@@GLIBC_2.1 () from /lib/libc.so.6
#1  0x080484bc in foo (str=0x41414141 <error: Cannot access memory...
#2  0x41414141 in ?? ()
#3  0x41414141 in ?? ()

Could there be a way to achieve code execution for such trivial function?. Since the ret variable can be overwritten, can it be set to 500 so that the if condition which determines if fclose() is called or not could be bypassed?

Answer 1

Since the ret variable can be overwritten, can it be set to 500 so that the if condition which determines if fclose() is called or not could be bypassed?

If the attacker can overwrite the ret variable on the stack with an arbitrary value, then yes.

And even if the attacker can't overwrite ret, they still might be able to overwrite fp with a value that is acceptable to fclose().

Furthermore, your approach relies on several implementation-specific details. For example:

• You assume that fp is between buffer and the return address, but the compiler may not order the variables this way.
• You assume that fclose() will always throw an exception when given a corrupted pointer, however this is not a requirement and may change in future versions of GNU libc.