Re: Security Problem ftpd (includes wu.ftpd 2.4 and 2.4.2 beta 4)

[H.Karrenbeld () ct utwente nl (Henri Karrenbeld)]

Some time ago James Seng declared:
> On Wed, 12 Jul 1995, Henri Karrenbeld wrote:
> > l-wx------   1 <yourname>     64 Jul 12 13:07 5 -> [0301]:24718
> [snip]
> > So normal access for wtmp is 644, however this 'hard link' into the filesystem
> > points directly to the inode (24718) and gives you write access to this file
> > by writing to /proc/2728/fd/5 instead of to /var/adm/wtmp.
>
> Just like to ask a stupid question. Is "5 -> [0301]:24718" a hard link or
> is it a soft link? (sorry..i dont have the spec for /proc filesystem..)

I have to admit I don't know how the /proc filesystem works exactly,
but it is not a normal link, I can tell you that! I did call it a
'hard link' and not a hard-link though, because I was not sure about the
jargon here.

> If it is a soft link, then it is no bug. The soft link maybe own you you
> but this doesnt means that inode 24718 is own by you. The ftp daemon may
> continue to access /var/adm/utmp even though it has euid itself to
> <yourname> since it has open() the file while it is still root.

That is true,...however I've also tried to:

1) access a 'link' to /etc/shadow this way, and I could read the file.
2) overwrite /var/adm/xferlog this way ( echo "This file is hacked" > )
   (with a '>' not '>>') and what it did, it appended to the file,
   which looks weird because I specified that I wanted to overwrite;
   maybe, if someone explains to us how this actually works in the /proc
   filesystem, this isn't so strange?

> If it is a hard link, then we are in deep trouble. If i am not wrong,
> /proc/<processid>/exe is also a link which actually points to the inode
> of the program of the process. This means that anyone can overwrite or
> modify any program they run by 1. run the program and then suspend it
> 2. ps and look for process id 3. Overwrite /proc/<processid>/exe with
> their trojan version.

Of course, we've also tried this. However, we were not able to overwrite
the file with our own program, but we assumed this was because the binary
was 'busy', being executed (have you ever tried stripping an executable
that was running, for example?)

> I maybe wrong about the whole thing however...feel free to correct me.

Well, _I_ might be wrong about the whole thing too, however the things
mentioned at (1) and (2) _did_ work on 5 systems that we tried it on
(1 system with /etc/shadow (wu.ftpd 2.4), 3 systems with /usr/adm/xferlog
(wu.ftpd 2.4) and 1 system with /var/adm/wtmp (wu.ftpd 2.4.2 beta4))
so there is definately _some_ security problem on _our_ machines.

$) Henri Karrenbeld