Re: [clamav-users] ScanOnAccess: ... (null) FOUND

2018-08-09 Thread Kretschmer, Jens 
> Do you have the OnAccessExtraScanning option on by chance?

Yes, OnAccessExtraScanning is turned on. 

I was able to reproduce this behavior on a different machine. It uses the same 
configuration as the first machine (the clamconf output can be found in my 
previous E-Mail).
I rebooted the machine yesterday at 13:45 and left it untouched. I did not even 
log in. Today I logged in via ssh and the first ScanOnAccess message since the 
reboot in the journal was:

Aug 09 09:36:47 hostname2 clamd[]: SelfCheck: Database status OK.
Aug 09 09:37:24 hostname2 clamd[]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/.sh_histdir/hostname2.0'
Aug 09 09:37:24 hostname2 clamd[]: ScanOnAccess: 
/home/user1/.sh_histdir/hostname2.0: (null) FOUND
Aug 09 09:39:34 hostname2 clamd[]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test2'
Aug 09 09:39:34 hostname2 clamd[]: ScanOnAccess: /home/user1/test2: (null) 
FOUND

On the first machine I restarted clamd@scan yesterday 13:32:05 and ran the 
following script

#!/bin/ksh
file="testfile.txt"
while true; do
  echo "test123" > $file
  sync
  rm $file
done

after about 13 hours clamd starts to show only the messages: "ScanOnAccess: 
Unable to kick off extra scanning."

Aug 09 02:40:37 hostname1 clamd[15866]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test/testfile.txt'
Aug 09 02:40:38 hostname1 clamd[15866]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test/testfile.txt'
Aug 09 02:40:39 hostname1 clamd[15866]: ScanOnAccess: Unable to kick off extra 
scanning.
Aug 09 02:40:39 hostname1 clamd[15866]: ScanOnAccess: Unable to kick off extra 
scanning.

Best regards,
Jens
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Bytecode 86 failed to run

2018-08-09 Thread Tilman Schmidt 
The machine pulled bytecode.cld version 327 last night:

Thu Aug  9 03:35:33 2018 -> Downloading bytecode-327.cdiff [100%]
Thu Aug  9 03:35:33 2018 -> bytecode.cld updated (version: 327, sigs:
91, f-level: 63, builder: neo)

Now the bytecode error messages are gone:

$ clamscan .java/deployment/cache/6.0/6/41d72bc6-799a1944
.java/deployment/cache/6.0/6/41d72bc6-799a1944: OK

--- SCAN SUMMARY ---
Known viruses: 6603127
Engine version: 0.100.1
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 13.36 MB
Data read: 4.67 MB (ratio 2.86:1)
Time: 15.219 sec (0 m 15 s)

Thanks,
Tilman

Am 07.08.2018 um 20:02 schrieb Tilman Schmidt:
> 
> $ sha256sum .java/deployment/cache/6.0/6/41d72bc6-799a1944
> 97432da2d77d78872ececf4de2eef1c759e7846db85d4fb14eb02764b6bd02ad
> .java/deployment/cache/6.0/6/41d72bc6-799a1944
> 
[...]
>>
>> The problem is back, this time with two bytecodes: 2 and 90.
>> ClamAV version is 0.100.1.
>> The last clamscan run without the error was on 2018-07-26 06:00.
>> The preceding freshclam run said:
>>
>> Thu Jul 26 05:49:13 2018 -> main.cld is up to date (version: 58, sigs:
>> 4566249, f-level: 60, builder: sigmgr)
>> Thu Jul 26 05:49:13 2018 -> daily.cld is up to date (version: 24783,
>> sigs: 2025533, f-level: 63, builder: neo)
>> Thu Jul 26 05:49:13 2018 -> bytecode.cld is up to date (version: 325,
>> sigs: 90, f-level: 63, builder: neo)
>>
>> The first clamscan run exhibiting the problem was on 2018-07-27 06:00.
>> The freshclam run preceding that said:
>>
>> Fri Jul 27 05:49:24 2018 -> main.cld is up to date (version: 58, sigs:
>> 4566249, f-level: 60, builder: sigmgr)
>> Fri Jul 27 05:49:24 2018 -> daily.cld is up to date (version: 24786,
>> sigs: 2027088, f-level: 63, builder: neo)
>> Fri Jul 27 05:49:24 2018 -> bytecode.cld is up to date (version: 326,
>> sigs: 93, f-level: 63, builder: neo)
>>
>> So it would seem that bytecode.cld version 326 is the culprit.
>>
>> The error message is again triggered only by a single file:
>>
>> -rw-rw-r-- 1 tschmidt tschmidt 4896567 Jul 11 11:15
>> .java/deployment/cache/6.0/6/41d72bc6-799a1944
>>
>> As you can see the file has been there for about four weeks, but the
>> messages started only two weeks ago, so it seems their reappearance was
>> triggered by the signature update, not by the appearance of the file.


