Re: [clamav-users] PCI DSS - Configuring ClamAv Logs to be Retained for 12 Months
On 2015/04/25 16:58, Dale Carter wrote: In order for ClamAv to be considered PCI Compliant the logs need to be kept for 12 months, preferably on a remote server. How do I configure logs to be kept for this long or is there a way to do it using rsyslog to a remote server for ClamAV LogSyslog yes, then it is just down to standard syslog configuration which presumably you are already doing for other logs in this sort of environment. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Regarding the Clamav 0.98.4 installation
On 2014/11/13 22:32, naresh hcu wrote: Sir, I have successfully installed calmav f rom clamav packags but i want to install it from source code i am getting errors , this is task is a part of my M.Tech project Could you help me Sir, Thanking sir, Naresh There isn't really enough information in your email for anyone to be able to help you. You'll need to be more specific - what exactly did you type, what errors did you see? (copy-and-paste the messages). Recommended reading: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Daily.cvd file
On 2014/09/18 17:24, G.W. Haywood wrote: Hi there, On Thu, 18 Sep 2014, Joel Esler wrote: [something or other, I can't really tell] Joel, PLEASE get a decent mail client, your messages on this list are pretty near indecipherable. One of the lines is this... X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 ...so I think this is HTML mails getting badly auto-converted to non-HTML for the mailing list. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
Re: [clamav-users] Problem with ClamAV 0.98.4 - HAVP won't load CVD files
On 2014/06/26 11:10, Shawn Webb wrote: On Thu, Jun 26, 2014 at 12:37 AM, Paul Kosinski cla...@iment.com wrote: I'm using HAVP (0.92) on Linux (openSuSE 13.1) as a virus scanning filter for HTTP traffic. It worked perfectly with ClamAV 0.98.3 (and many previous versions), but now it won't start at all with 0.98.4. HAVP uses libclamav.so to do the actual scanning (more efficient than even the socket interface), so it starts by loading the various CVD files. With 0.98.4, HAVP fails thus: 25/06/2014 20:30:54 === Starting HAVP Version: 0.92 25/06/2014 20:30:54 Running as user: havp, group: havp 25/06/2014 20:30:54 --- Initializing ClamAV Library Scanner 25/06/2014 20:30:54 ClamAV: Using database directory: /opt/clamav/share/clamav 25/06/2014 20:30:54 ClamAV: Could not load database: Can't allocate memory 25/06/2014 20:30:54 Error initializing ClamAV Library Scanner! While with 0.98.3, HAVP succeeds: 25/06/2014 20:32:48 === Starting HAVP Version: 0.92 25/06/2014 20:32:48 Running as user: havp, group: havp 25/06/2014 20:32:48 --- Initializing ClamAV Library Scanner 25/06/2014 20:32:48 ClamAV: Using database directory: /opt/clamav/share/clamav 25/06/2014 20:32:55 ClamAV: Loaded 3470096 signatures (engine 0.98.3) 25/06/2014 20:32:56 ClamAV Library Scanner passed EICAR virus test (Eicar-Test-Signature) 25/06/2014 20:32:56 --- All scanners initialized A previous posting to this list implied that such (presumably bogus) memory errors might be related to the switch to OpenSSL. In both cases, I'm using OpenSSL 1.0.1h-1.60.1 (openSuSE's latest version), and the clamd.conf file and HAVP binary are the same. Hey Paul, It looks like HAVP is calling into libclamav directly. That means that HAVP will need to either initialize OpenSSL prior to calling the cl_init() function in libclamav, or it will need to call cl_initialize_crypto() prior to calling cl_init(). We have an open bug on our end to track this issue (bugzilla bug 11037). Additionally, a bug report should be opened with HAVP to document the issue on their end. I will be discussing with the team soon potential solutions going forward. One complication with this is that the prototype for cl_initialize_crypto() is only in libclamav/crypto.h which doesn't get installed..(and for HAVP which doesn't normally use openssl, it would need extra build scaffolding there to do this via openssl rather than cl_initialize_crypto). As far as external users go, the approach in Sebastian's diff (calling cl_initialize_crypto from cl_init) seems far simpler. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
Re: [clamav-users] [Clamav-devel] ClamAV(R): ClamAV 0.98.4rc1 is now available!
On 2014/05/20 14:27, Mark Allan wrote: Hi Shawn, By the sample do you mean the 1.15 GB file? If so, that's the user's personal email mailbox so I can't imagine he'd be willing to share it. If you mean a 0.98.4-rc1 crash log, I've just asked him again, so hopefully he'll be able to find it. 1.15GB seems like a lot but it wouldn't take all that many iterations of a binary search to get it to a manageable size, and quite possibly not containing anything particularly personal. Thunderbird mailboxes are plaintext so this could be done by chopping it with head / tail commands .. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml
[clamav-users] 0.98.3, new segfault probably related to email parser
I'm running clamav on OpenBSD/amd64 5.5 (with various sanesecurity hdb's, if that matters). Built from ports (with LLVM 3.3). Config is: LogSyslog true LogFacility LOG_MAIL TCPSocket 3310 TCPAddr 127.0.0.1 SelfCheck 600 User _clamav AllowSupplementaryGroups true This setup was stable with 0.98.1 but since updating to 0.98.3 I've seen several segfaults like below (debug, backtrace and a couple of prints from gdb included). Any ideas? Any requests for further information next time it happens? $THRMGR: queue (single) crossed low threshold - signaling $THRMGR: queue (bulk) crossed low threshold - signaling $Received POLLIN|POLLHUP on fd 8 $Got new connection, FD 13 $Received POLLIN|POLLHUP on fd 9 $fds_poll_recv: timeout after 5 seconds $Received POLLIN|POLLHUP on fd 13 $got command CONTSCAN /var/amavisd/tmp/amavis-20140512T125548-02478-meKXMAUm/parts (69, 7), argument: /var/amavisd/tmp/amavis-20140512T125548-02478-meKXMAUm/parts $mode - MODE_WAITREPLY $THRMGR: queue (single) crossed low threshold - signaling $Breaking command loop, mode is no longer MODE_COMMAND $THRMGR: queue (bulk) crossed low threshold - signaling $Consumed entire command $Number of file descriptors polled: 1 fds $fds_poll_recv: timeout after 600 seconds LibClamAV debug: in cli_magic_scandesc (reclevel: 0/16) LibClamAV debug: Recognized Raw mail file LibClamAV debug: cache_check: 508dfbcb3a25db9c5b22eaa7ee97081e is negative LibClamAV debug: Starting cli_scanmail(), recursion = 1 LibClamAV debug: in mbox() LibClamAV debug: parseEmailFile LibClamAV debug: parseEmailFile: check 'Received: from localhost (unknown [123.16.129.96])' fullline 0x0 LibClamAV debug: parseEmailFile: check 'by [REDACTED] (Postfix) with ESMTP id 3gS1nn3QPBz74R3' fullline 0x0 LibClamAV debug: parseEmailFile: check 'for [REDACTED]; Mon, 12 May 2014 13:35:23 +0100 (BST)' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Received: from [167.39.199.27] (helo=jnxfcznftn.fxztsfyhme.info)' fullline 0x0 LibClamAV debug: parseEmailFile: check 'by localhost with esmtpa (Exim 4.69)' fullline 0x0 LibClamAV debug: parseEmailFile: check '(envelope-from )' fullline 0x0 LibClamAV debug: parseEmailFile: check 'id 1MMK6T-0496yb-WZ' fullline 0x0 LibClamAV debug: parseEmailFile: check 'for [REDACTED]; Mon, 12 May 2014 19:35:24 +0700' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Date: Mon, 12 May 2014 19:35:24 +0700' fullline 0x0 LibClamAV debug: parseEmailFile: check 'From: UPS Quantum View auto-not...@ups.com' fullline 0x0 LibClamAV debug: parseEmailFile: check 'X-Mailer: The Bat! (v3.0.0.15) Professional' fullline 0x0 LibClamAV debug: parseEmailFile: check 'X-Priority: 3 (Normal)' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Message-ID: 2465346162.j7a29kv6581...@moezlge.bpkpejifhl.net' fullline 0x0 LibClamAV debug: parseEmailFile: check 'To: [REDACTED]' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Cc: [REDACTED]' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Subject: UPS Notification, Tracking Number 1484-527152' fullline 0x0 LibClamAV debug: parseEmailFile: check 'MIME-Version: 1.0' fullline 0x0 LibClamAV debug: parseEmailFile: check 'Content-Type: multipart/mixed;' fullline 0x0 LibClamAV debug: parseEmailFile: check ' boundary=--9305594F5ADCAB39' fullline 0x443d5bd6ce0 LibClamAV debug: parseEmailHeader 'Content-Type: multipart/mixed; boundary=--9305594F5ADCAB39' LibClamAV debug: parseMimeHeader: cmd='Content-Type', arg=' multipart/mixed; boundary=--9305594F5ADCAB39' LibClamAV debug: messageSetMimeType: 'multipart' LibClamAV debug: mimeArgs = ' boundary=--9305594F5ADCAB39' LibClamAV debug: Add arguments ' boundary=--9305594F5ADCAB39' LibClamAV debug: messageAddArgument, arg='boundary=--9305594F5ADCAB39' LibClamAV debug: parseEmailFile: check '' fullline 0x0 LibClamAV debug: End of header information LibClamAV debug: newline_in_header, check 9305594F5ADCAB39 LibClamAV debug: getline_from_mbox: fmap need failed LibClamAV debug: parseEmailFile: return LibClamAV debug: in parseEmailBody, 0 files saved so far LibClamAV debug: Parsing mail file LibClamAV debug: mimeType = 5 LibClamAV debug: Content-type 'multipart' handler LibClamAV debug: boundaryStart: found --9305594F5ADCAB39 in 9305594F5ADCAB39 LibClamAV debug: Now read in part 0 LibClamAV debug: Multipart 0: About to parse folded header 'Content-Type: multipart/alternative; boundary=--7F07E60B2BC74B5' LibClamAV debug: parseEmailHeader 'Content-Type: multipart/alternative; boundary=--7F07E60B2BC74B5' LibClamAV debug: parseMimeHeader: cmd='Content-Type', arg=' multipart/alternative; boundary=--7F07E60B2BC74B5' LibClamAV debug: messageSetMimeType: 'multipart' LibClamAV debug: mimeArgs = ' boundary=--7F07E60B2BC74B5' LibClamAV debug: Add arguments ' boundary=--7F07E60B2BC74B5' LibClamAV debug:
Re: [clamav-users] 0.98.3, new segfault probably related to email parser
On 2014/05/12 14:57, Steve Basford wrote:
On Mon, May 12, 2014 2:12 pm, Stuart Henderson wrote:
I'm running clamav on OpenBSD/amd64 5.5 (with various sanesecurity
hdb's, if that matters). Built from ports (with LLVM 3.3).
Hi,
Is is random or only on a certain email?
Do have a full copy of the email shown in your log?
If you do, does a clamdscan on the email cause a crash?
I've isolated a certain email which seems particularly likely to
trigger it, but it doesn't happen every time for that message.
From the last few attempts running clamdscan in a loop, it
took approx 100, 10, 300, 130 attempts to hit the crash.
It also happens for clamscan (I removed all standard db's and
included only the single signature triggered by this mail so it
would start quickly).
I have only hit this crash if a signature is matched (i.e.
I haven't hit it if I remove phish.ndb).
Here's a backtrace from clamscan built with -O0, I can provide
message/sig to attempt to reproduce off-list.
(gdb) bt full
#0 0x08617687540b in boundaryEnd (line=0x8616bbebd81 ,
boundary=0x8616ad88b60 --9305594F5ADCAB39) at mbox.c:2273
len = 26
newline = 0x86169a74000
p = 0x86169a74000
p2 = 0x86169a73fff Address 0x86169a73fff out of bounds
#1 0x086176873baa in parseEmailBody (messageIn=0x861753cd980, textIn=0x0,
mctx=0x7f7c31a0, recursion_level=0) at mbox.c:1494
line = 0x8616bbebd81
lines = 4
m = (message **) 0x8616bbeb890
old_rc = FAIL
subtype = 5
htmltextPart = 0
inMimeHead = 0
mimeSubtype = 0x8616bbeb000 mixed
boundary = 0x8616ad88b60 --9305594F5ADCAB39
aMessage = (message *) 0x86169a75080
mimeType = MULTIPART
inhead = 0
i = 0
t_line = (const text *) 0x8616bbeb270
multiparts = 0
messages = (message **) 0x8616bbeb890
rc = OK
aText = (text *) 0x0
mainMessage = (message *) 0x861753cd980
fb = (fileblob *) 0x0
infected = false
engine = (const struct cl_engine *) 0x8617164e800
doPhishingScan = 1
#2 0x086176871e35 in cli_parse_mbox (
dir=0x8616fe80d80 /tmp//clamav-d32876238e1c0847f3ed68257ceb49c6.tmp,
ctx=0x7f7c39e0) at mbox.c:508
retcode = 0
body = (message *) 0x861753cd980
buffer = Return-Path: \n\000\000c6, '\0' repeats 20 times,
÷V.\230\215íÐI\000\000\000\000\000\000\000\000^\016èoa\b\000\000\2205üÿ\177\177\000\000\236dµva\b\000\000\002,
'\0' repeats 23 times, ÃñÖha\b, '\0' repeats 14 times,
a\b\000\000\000\000\000\000\000\000\000\000÷V.\230\215íÐI\000\000\000\000\000\000\000\000\200\rèoa\b\000\0002\000\000\000\000\000\000\000âdµva\b\000\000\002,
'\0' repeats 23 times, d¥Ùha\b, '\0' repeats 290 times,
\000\000\000\000p2üÿ\177\177\000\000±\rèoa\b\000\000...
mctx = {
dir = 0x8616fe80d80 /tmp//clamav-d32876238e1c0847f3ed68257ceb49c6.tmp,
rfc821Table = 0x8616ad986e0, subtypeTable = 0x8616ad88080,
ctx = 0x7f7c39e0, files = 0}
at = 21404
map = (fmap_t *) 0x8616796b000
#3 0x086176871845 in cli_mbox (
dir=0x8616fe80d80 /tmp//clamav-d32876238e1c0847f3ed68257ceb49c6.tmp,
ctx=0x7f7c39e0) at mbox.c:309
No locals.
#4 0x086176866520 in cli_scanmail (ctx=0x7f7c39e0) at scanners.c:1804
dir = 0x8616fe80d80 /tmp//clamav-d32876238e1c0847f3ed68257ceb49c6.tmp
ret = 2145
viruses_found = 0
#5 0x08617686a49c in magic_scandesc (ctx=0x7f7c39e0,
type=CL_TYPE_MAIL) at scanners.c:2697
ret = 0
dettype = CL_TYPE_ANY
typercg = 1 '\001'
current_container_type = CL_TYPE_ANY
current_container_size = 0
hashed_size = 21404
hash = uÒ\000\000Qÿ·/\005|ÝÅgB§Æ
old_hook_lsig_matches = (bitset_t *) 0x8616bbeb780
filetype = 0x86176b1bf94 CL_TYPE_MAIL
cache_clean = 0
res = 1
#6 0x08617686c178 in cli_base_scandesc (desc=3, ctx=0x7f7c39e0,
type=CL_TYPE_ANY) at scanners.c:3007
sb = {st_mode = 33184, st_dev = 9985, st_ino = 45975, st_nlink = 1,
st_uid = 1000, st_gid = 0, st_rdev = -1, st_atim = {tv_sec = 1399905336,
tv_nsec = 495715245}, st_mtim = {tv_sec = 1399904591, tv_nsec = 62550638},
st_ctim = {tv_sec = 1399904591, tv_nsec = 62555667}, st_size = 21404,
st_blocks = 48, st_blksize = 4096, st_flags = 0, st_gen = 0,
__st_birthtim = {tv_sec = 0, tv_nsec = 0}}
ret = 32639
#7 0x08617686c1fa in cli_magic_scandesc (desc=3, ctx=0x7f7c39e0)
at scanners.c:3016
No locals.
#8 0x08617686cbf6 in scan_common (desc=3, map=0x0,
virname=0x7f7c3c58, scanned=0x85f672275d8, engine=0x8617164e800,
---Type return to continue, or q return to quit---
scanoptions=4219447, context=0x7f7c3c30) at scanners.c:3233
ctx = {virname = 0x7f7c3c58, num_viruses = 0, size_viruses = 0,
scanned = 0x85f672275d8, root = 0x0, engine
