mailing list archives
Re: Exploit for Linux wu.ftpd hole
From: medulla () infosoc com (Mike Edulla)
Date: Sat, 8 Jul 1995 14:13:35 -0400
On Thu, 6 Jul 1995, Marc W. Mengel wrote:
Date: Thu, 6 Jul 1995 09:12:33 -0600
From: Marc W. Mengel <mengel () dcdmwm fnal gov>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ () CRIMELAB COM>
Subject: Re: Exploit for Linux wu.ftpd hole
In <Pine.LNX.3.91.950705175939.1572B-100000 () phoenix org> you write:
There also apepars to be a bug in syslog. If you do something like:
grep -v "ROOT" messages > mmm; mv mmm messages
Logging is disabled, I suspect this problem is that the file pointer
maintained by syslog is getting ahead of the physical EOF, and thus
writes will fail, but this is just a guess, and I havent looked at the
source to linux's syslog.
Actually, that sounds like Broken As Designed -- syslogd continues
writing on the (unlinked) old messages file until someone sends
him a SIGHUP and he rereads the config file and reopens the output
files. This is really a filesystem issue and not a syslogd issue,
you can remove the last directory link to any open file, and the
program(s) that have it open don't notice, and the file doesn't
go away 'till it's closed.
Yes, i've since discovered this. And the writes dont return a error. Hmm,
how slow would fstat()ing the log file before writing be, it shouldnt be
Of course, the fun thing is that output file continues to fill up
the filesystem with syslog messages that no-one can see...
Perhaps syslogd should fstat() the file descriptor , and stat() the
file name, and make sure they're the same inode, etc. periodically?
I *thought* the write's would return a error, but they dont. A stat
before writes (maybe a function that tries statting for link 30 seconds
until it succeeds, and if it doesnt succeed after 30 seconds, try to
close and reopen the syslog files, if that fails, kill -HUP syslog).
Nah, even if you did make it that smart, you could still just
overwrite the logfile, replacing the su/ROOT/login/ftp/whatever
messages with something innocuous of the same length, and let it
keep on logging...
Once someone gets in there's really nothing to prevent the person
from "fixing" all the logfiles to make it look like they weren't
Indeed. Not enough people write to either a seperate non-accessable
machine, or a printer. A printer is prob the best way, but alas - most
people dont even bother to *read* logs, let alone logging to a printer.