Re: "Interesting" log-file names

From: Neil Murray <>
Date: Wed, 17 Jul 1996 15:40:57 +1000

- I'm running squid 1.0.0 under Solaris 2.4 and noticed the following
- interesting effect. My primary cache-directory has the following
- contents:
- root@sun579 www/log-files # ls -lrtd ~/harvest-cache/[^0-9]*
- drwx------ 2 www www 512 May 6 09:59 /net/sun579/disc1/home/www/harvest-cache/dns/
- - -rw-rw-rw- 1 www www 8747713 Jul 10 15:58 /net/sun579/disc1/home/www/harvest-cache/submission%25253Dsequence%2526submi
- - -rw-rw-rw- 1 www www 16284425 Jul 11 23:05 /net/sun579/disc1/home/www/harvest-cache/log
- - -rw-r--r-- 1 www www 0 Jul 14 23:06 /net/sun579/disc1/home/www/harvest-cache/log-last-clean
- - -rw-rw-rw- 1 www www 18009604 Jul 15 16:55 /net/sun579/disc1/home/www/harvest-cache/%0A+FB%3A+Fahrradmitnahm
- ro
- (I filtered out the subdirectories 00-99, of course.)
- It seems squid is writing it's logfile to the file called
- %0A+FB%3A+Fahrradmitnahm
- which looks like some properly escaped bit of memory rubbish.
- My question is now: Where should I start to look in my configuration.
- Very probably I have something atypical, someone else would have run int this.
- The first things I think of are:
- 2 cache-directories.
- 20 dns resolver processes.
- very long acl lists.

        Funnily enough I ran into this as well. But the log file ended up in a
totally different area since I had added 'cd /usr/local/squid' into the
RunCache script (so core files wouldn't end up in '/'). I had a log file with
the name "8just+you+me%27" growing in /usr/local/squid. Fairly obviously a
buffer was being overwritten. Examining the code for the swaplog file in
store.c I found

        static char key_temp_buffer[MAX_URL];
        static char swaplog_file[MAX_FILE_NAME_LEN];
        static char tmp_filename[MAX_FILE_NAME_LEN];
        static char logmsg[MAX_URL << 1];

        The most likely candidate to cause an overwrite is key_temp_buffer[] looking
to see where it is used shows that it appears in only two routines;
storeGeneratePrivateKey() and storeGeneratePublicKey() it is used as the
target for sprintf(). In all cases '%s' strings are fed into the sprintf()
with no checks on the ultimate length for both routines.

        Checking my access.log file I found a URL that was 4293 bytes longs (a chat
site web thing) The end of that URL had the "8just+you+me%27" on it.

        For a temmporary workaround (this is NOT! a fix) I did the following.

        static char swaplog_file[MAX_FILE_NAME_LEN];
        static char key_temp_buffer[MAX_URL<<1];
        static char logmsg[MAX_URL << 2];
        static char tmp_filename[MAX_FILE_NAME_LEN];

        I'm still checking to see if other collateral changes are required.

        I would include the URL that caused the problem but reading the scribblings
of a lovesick swain to his object of desire may cause a mass unsubscription
from this list. :-) (If anyone really wants it, send me email)

PS: I just noticed that squid-1.0.2 has the following in the change notes.

            Changes to squid-1.0.2 (July 16, 1996):
                - Increased some MAX_URL sized character buffers to prevent

Have not checked to see if this addresses the above problem.

Neil Murray                              Email:
Access One Pty. Ltd.           
41 Malcolm Rd., Braeside                 Phone:  +61 3 9239 1444
Victoria, Australia  3195                Fax:    +61 3 9580 5581
Received on Tue Jul 16 1996 - 22:42:21 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:32:36 MST