-- 
Tilman Schmidt
cardtech Card & POS Service GmbH
Cologne, Germany
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] Bytecode 86 failed to run

2018-08-09 Thread Al Varnell 
If by pulled you mean updated to, then yes that happened and it only included 
these two changes:
> Dropped Detection Signatures:
>* BC.Img.Exploit.CVE_2018_3839-6614872-0
>* BC.Img.Exploit.CVE_2018_3839-6614873-0

Which were previously added on 26 July by bytecode - 326.

So I'd have to guess that was all that was needed to fix the issues some have 
been observing.

-Al-

On Thu, Aug 09, 2018 at 01:12 AM, Tilman Schmidt wrote:
> The machine pulled bytecode.cld version 327 last night:
> 
> Thu Aug  9 03:35:33 2018 -> Downloading bytecode-327.cdiff [100%]
> Thu Aug  9 03:35:33 2018 -> bytecode.cld updated (version: 327, sigs:
> 91, f-level: 63, builder: neo)
> 
> Now the bytecode error messages are gone:
> 
> $ clamscan .java/deployment/cache/6.0/6/41d72bc6-799a1944
> .java/deployment/cache/6.0/6/41d72bc6-799a1944: OK
> 
> --- SCAN SUMMARY ---
> Known viruses: 6603127
> Engine version: 0.100.1
> Scanned directories: 0
> Scanned files: 1
> Infected files: 0
> Data scanned: 13.36 MB
> Data read: 4.67 MB (ratio 2.86:1)
> Time: 15.219 sec (0 m 15 s)
> 
> Thanks,
> Tilman
> 
> Am 07.08.2018 um 20:02 schrieb Tilman Schmidt:
>> 
>> $ sha256sum .java/deployment/cache/6.0/6/41d72bc6-799a1944
>> 97432da2d77d78872ececf4de2eef1c759e7846db85d4fb14eb02764b6bd02ad
>> .java/deployment/cache/6.0/6/41d72bc6-799a1944
>> 
> [...]
>>> 
>>>The problem is back, this time with two bytecodes: 2 and 90.
>>>ClamAV version is 0.100.1.
>>>The last clamscan run without the error was on 2018-07-26 06:00.
>>>The preceding freshclam run said:
>>> 
>>>Thu Jul 26 05:49:13 2018 -> main.cld is up to date (version: 58, sigs:
>>>4566249, f-level: 60, builder: sigmgr)
>>>Thu Jul 26 05:49:13 2018 -> daily.cld is up to date (version: 24783,
>>>sigs: 2025533, f-level: 63, builder: neo)
>>>Thu Jul 26 05:49:13 2018 -> bytecode.cld is up to date (version: 325,
>>>sigs: 90, f-level: 63, builder: neo)
>>> 
>>>The first clamscan run exhibiting the problem was on 2018-07-27 06:00.
>>>The freshclam run preceding that said:
>>> 
>>>Fri Jul 27 05:49:24 2018 -> main.cld is up to date (version: 58, sigs:
>>>4566249, f-level: 60, builder: sigmgr)
>>>Fri Jul 27 05:49:24 2018 -> daily.cld is up to date (version: 24786,
>>>sigs: 2027088, f-level: 63, builder: neo)
>>>Fri Jul 27 05:49:24 2018 -> bytecode.cld is up to date (version: 326,
>>>sigs: 93, f-level: 63, builder: neo)
>>> 
>>>So it would seem that bytecode.cld version 326 is the culprit.
>>> 
>>>The error message is again triggered only by a single file:
>>> 
>>>-rw-rw-r-- 1 tschmidt tschmidt 4896567 Jul 11 11:15
>>>.java/deployment/cache/6.0/6/41d72bc6-799a1944
>>> 
>>>As you can see the file has been there for about four weeks, but the
>>>messages started only two weeks ago, so it seems their reappearance was
>>>triggered by the signature update, not by the appearance of the file.

