mailing list archives
Re: Security Problem ftpd (includes wu.ftpd 2.4 and 2.4.2 beta 4)
From: H.Karrenbeld () ct utwente nl (Henri Karrenbeld)
Date: Wed, 12 Jul 1995 22:44:23 +0100
Some time ago James Seng declared:
On Wed, 12 Jul 1995, Henri Karrenbeld wrote:
l-wx------ 1 <yourname> 64 Jul 12 13:07 5 -> :24718
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 -> :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
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
Re: Exploit for Linux wu.ftpd hole Michael Shields (Jul 06)