http://www.anticode.com  for the latest exploits, tools and documents!



Date:         Thu, 7 Jan 1999 12:28:59 -0500

From:         John McDonald <jmcdonal@UNF.EDU>

Subject:      really silly ff.core exploit for Solaris



Hi,



At the bottom of this email is an exploit I wrote a little bit ago for

/usr/openwin/bin/ff.core on Solaris 2.5.1, and 2.6. I have tested it on a

few machines, with decent success. There is a security patch for ff.core,

labeled 106222-01. I installed it on my 2.6 box, and it does *not* appear

to fix the problem.



The success of this exploit depends heavily on certain default

characteristics of the OS.. There is a pretty good chance it won't

work on your machine if you have changed much of the configuration and

layout. Obviously, openwindows has to be installed. It's a really noisy

exploit, and if someone uses it on your machine, there is a good chance

you might notice.. Let me explain...



We can use ff.core to do a rename() as root. However, there are a lot of

restrictions on what we can get away with. Taking those into account, here

is what I came up with:



ln -fs $A /vol/rmt/diskette0

/usr/openwin/bin/ff.core -r /vol/rmt/diskette0/$B $C /floppy/



$A is the directory that contains the file we want to rename.



$B is the file that we want to rename relative to $A. This can be in any

directory under $A (it can't contain '..').



$C is what we want to rename the file too. $C cannot contain '/', so it

has to be in the $A directory.



If you are interested, you can see why we have these restrictions by

gdb'ing a copy of ffcore and disass'ing ff_rename. The 2.5.1

binary is real straightforward.. our 3 arguments make it to ff_rename as

%i0, %i1, and %i2. Then there is a series of sanity checks on the input, a

call to get_vol, a call to get_newpath, and then our call to rename(). The

2.6 binary is a bit more complex, and I haven't tried to follow that one,

but the exploit still works fine. Anyway, it's easy to figure out the

rules that govern our input from the 2.5.1 binary. However, this

invalidates your license, and is an atrocious intellectual property crime,

so don't even consider it.



Ok, so following our rules from above, we can rename any file on the

system to anything we want within the same directory. Also, we can move a

file from any directory to a directory that is above that file in the

tree, as long as they are on the same filesystem. ie- we can move

something from /usr/bin to /usr, as long as /usr/bin and /usr are the same

filesystem.



So, how do we exploit this? On Solaris 2.5, it was pretty easy. I moved

/etc/group on top of /etc/shadow, and su'ed to root. (You can back up

/etc/shadow by moving it to /etc/shadow.bak). However, this doesn't work

on machines running a later version of Solaris. (and some patch probably

makes the passwd system a bit smarter). So, I struggled with it for a

while and came up with a solution. There is easily something I missed or

didn't think of, so this might not be the most effective way.



Anyway, this exploit will attempt to move /bin/sh over in.rlogind. It does

this by utilizing some files sitting around by default in various

directories.



This is basically what it does:



rename /usr/bin/sh /usr/bin/admintool

rename /usr/sbin/swmtool /usr/sbin/in.rlogind

telnet localhost login and clean up



This works because /usr/sbin/swmtool is a symlink to /usr/bin/admintool.

When we rename swmtool to in.rlogind, and telnet in, inetd is going to

exec in.rlogind, and the symlink will be resolved such that

/usr/bin/admintool will be execed. So, if we move /usr/bin/sh to

/usr/bin/admintool, then it will be execed by inetd, and we will have a

root prompt waiting for us.



Obviously, this is going to make tripwire or any other binary modification

detector go nuts. Also, rlogind, sh, and admintool will be temporarily

hosed during the exploit. It attempts to clean up everything it can, but

if everything isn't quite right, and it renames files, but doesn't get the

root shell, then it can't clean up. Run