Re: Exploit for Linux wu.ftpd hole

[medulla () infosoc com (Mike Edulla)]

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
*too* bad.

> 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
> there.

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.