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

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



http://dividead.wordpress.com/tag/heap-overflow/


oh wow, amazing, someone has already posted but, anyhow, the things
explained, here...and yes, if it overflows then ofc it can lead to
possible root....

fucuall fd
/XD


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/