- 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
                          overflows.
Have not checked to see if this addresses the above problem.
-- Neil Murray Email: neil@aone.com.au Access One Pty. Ltd. http://www.aone.net.au/ 41 Malcolm Rd., Braeside Phone: +61 3 9239 1444 Victoria, Australia 3195 Fax: +61 3 9580 5581Received 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