- 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