[1997] in bugtraq
Re: Exploit for Linux wu.ftpd hole
daemon@ATHENA.MIT.EDU (Marc W. Mengel)
Fri Jul 7 20:24:20 1995
Date: Thu, 6 Jul 1995 09:12:33 -0600
Reply-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
From: "Marc W. Mengel" <mengel@dcdmwm.fnal.gov>
X-To: Bugtraq List <BUGTRAQ@CRIMELAB.COM>
To: Multiple recipients of list BUGTRAQ <BUGTRAQ@CRIMELAB.COM>
In-Reply-To: (Your message of Wed, 05 Jul 95 18:06:10 D.)
<Pine.LNX.3.91.950705175939.1572B-100000@phoenix.org>
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.
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?
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
there.
Of course, the paper DecWriter console won't reverse linefeed :-).
Marc