-Al-
-- 
Al Varnell
Mountain View, CA







smime.p7s
Description: S/MIME cryptographic signature
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] ScanOnAccess: ... (null) FOUND

2018-08-09 Thread Micah Snyder (micasnyd) 
I've been running clamd with OnAccess on a box using Firefox and just yesterday 
saw the (null) FOUND as well.  I haven't had a chance to take the file in 
question and debug with clamscan to reproduce it and figure out what's causing 
it but I will do so soon.

Regarding your second issue, I believe there is a memory leak with the 
OnAccessExtraScanning feature because the threads that process the extra 
scanning work aren't being join()'d.
I have a feeling that may be why you're seeing "Unable to kick off extra 
scanning".  We're getting near the end of our development cycle for 0.101 and 
still have some tough work left, but we'll try to find a solution to the 
OnAccessExtraScanning thread joining issue if time permits.

Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Aug 9, 2018, at 4:03 AM, Kretschmer, Jens 
mailto:kretschmer.j...@siemens.com>> wrote:

Do you have the OnAccessExtraScanning option on by chance?

Yes, OnAccessExtraScanning is turned on.

I was able to reproduce this behavior on a different machine. It uses the same 
configuration as the first machine (the clamconf output can be found in my 
previous E-Mail).
I rebooted the machine yesterday at 13:45 and left it untouched. I did not even 
log in. Today I logged in via ssh and the first ScanOnAccess message since the 
reboot in the journal was:

Aug 09 09:36:47 hostname2 clamd[]: SelfCheck: Database status OK.
Aug 09 09:37:24 hostname2 clamd[]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/.sh_histdir/hostname2.0'
Aug 09 09:37:24 hostname2 clamd[]: ScanOnAccess: 
/home/user1/.sh_histdir/hostname2.0: (null) FOUND
Aug 09 09:39:34 hostname2 clamd[]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test2'
Aug 09 09:39:34 hostname2 clamd[]: ScanOnAccess: /home/user1/test2: (null) 
FOUND

On the first machine I restarted clamd@scan yesterday 13:32:05 and ran the 
following script

#!/bin/ksh
file="testfile.txt"
while true; do
 echo "test123" > $file
 sync
 rm $file
done

after about 13 hours clamd starts to show only the messages: "ScanOnAccess: 
Unable to kick off extra scanning."

Aug 09 02:40:37 hostname1 clamd[15866]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test/testfile.txt'
Aug 09 02:40:38 hostname1 clamd[15866]: ScanOnAccess: Performing additional 
scanning on file '/home/user1/test/testfile.txt'
Aug 09 02:40:39 hostname1 clamd[15866]: ScanOnAccess: Unable to kick off extra 
scanning.
Aug 09 02:40:39 hostname1 clamd[15866]: ScanOnAccess: Unable to kick off extra 
scanning.

Best regards,
Jens
___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

Re: [clamav-users] clamdscan and TCPAddr

2018-08-09 Thread Micah Snyder (micasnyd) 
Hajo,

Good call testing clamdscan with strace!  That's an interesting issue.  I'm 
glad to hear that setting TCPAddr solved it for you.


Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.


On Aug 7, 2018, at 4:13 AM, Hajo Locke 
mailto:hajo.lo...@gmx.de>> wrote:

Hello List,

have an odd behaviour of clamav. Version is 0.100.1+dfsg-1ubuntu0.16.04.2
Short:
clamscan is able to find a virus in file, clamdscan not. 1st i thought about 
deprecation of AllowSupplementaryGroups, but was not confirmed.

clamdscan -v tells only about an error, but no detailed info, so I did a strace 
to clamdscan and found this errormessage:

connect(3, {sa_family=AF_INET6, sin6_port=htons(3310), inet_pton(AF_INET6, 
"::", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = -1 EADDRNOTAVAIL 
(Cannot assign requested address)

In clamd.conf i have:

TCPSocket 3310
By default clamav binds on any configured IP-Adress, i can see this with lsof.
It looks like that clamdscan tries to connect to ipv6 Adress first and ends up 
in this errormessage and exits, thats my reading of the line.
It is working again if i add "TCPAddr 127.0.0.1" to my clamd.conf.

Is this an expected behaviour? ipv6 is disabled on this machine, clamdscan 
should not try to use it.

Thanks,
Hajo

___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml

___
clamav-users mailing list
clamav-users@lists.clamav.net
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-users


Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq

http://www.clamav.net/contact.html#ml