Re: [Clamav-users] clamd cannot allocate memory
Thanks for the tips all. I've implemented a max attachment size on qmail to try and block some of this ridiculous stuff. I always went through the entire config file and updated it with new options available in 0.88.2. That config file was probably the same one I was using when I started using clamav around 0.71 or so. :-o I've put a softlimit of 128Mb on clamd, which I'm hoping should be sufficient given everything else that has been implemented here. I'll post back if I have any more issues. Thanks again for the help! ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamd cannot allocate memory
At any rate, I'm running without a softlimit right now so we will see what happens. Other avenues to persue would be helpful. Well, I've been running clamd for the last few days without softlimits and have had no problems with it choking. I've reviewed the logs and see several messages where the max file size was hit, but it didn't die so that's a good sign. So now I have a few more questions: 1) For those of you who are using softlimits or ulimits, what are you're limits set to? It still makes me nervous, so I'd like to add the limits back at some point. 2) I've been monitoring the clamd process with top and it never seems to take more than about 30Mb of total memory (physical + virtual), so I'm curious why it would be choking with a softlimit of 50Mb. Thoughts? 3) Are other mail admins out there seeing these huge file attachments coming in? Most of them seem to be spam, so I'm guessing a few folks are. I'm sure I could find this in the docs, but being a little lazy right now, what does clamd do when it reaches the max file size? What do other clamd users have your max file size set to? Thanks. ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] clamd cannot allocate memory
I'm running ClamAV 0.88.2 via daemontools and qscanq for use with qmail. I've been having an issue with clamd not being unable to allocate memory. From the logs (as an example): 2006-06-27 08:36:36.985532500 LibClamAV Error: cli_malloc(): Can't allocate memory (123 bytes). 2006-06-27 08:36:36.985554500 malloc_problem: Cannot allocate memory 2006-06-27 08:36:36.985584500 LibClamAV Error: cli_malloc(): Can't allocate memory (123 bytes). 2006-06-27 08:36:36.985606500 malloc_problem: Cannot allocate memory 2006-06-27 08:36:36.985635500 LibClamAV Error: cli_malloc(): Can't allocate memory (95 bytes). 2006-06-27 08:36:36.985656500 malloc_problem: Cannot allocate memory 2006-06-27 08:36:36.985683500 LibClamAV Error: cli_malloc(): Can't allocate memory (123 bytes). 2006-06-27 08:36:36.985704500 malloc_problem: Cannot allocate memory 2006-06-27 08:36:36.985730500 LibClamAV Error: cli_malloc(): Can't allocate memory (8 bytes). 2006-06-27 08:36:36.985752500 malloc_problem: Cannot allocate memory The problem is that this causes clamd to crater (CPU usage for the clamd process goes to 100%) and makes the mail server unavailable (sending mail returns an SMTP 4.3.0 temporarily not available). This will usually eventually resolve itself, but it could take hours for mail service to be restored. I've upped the softlimit on clamd from 10Mb to 30Mb to 50Mb but that didn't solve the problem. I researched this problem in the list archives and found the ExitOnOOM directive, however incorporating that doesn't solve the problem either: clamd does not die when it cannot allocate memory. I cannot seem to find any other solutions, so I would appreciate some insight. For reference: # cat /service/clamd/run #!/bin/sh exec 21 CLAMD_FILE=./root/clamd SCAN_FILE=$0 # Check for a leftover socket. if [ -e $CLAMD_FILE ] then echo run: WARNING: file $CLAMD_FILE exists if clamdscan $SCAN_FILE then echo run: FATAL: Clamd is already running. Trying to start anyway... else echo run: INFO: Clamd is not running. Deleting $CLAMD_FILE rm -f $CLAMD_FILE fi fi # Run the scanner daemon. # NOTE: ClamAV v.80 will not run with this setuidgid line. Removing seems to fix the issue per Clamav-users list #exec setuidgid gqscanq /usr/local/sbin/clamd exec /usr/local/bin/softlimit -a 5000 /usr/local/sbin/clamd -c /etc/clamav/clamd.conf exec /usr/local/sbin/freshclam --daemon --checks 2 # cat /etc/clamav/clamd.conf ## ## Example config file for the Clam AV daemon ## Please read the clamav.conf(5) manual before editing this file. ## # Comment or remove the line below. #Example # Uncomment this option to enable logging. # LogFile must be writable for the user running the daemon. # Full path is required. LogFile /dev/stderr # By default the log file is locked for writing - the lock protects against # running clamd multiple times (if want to run another clamd, please # copy the configuration file, change the LogFile variable, and run # the daemon with --config-file option). That's why you shouldn't uncomment # this option. #LogFileUnlock # Maximal size of the log file. Default is 1 Mb. # Value of 0 disables the limit. # You may use 'M' or 'm' for megabytes (1M = 1m = 1048576 bytes) # and 'K' or 'k' for kilobytes (1K = 1k = 1024 bytes). To specify the size # in bytes just don't use modifiers. #LogFileMaxSize 2M # Log time with an each message. LogTime # Log also clean files. May be useful in debugging but will drastically # increase the log size. #LogClean # Use system logger (can work together with LogFile). #LogSyslog # Specify the type of syslog messages - please refer to 'man syslog' # for facility names. Default is LOG_LOCAL6. LogFacility LOG_MAIL # Enable verbose logging. #LogVerbose # This option allows you to save the process identifier of the listening # daemon (main thread). #PidFile /var/run/clamd.pid # Optional path to the global temporary directory. # Default is system specific - usually /var/tmp or /tmp. #TemporaryDirectory /var/tmp # Path to the database directory. # Default is the hardcoded directory (mostly /usr/local/share/clamav, # but it depends on installation options). #DatabaseDirectory /var/lib/clamav # The daemon works in local or network mode. Currently the local mode is # recommended for security reasons. # Path to the local socket. The daemon doesn't change the mode of the # created file (portability reasons). You may want to create it in a directory # which is only accessible for a user running daemon. LocalSocket /tmp/clamd # Remove stale socket after unclean shutdown. FixStaleSocket # TCP port address. #TCPSocket 3310 # TCP address. # By default we bind to INADDR_ANY, probably not wise. # Enable the following to provide some degree of protection # from the outside world. TCPAddr 127.0.0.1 # Maximum length the queue of pending connections may grow to. # Default is 15. #MaxConnectionQueueLength 30 # When activated, input stream (see STREAM command) will be saved to disk before #
Re: [Clamav-users] clamd cannot allocate memory
Have you tried running clamav without softlimit? No, but that doesn't seem like a long-term solution. I'll give it a whirl just to see what happens, but I don't want to leave a deamon running without limits forver. ___ http://lurker.clamav.net/list/clamav-users.html
Re: [Clamav-users] clamd cannot allocate memory
Can you tie your problems up with particular mails from your logs ? I've found Clam is very greedy on big MIME mails, as it stores the entire mail in RAM whilst extracting the attachments. The last few that have triggered this condition seem to be caused by large files. I will get a log like: WARNING: ScanStream: Size limit reached ( max: 10485760) Why doesn't clamav skip the file if it is larger than its max file size? After this, it throws a few hundred like the following within 1 second: LibClamAV Error: cli_malloc(): Can't allocate memory (8 bytes). malloc_problem: Cannot allocate memory Why does libclamav throw several hundred of these before actually dieing? Seems to me that ExitOnOOM should make it die immediately when one of these is thrown. Of course, I'm also not a devel. :P At any rate, those messasges are often followed by: ERROR: ScanStream: Can't create temporary file. That seems to be where clamd is choking. At any rate, I'm running without a softlimit right now so we will see what happens. Other avenues to persue would be helpful. Steve ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Secunia 18379
Hi guys, Can somebody confirm that the upx.c buffer overflow vulnerability referred to at http://secunia.com/advisories/18379 (2006-01-10) is the one that was fixed in CVS on Sept 16. Steve ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Secunia 18379
Tomasz Kojm wrote: Can somebody confirm that the upx.c buffer overflow vulnerability referred to at http://secunia.com/advisories/18379 (2006-01-10) is the one that was fixed in CVS on Sept 16. No, that's not that one. Ok, thanks for the prompt answer. Can you tell me if the Secunia vulnerability mentioned above has been attended to (hopefully to remove the vulnerability), and approximately when, and whether it's now fixed in CVS and/or 0.88? Thanks for your time. Steve ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Secunia 18379
Stephen Gran wrote: No, sorry, it should be the CVS commit on Tue Jan 10 00:46:40 2006 - I had Sept 16 selected for diffs and got stupid about which was which. Aha, got it! Thanks very much for your help. -S ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Virus not detected by -devel version; 0.86-1 ok
I've noticed that today's (maybe also recent versions) development version of clam no longer detects W32/Mytob-BP (Sophos). I have several samples which are declared fine by ClamAV (devel-20050721/985/Thu Jul 21 13:14:39 2005), but correctly flagged as infected by both another server not quite as current (ClamAV devel-20050627/985/Thu Jul 21 13:14:39 2005; Worm.Mytob.FJ FOUND) and also by the online scanner: Result: This virus is already recognized by ClamAV 0.86.1/984/Tue Jul 19 11:16:09 2005 (timezone: +0200 ) as Worm.Mytob.FJ . Is this a known issue with the CVS version? Yes, I am aware it's 'my risk' using CVS ;-) Steve PS I originally sent this to the -devel list, but my subscription request from a coupld of months ago still hasn't been approved so my post was rejected. * confirm 292432 Your request has been forwarded to the list administrator for approval ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Virus Name Sophos-Clam
Guys, Can anyone offer a Clam virus name for the following Sophos names? Troj/Agent-BX Troj/Agent-T Troj/DDrop-A Troj/Dloader-KF Troj/Dloader-KZ Troj/Lecna-C Troj/Nethief-M Troj/Nethief-N Troj/Nethief-O Troj/Netter-A Troj/Riler-E Troj/Riler-F Troj/Riler-J Troj/RPE-A Troj/Sharp-A Troj/VBDrop-A WM97/Loof-D I've tried cross-referencing the names at viruspool.vanderkooij.org and www.rainingfrogs.co.uk but without to much luck. It's not _too_ bad matching the generic names, but the varients are a tad difficult. So, if anyone *knows* a Clam name for any of the above, I'd be pretty happy. Steve ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: Recent CVS - broken logging to /dev/stderr ?
I said: with perms = rw--- root.root. It was fine (and still is) on cvs from Stephen Gran wrote: Yes, that is the problem. This does however fix the problem of clamav opening all it's descriptors (including the logfile) as root, breaking permissions for anything else that needs to write to the logfile. At least I got that bit right ;-) Try starting it as the user it runs as, e.g., I tried that, although it's a little trickier since I run clamd supervised with daemontools. Anyhow, using the run script: su -c '/usr/sbin/clamd -c /etc/clamav/clamd.conf 21' - qscand *And* turning off 'LogFile /dev/stderr' fixed it for now, _and_ it's still logging correctly. Go figure :-) Er, Matt Fretwell said: Unless I am very much mistaken, the perms on stderr should be 666. Stephen Gran then said: I doubt that - 0600 is much more reasonable. Why would you want your Exactly, and certainly on Debian it defaults to 600, which is sensible really. -S ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Recent CVS - broken logging to /dev/stderr ?
Hi list, Is it just me, or has the recent CVS changes around the logg() function broken logging to /dev/stderr? It would appear that maybe privileges are being dropped too quickly because with today's cvs I'm getting permission denied on /dev/stderr with perms = rw--- root.root. It was fine (and still is) on cvs from a few days ago. Steve ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: problems with ScanMail and digests
Sorry to hijack Steve Platt's thread :-/ Nigel Horne wrote: Looks OK to me: [EMAIL PROTECTED] tmp]$ clamscan 23893.0.dodgy.eml 23893.0.dodgy.eml: OK I have to jump in here and concur that it's also broken on 2 of my systems, and they're both running the current CVS version: ClamAV devel-20050301/738/Tue Mar 1 12:08:00 2005 I've been hunting around trying to discover what's up with the two machines after noticing qmaiil-scanner aborting on a few incoming mails. Steve's thread was the clue I needed and I have the same issue. I can see that clamscan clamdscan seem to scan in an infinite loop, certainly it's still scanning dodgy.eml after 40 minutes... -S -- Steve Brown Unix Systems Manager ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: RAR module failure
Tomasz Kojm wrote: Yes, the internal unpacker for rar archives doesn't handle v3 rar archives. Try clamscan --unrar /path/to/unrar for this. Funnily enough I was just about to compose a message about this on the devel list but thought I'd better check here first. I'm getting probably the same virus through and according to RAR it's (I think) a version 2.9 file, not 3.x. Maybe a cleverly crafted archive because Debians package unrar - Unarchiver for .rar files v0.0.1 cannot open it, but unrar-nonfree 3.3.6-2 (which provides UNRAR 3.30 freeware Copyright (c) 1993-2004 Eugene Roshal) can. Anyway, the built in rar module in Clam fails with: LibClamAV debug: unknown compression method: 29 (min=13 max=20) or likely I misunderstand and it is a V3 archive with a compression method of 29? Steve ___ http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users
[Clamav-users] 0.80rc bad format or broken data error - POSIX tar files
Hi, I see that a similar reported problem was fixed (RFC2298 fixes) but I have a slightly different problem. After some debugging, I can see that clamav doesn't seem to be able to scan POSIX tar archives (returns Bad format or broken data ERROR) while GNU tar archives are fine. I used 'file' on the archive to determine what was what. Is this a ClamAV issue, or an OS issue - Redhat ES 3.0? If it's been fixed in RC3, then sorry - I cannot compile on this platform so am dependant on binary ports and there kind maintainers. -S --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
Re: [Clamav-users] 0.80rc bad format or broken data error - POSIX tar files
Nigel Horne wrote: Send me an example, please, and I'll have a look into it. Sure, I already asked the user to create an example suitable for the public domain in advance of my query ;-) Naturally he's on holiday today, and I'm away from tomorrow for a week... When I get back I'll forward it. Thanks very much for the interest. -S -- Steve Brown Unix Systems Manager Accenture Data Centre, QinetiQ Farnborough FRN (802) 4416 +44 1252 394416 --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl ___ Clamav-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/clamav-users
