Mailing List Archive

Hi there,

On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:

> I'm using clamd to make a large data scanning using INSTREAM ...
> If I send only one INSTREAM chunk with EICAR inside it is correctly
> detected, but if I send several chunks plus EICAR string, it is not
> ...
> char *eicarTest =
> "X5O!P%@AP[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*";
> char *junkData = "89jsdkfj";
> ...
> ... plus the 0 length chunk to finish..
>
> In that case it is not detected, clamd says: instream(local): OK
>
> Does it make any sense? I will appreciate any help.

Well it sort of makes sense. :/

I use INSTREAM all the time in my milters. If I do the same thing
as you with my homebrew Perl library, I see the expected detection:

8<----------------------------------------------------------------------
$ cat --show-nonprinting eicar_mod.tst
zINSTREAM^@^@^@^D^LX5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*89jsdkfj^@^@^@^@^@
$ ./tempscan.pl eicar_mod.tst
Sent [96] bytes to clamd...
Reply is [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
$
8<----------------------------------------------------------------------

Maybe you aren't sending what you think you're sending? You could use
something like tcpdump to see exactly what is 'going down the wire'.

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

Thank you for your answer.
I'm using Windows clamd release 0.104.2
I have double checked with wireshark and the data sent is ok.

suppose I just send: char *eicarTest = "X5O!P%@AP
[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"
Result is ok: instream(local):
Win.Test.EICAR_HDB-1(44d88612fea8a8f36de82e1278abb02f:68) FOUND

then I send: char *eicarTest = "X5O!P%@AP
[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*hjyhj"
(5 more characters)
Result is not ok: instream(local): OK

Perhaps Windows Clamd release works differently than Linux release?

Thank you



El mié, 2 mar 2022 a las 15:03, G.W. Haywood via clamav-users (<
clamav-users@lists.clamav.net>) escribió:

> Hi there,
>
> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>
> > I'm using clamd to make a large data scanning using INSTREAM ...
> > If I send only one INSTREAM chunk with EICAR inside it is correctly
> > detected, but if I send several chunks plus EICAR string, it is not
> > ...
> > char *eicarTest =
> > "X5O!P%@AP[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*";
> > char *junkData = "89jsdkfj";
> > ...
> > ... plus the 0 length chunk to finish..
> >
> > In that case it is not detected, clamd says: instream(local): OK
> >
> > Does it make any sense? I will appreciate any help.
>
> Well it sort of makes sense. :/
>
> I use INSTREAM all the time in my milters. If I do the same thing
> as you with my homebrew Perl library, I see the expected detection:
>
> 8<----------------------------------------------------------------------
> $ cat --show-nonprinting eicar_mod.tst
> zINSTREAM^@^@^@^D^LX5O!P%@AP
> [4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*89jsdkfj^@^@^@^@^@
> $ ./tempscan.pl eicar_mod.tst
> Sent [96] bytes to clamd...
> Reply is [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> $
> 8<----------------------------------------------------------------------
>
> Maybe you aren't sending what you think you're sending? You could use
> something like tcpdump to see exactly what is 'going down the wire'.
>
> --
>
> 73,
> Ged.
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

I have made another test using clamdscan.
If I scan a file with just the EICAR string the detection is fine.
If I modify that file adding a single character, the detection fails.

clamdscan file ( file content: X5O!P%@AP
[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
Infected files: 1

clamdscan file ( file content:
X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
)
Infected files: 0

(second test has a '=' added at the end)

I don't understand it.
Thank you in advance!






El mié, 2 mar 2022 a las 15:03, G.W. Haywood via clamav-users (<
clamav-users@lists.clamav.net>) escribió:

> Hi there,
>
> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>
> > I'm using clamd to make a large data scanning using INSTREAM ...
> > If I send only one INSTREAM chunk with EICAR inside it is correctly
> > detected, but if I send several chunks plus EICAR string, it is not
> > ...
> > char *eicarTest =
> > "X5O!P%@AP[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*";
> > char *junkData = "89jsdkfj";
> > ...
> > ... plus the 0 length chunk to finish..
> >
> > In that case it is not detected, clamd says: instream(local): OK
> >
> > Does it make any sense? I will appreciate any help.
>
> Well it sort of makes sense. :/
>
> I use INSTREAM all the time in my milters. If I do the same thing
> as you with my homebrew Perl library, I see the expected detection:
>
> 8<----------------------------------------------------------------------
> $ cat --show-nonprinting eicar_mod.tst
> zINSTREAM^@^@^@^D^LX5O!P%@AP
> [4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*89jsdkfj^@^@^@^@^@
> $ ./tempscan.pl eicar_mod.tst
> Sent [96] bytes to clamd...
> Reply is [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> $
> 8<----------------------------------------------------------------------
>
> Maybe you aren't sending what you think you're sending? You could use
> something like tcpdump to see exactly what is 'going down the wire'.
>
> --
>
> 73,
> Ged.
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

Hi there,

On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:

> I have made another test using clamdscan.
> If I scan a file with just the EICAR string the detection is fine.
> If I modify that file adding a single character, the detection fails.
>
> clamdscan file ( file content: X5O!P%@AP
> [.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
> Infected files: 1
>
> clamdscan file ( file content:
> X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> )
> Infected files: 0
>
> (second test has a '=' added at the end)

It seems to me that in your second test there is more than just one
single character appended, but when I do what you say you're doing I
see the results which I expect.

There are 68 characters in the original eicar file and 69 in the file
which has the extra '=' character appened:

8<----------------------------------------------------------------------
ged@pi4b530214:~ $ diff eicar.orig eicar.single_character_appended
1c1
< X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
\ No newline at end of file
---
> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
\ No newline at end of file
ged@pi4b530214:~ $
8<----------------------------------------------------------------------

The harness tells me that it has sent 68 characters from the file to
clamd when I send the original eicar file, and 69 characters when it
sends the modified file. This gives me confidence that it's sent what
I think it's sent.

Here is the output that I see from my little harness for the original:

8<----------------------------------------------------------------------
ged@pi4b530214:~ $ ./tempscan.pl eicar.orig
filename=[eicar.orig]
Sent [68] bytes to clamd...
REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
8<----------------------------------------------------------------------

Here it is for the modified file:

8<----------------------------------------------------------------------
ged@pi4b530214:~ $ ./tempscan.pl eicar.single_character_appended
filename=[eicar.single_character_appended]
Sent [69] bytes to clamd...
REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
8<----------------------------------------------------------------------

I don't think the difference in behaviour would be explained by the
fact that you're using Windows - but I was wrong before, once. :)

Perhaps you can post the output of 'clamconf -n' and the source of the
program that you're using to send the file if it's reasonably compact.
The executable wouldn't be much use to me, although I could spin up a
VM if absolutely necessary.

If you have Perl on your computer you might want to try this script; I
hope your mail client doesn't mangle the lines too much, there are 47
lines in the script.

8<----------------------------------------------------------------------
File name: tempscan.pl
8<----------------------------------------------------------------------
#!/usr/bin/perl
# Send a file to clamd.
# usage: tempscan.pl <filename>
use strict;
use IO::Socket;
use File::Slurp;
# Make sure the IP address and port number suit your clamd setup!
my $peer_addr = '127.0.0.1';
my $peer_port = '3310';
my $filename = $ARGV[0];
printf( "filename=[$filename]\n" );
my $clam1;
if( ! ($clam1 = IO::Socket::INET->new(Proto=>"tcp",PeerAddr=>$peer_addr,PeerPort=>$peer_port)))
{
printf( 'Failed to connect to ClamAV daemon on [%s:%s]', $peer_addr, $peer_port );
exit;
}
my $remaining = read_file( $filename );
my $part_length = length($remaining);
print $clam1 "nINSTREAM\n";
while( $remaining ) # Send in chunks, maximum 65535 bytes per chunk.
{
my $chunk = substr( $remaining, 0, 65_535, '' ) ;
my $chunk_length = pack( 'N', length( $chunk ) );
print( $clam1 $chunk_length . $chunk );
printf( "Sent [%d] bytes to clamd...\n", length($chunk) );
}
my $terminator = pack( 'N', 0 );
print $clam1 $terminator,"\n"; # The terminating null for the data.
my $reply_timeout = 10_000;
my $reply = '';
while( !$reply && $reply_timeout )
{
if( ! ($reply = <$clam1>) )
{
usleep( 1_000_000 );
$reply_timeout--;
if( ! $reply_timeout )
{
print( "TIMEOUT waiting for response from clamd\n" );
$reply = 'TIMEOUT';
}
}
}
close $clam1;
chomp $reply;
printf( "REPLY IS [%s]\n", $reply );
8<----------------------------------------------------------------------

HTH

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

Hi,

Thank you for your answer.
I think the issue is in the Windows clamd release.
I made a tiny perl code based on your, running over Linux and connecting to
Clamd running on Windows.
Code is as follows:

#!/usr/bin/perl

use strict;
use IO::Socket;

my $peer = '172.20.0.165';
my $port = '3310';
my $clamScan;

if (!($clamScan =
IO::Socket::INET->new(Proto=>'tcp',PeerAddr=>$peer,PeerPort=>$port)))
{ printf ("Cannot connect to ClamAV");
exit;
}
print $clamScan "nINSTREAM\n";

my $chunk = 'X5O!P%@AP
[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*';

my $chlen = pack('N', length($chunk));
print $clamScan $chlen . $chunk;

$chlen = pack('N',0);
print $clamScan $chlen;

close $clamScan;

------

That code correctly reports EICAR:
instream(172.20.0.170@41836):
Win.Test.EICAR_HDB-1(44d88612fea8a8f36de82e1278abb02f:68) FOUND

If I modify the $chunk var, adding several chars, detection fails:

my $chunk = 'X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*kkkkkk';


instream(172.20.0.170@41838): OK


I'm going to install Clamd Linux version and test it again, but everything
here means that Windows clamd is not well working.
Thank you very much!





El jue, 3 mar 2022 a las 8:03, G.W. Haywood via clamav-users (<
clamav-users@lists.clamav.net>) escribió:

> Hi there,
>
> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>
> > I have made another test using clamdscan.
> > If I scan a file with just the EICAR string the detection is fine.
> > If I modify that file adding a single character, the detection fails.
> >
> > clamdscan file ( file content: X5O!P%@AP
> > [.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
> > Infected files: 1
> >
> > clamdscan file ( file content:
> > X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> > )
> > Infected files: 0
> >
> > (second test has a '=' added at the end)
>
> It seems to me that in your second test there is more than just one
> single character appended, but when I do what you say you're doing I
> see the results which I expect.
>
> There are 68 characters in the original eicar file and 69 in the file
> which has the extra '=' character appened:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ diff eicar.orig eicar.single_character_appended
> 1c1
> < X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
> \ No newline at end of file
> ---
> > X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> \ No newline at end of file
> ged@pi4b530214:~ $
> 8<----------------------------------------------------------------------
>
> The harness tells me that it has sent 68 characters from the file to
> clamd when I send the original eicar file, and 69 characters when it
> sends the modified file. This gives me confidence that it's sent what
> I think it's sent.
>
> Here is the output that I see from my little harness for the original:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ ./tempscan.pl eicar.orig
> filename=[eicar.orig]
> Sent [68] bytes to clamd...
> REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> 8<----------------------------------------------------------------------
>
> Here it is for the modified file:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ ./tempscan.pl eicar.single_character_appended
> filename=[eicar.single_character_appended]
> Sent [69] bytes to clamd...
> REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> 8<----------------------------------------------------------------------
>
> I don't think the difference in behaviour would be explained by the
> fact that you're using Windows - but I was wrong before, once. :)
>
> Perhaps you can post the output of 'clamconf -n' and the source of the
> program that you're using to send the file if it's reasonably compact.
> The executable wouldn't be much use to me, although I could spin up a
> VM if absolutely necessary.
>
> If you have Perl on your computer you might want to try this script; I
> hope your mail client doesn't mangle the lines too much, there are 47
> lines in the script.
>
> 8<----------------------------------------------------------------------
> File name: tempscan.pl
> 8<----------------------------------------------------------------------
> #!/usr/bin/perl
> # Send a file to clamd.
> # usage: tempscan.pl <filename>
> use strict;
> use IO::Socket;
> use File::Slurp;
> # Make sure the IP address and port number suit your clamd setup!
> my $peer_addr = '127.0.0.1';
> my $peer_port = '3310';
> my $filename = $ARGV[0];
> printf( "filename=[$filename]\n" );
> my $clam1;
> if( ! ($clam1 =
> IO::Socket::INET->new(Proto=>"tcp",PeerAddr=>$peer_addr,PeerPort=>$peer_port)))
> {
> printf( 'Failed to connect to ClamAV daemon on [%s:%s]', $peer_addr,
> $peer_port );
> exit;
> }
> my $remaining = read_file( $filename );
> my $part_length = length($remaining);
> print $clam1 "nINSTREAM\n";
> while( $remaining ) # Send in chunks, maximum 65535 bytes
> per chunk.
> {
> my $chunk = substr( $remaining, 0, 65_535, '' ) ;
> my $chunk_length = pack( 'N', length( $chunk ) );
> print( $clam1 $chunk_length . $chunk );
> printf( "Sent [%d] bytes to clamd...\n", length($chunk) );
> }
> my $terminator = pack( 'N', 0 );
> print $clam1 $terminator,"\n"; # The terminating null for the data.
> my $reply_timeout = 10_000;
> my $reply = '';
> while( !$reply && $reply_timeout )
> {
> if( ! ($reply = <$clam1>) )
> {
> usleep( 1_000_000 );
> $reply_timeout--;
> if( ! $reply_timeout )
> {
> print( "TIMEOUT waiting for response from clamd\n" );
> $reply = 'TIMEOUT';
> }
> }
> }
> close $clam1;
> chomp $reply;
> printf( "REPLY IS [%s]\n", $reply );
> 8<----------------------------------------------------------------------
>
> HTH
>
> --
>
> 73,
> Ged.
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

I have the same result using Linux clamd release 0.104.2
#/usr/local/sbin# ./clamd --ver
ClamAV 0.104.2/26470/Thu Mar 3 06:49:16 2022

The code just adds a simple '=' character at the end of the chunk and
detection fails.

#!/usr/bin/perl

use strict;
use IO::Socket;

my $peer = 'localhost'; #172.20.0.165';
my $port = '3310';
my $clamScan;

if (!($clamScan =
IO::Socket::INET->new(Proto=>'tcp',PeerAddr=>$peer,PeerPort=>$port)))
{ printf ("Cannot connect to ClamAV");
exit;
}
print $clamScan "nINSTREAM\n";

my $chunk = 'X5O!P%@AP
[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*'=;

my $chlen = pack('N', length($chunk));
print $clamScan $chlen . $chunk;

$chlen = pack('N',0);
print $clamScan $chlen;

my $reply_timeout = 10_000;
my $reply = "";
while (!$reply && $reply_timeout)
{
if (!($reply = <$clamScan>))
{ usleep(1_000_0000);
$reply_timeout--;
if (!$reply_timeout)
{ print ("TIMEOUT\n");
$reply = 'TIMEOUT';
}
}
}

printf $reply;


close $clamScan;
---------------------------------


It doesn't work for me.
Thank you!




El jue, 3 mar 2022 a las 8:03, G.W. Haywood via clamav-users (<
clamav-users@lists.clamav.net>) escribió:

> Hi there,
>
> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>
> > I have made another test using clamdscan.
> > If I scan a file with just the EICAR string the detection is fine.
> > If I modify that file adding a single character, the detection fails.
> >
> > clamdscan file ( file content: X5O!P%@AP
> > [.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
> > Infected files: 1
> >
> > clamdscan file ( file content:
> > X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> > )
> > Infected files: 0
> >
> > (second test has a '=' added at the end)
>
> It seems to me that in your second test there is more than just one
> single character appended, but when I do what you say you're doing I
> see the results which I expect.
>
> There are 68 characters in the original eicar file and 69 in the file
> which has the extra '=' character appened:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ diff eicar.orig eicar.single_character_appended
> 1c1
> < X5O!P%@AP[.4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
> \ No newline at end of file
> ---
> > X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> \ No newline at end of file
> ged@pi4b530214:~ $
> 8<----------------------------------------------------------------------
>
> The harness tells me that it has sent 68 characters from the file to
> clamd when I send the original eicar file, and 69 characters when it
> sends the modified file. This gives me confidence that it's sent what
> I think it's sent.
>
> Here is the output that I see from my little harness for the original:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ ./tempscan.pl eicar.orig
> filename=[eicar.orig]
> Sent [68] bytes to clamd...
> REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> 8<----------------------------------------------------------------------
>
> Here it is for the modified file:
>
> 8<----------------------------------------------------------------------
> ged@pi4b530214:~ $ ./tempscan.pl eicar.single_character_appended
> filename=[eicar.single_character_appended]
> Sent [69] bytes to clamd...
> REPLY IS [stream: {HEX}EICAR.TEST.3.UNOFFICIAL FOUND]
> 8<----------------------------------------------------------------------
>
> I don't think the difference in behaviour would be explained by the
> fact that you're using Windows - but I was wrong before, once. :)
>
> Perhaps you can post the output of 'clamconf -n' and the source of the
> program that you're using to send the file if it's reasonably compact.
> The executable wouldn't be much use to me, although I could spin up a
> VM if absolutely necessary.
>
> If you have Perl on your computer you might want to try this script; I
> hope your mail client doesn't mangle the lines too much, there are 47
> lines in the script.
>
> 8<----------------------------------------------------------------------
> File name: tempscan.pl
> 8<----------------------------------------------------------------------
> #!/usr/bin/perl
> # Send a file to clamd.
> # usage: tempscan.pl <filename>
> use strict;
> use IO::Socket;
> use File::Slurp;
> # Make sure the IP address and port number suit your clamd setup!
> my $peer_addr = '127.0.0.1';
> my $peer_port = '3310';
> my $filename = $ARGV[0];
> printf( "filename=[$filename]\n" );
> my $clam1;
> if( ! ($clam1 =
> IO::Socket::INET->new(Proto=>"tcp",PeerAddr=>$peer_addr,PeerPort=>$peer_port)))
> {
> printf( 'Failed to connect to ClamAV daemon on [%s:%s]', $peer_addr,
> $peer_port );
> exit;
> }
> my $remaining = read_file( $filename );
> my $part_length = length($remaining);
> print $clam1 "nINSTREAM\n";
> while( $remaining ) # Send in chunks, maximum 65535 bytes
> per chunk.
> {
> my $chunk = substr( $remaining, 0, 65_535, '' ) ;
> my $chunk_length = pack( 'N', length( $chunk ) );
> print( $clam1 $chunk_length . $chunk );
> printf( "Sent [%d] bytes to clamd...\n", length($chunk) );
> }
> my $terminator = pack( 'N', 0 );
> print $clam1 $terminator,"\n"; # The terminating null for the data.
> my $reply_timeout = 10_000;
> my $reply = '';
> while( !$reply && $reply_timeout )
> {
> if( ! ($reply = <$clam1>) )
> {
> usleep( 1_000_000 );
> $reply_timeout--;
> if( ! $reply_timeout )
> {
> print( "TIMEOUT waiting for response from clamd\n" );
> $reply = 'TIMEOUT';
> }
> }
> }
> close $clam1;
> chomp $reply;
> printf( "REPLY IS [%s]\n", $reply );
> 8<----------------------------------------------------------------------
>
> HTH
>
> --
>
> 73,
> Ged.
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

Jorge Elissalde via clamav-users wrote:
> Thank you for your answer.
> I'm using Windows clamd release 0.104.2
> I have double checked with wireshark and the data sent is ok.
>
> suppose I just send: char *eicarTest =
> "X5O!P%@AP[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*"
> Result is ok: instream(local):
> Win.Test.EICAR_HDB-1(44d88612fea8a8f36de82e1278abb02f:68) FOUND
>
> then I send: char *eicarTest =
> "X5O!P%@AP[.4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*hjyhj"
> (5 more characters)
> Result is not ok: instream(local): OK
>
> Perhaps Windows Clamd release works differently than Linux release?

This got me curious, because this is the canonical test "virus" (does
this actually still run on modern Windows?) that should be detected by
any AV software in existence. I started wondering if the official stock
Eicar signatures were hash signatures instead of one of the
pattern-based types.

And so they are:

kdeugau@ele:$ sigtool --find-sigs Eicar
[daily.mdu] 45056:3ea7d00dedd30bcdf46191358c36ffa4:Eicar-Test-Signature
[daily.msb]
45056:f9b304ced34fcce3ab75c6dc58ad59e4d62177ffed35494f79f09bc4e8986c16:Eicar-Test-Signature
[daily.hsb]
275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f:68:Eicar-Test-Signature
[daily.hsu]
275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f:68:Eicar-Test-Signature
[daily.hdu] 44d88612fea8a8f36de82e1278abb02f:68:Eicar-Test-Signature
[daily.msu]
45056:f9b304ced34fcce3ab75c6dc58ad59e4d62177ffed35494f79f09bc4e8986c16:Eicar-Test-Signature
[daily.ldb]
Win.Dropper.Eicar-9892650-0;Engine:106-255,Target:1;0&1&2;4d535642564d{2}2e444c4c::i;56423521f01f{28}0a00{16}00f0300000ffffff08000000010000000100;499257354f8ce4499f7d1f926dd38d28
[daily.hdb] 44d88612fea8a8f36de82e1278abb02f:68:Eicar-Test-Signature
[daily.mdb] 45056:3ea7d00dedd30bcdf46191358c36ffa4:Eicar-Test-Signature
[daily.mdb] 15872:2cc59e79e957c0fd8068e1bac52137bc:Win.Trojan.Eicartest-1
[6327695.cbc BYTECODE]
Eicar-Signature.{};Engine:56-255,Target:0;0;0:58354f2150254041505b345c505a58353428505e2937434329377d2445494341522d5354414e444152442d414e544956495255532d544553542d46494c452124482b482a
[main.mdb] 2560:db9db3a5cf0ba0e644ad04792e02fbcd:Win.Trojan.Eicar-1

kdeugau@ele:$ sigtool --find-sigs EICAR
[daily.ldb]
Win.Tool.EICAR-9917185-0;Engine:51-255,Target:1;0&1&2&3&4;466f72206d6f726520736563757269747920666561747572652074657374732c20706c656173652076697369743a20687474703a2f2f7777772e616d74736f2e6f72672f666561747572652d73657474696e67732d636865636b2e68746d6c20;496e206361736520796f752065786563757465642074686973206170706c69636174696f6e20776974686f75742067657474696e6720616e7920616c6572742c20646574656374696f6e206f66205055412028506f74656e7469616c6c7920556e77616e746564204170706c69636174696f6e7329206973206e6f7420656e61;497320746865726520616e7920726561736f6e2c20776879206e6f7420636c6f7365207468652077696e646f773f;492077696c6c207265616c6c7920636c6f7365207468652077696e646f77206e6f772e;446f20796f752077616e7420746f20636c6f736520746869732077696e646f773f
[main.hdb] 44d88612fea8a8f36de82e1278abb02f:68:Win.Test.EICAR_HDB-1
[main.msb]
45056:f9b304ced34fcce3ab75c6dc58ad59e4d62177ffed35494f79f09bc4e8986c16:Win.Test.EICAR_MSB-1
[main.mdb] 45056:3ea7d00dedd30bcdf46191358c36ffa4:Win.Test.EICAR_MDB-1
[main.hsb]
275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f:68:Win.Test.EICAR_HSB-1


There are quite the proliferation of hash signatures, but by definition
those will only ever match the exact file - ie, a file or stream
consisting of the exact 68 bytes in eicar.com. The only one that would
match within a larger file or datastream is the bytecode signature
Eicar-Signature.{} (second from the bottom in the first set).

Check if you have bytecode signatures disabled in your Windows clamd
instance.

-kgd

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

On Wed, 2 Mar 2022 12:35:40 -0300
Jorge Elissalde via clamav-users <clamav-users@lists.clamav.net> wrote:

> Hi,
>
> I'm using clamd to make a large data scanning using INSTREAM (data it
> is not available as files I could send to clamd). If I send only one
> INSTREAM chunk with EICAR inside it is correctly detected, but if I
> send several chunks plus EICAR string, it is not detected.

> Does it make any sense? I will appreciate any help.

You miss the most important point. Eicar test file is very strictly
defined at https://www.eicar.org/?page_id=3950 - it very clearly
defines which extra characters are allowed after 68 characters string.

"The first 68 characters is the known string. It may be optionally
appended by any combination of whitespace characters with the total
file length not exceeding 128 characters. The only whitespace
characters allowed are the space character, tab, LF, CR, CTRL-Z. To
keep things simple the file uses only upper case letters, digits and
punctuation marks, and does not include spaces. The only thing to watch
out for when typing in the test file is that the third character is the
capital letter „O“, not the digit zero."

--
Tuomo Soini <tis@foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

Hi there,

On Thu, 3 Mar 2022, G.W. Haywood wrote:

> ... Perhaps you can post the output of 'clamconf -n' ...

On Thu, 3 Mar 2022, Kris Deugau wrote:

> ...
> There are quite the proliferation of hash signatures, but ...
> The only one that would match within a larger
> file or datastream is the bytecode signature Eicar-Signature.{}
> ...
> Check if you have bytecode signatures disabled ...

Good catch Kris. This has me wondering - does some equivalent of

'clamconf -n'

exist in the Windows versions of ClamAV?

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

On Thu, 3 Mar 2022 11:02:36 +0000 (GMT)
"G.W. Haywood via clamav-users" <clamav-users@lists.clamav.net> wrote:

> Hi there,
>
> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>
> > I have made another test using clamdscan.
> > If I scan a file with just the EICAR string the detection is fine.
> > If I modify that file adding a single character, the detection fails.
> >
> > clamdscan file ( file content: X5O!P%@AP
> > [4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
> > Infected files: 1
> >
> > clamdscan file ( file content:
> > X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
> > )
> > Infected files: 0
> >
> > (second test has a '=' added at the end)
>
> It seems to me that in your second test there is more than just one
> single character appended, but when I do what you say you're doing I
> see the results which I expect.
>
> There are 68 characters in the original eicar file and 69 in the file
> which has the extra '=' character appened:



A trailing '=' and changing the length from 68 to 69 is what base64 encoding does, since it works in multiples of 3 bytes and pads with trailing '='s.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

Hi,

The weird part is that Avira and other Antivirus correctly are able to
detect EICAR in any case, having other characters before and/or after the
EICAR string.
Thank you,




El jue, 3 mar 2022 a las 12:27, Tuomo Soini via clamav-users (<
clamav-users@lists.clamav.net>) escribió:

> On Wed, 2 Mar 2022 12:35:40 -0300
> Jorge Elissalde via clamav-users <clamav-users@lists.clamav.net> wrote:
>
> > Hi,
> >
> > I'm using clamd to make a large data scanning using INSTREAM (data it
> > is not available as files I could send to clamd). If I send only one
> > INSTREAM chunk with EICAR inside it is correctly detected, but if I
> > send several chunks plus EICAR string, it is not detected.
>
> > Does it make any sense? I will appreciate any help.
>
> You miss the most important point. Eicar test file is very strictly
> defined at https://www.eicar.org/?page_id=3950 - it very clearly
> defines which extra characters are allowed after 68 characters string.
>
> "The first 68 characters is the known string. It may be optionally
> appended by any combination of whitespace characters with the total
> file length not exceeding 128 characters. The only whitespace
> characters allowed are the space character, tab, LF, CR, CTRL-Z. To
> keep things simple the file uses only upper case letters, digits and
> punctuation marks, and does not include spaces. The only thing to watch
> out for when typing in the test file is that the third character is the
> capital letter „O“, not the digit zero."
>
> --
> Tuomo Soini <tis@foobar.fi>
> Foobar Linux services
> +358 40 5240030
> Foobar Oy <https://foobar.fi/>
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml
>

On Thu, 3 Mar 2022 22:50:04 -0300
Jorge Elissalde via clamav-users <clamav-users@lists.clamav.net> wrote:

> Hi,
>
> The weird part is that Avira and other Antivirus correctly are able to
> detect EICAR in any case, having other characters before and/or after
> the EICAR string.

That is incorrectly detecting it. They must not detect signature in the
middle. That's clearly in specification. Long time ago there was big
discussion about eicar detection and at that time ClamAV got fixed not
to incorrectly detect eicar signature in the middle of other data.

--
Tuomo Soini <tis@foobar.fi>
Foobar Linux services
+358 40 5240030
Foobar Oy <https://foobar.fi/>

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

On Thu, 3 Mar 2022, Paul Kosinski via clamav-users wrote:

> On Thu, 3 Mar 2022 11:02:36 +0000 (GMT)
> "G.W. Haywood via clamav-users" <clamav-users@lists.clamav.net> wrote:
>
>> Hi there,
>>
>> On Wed, 2 Mar 2022, Jorge Elissalde via clamav-users wrote:
>>
>>> I have made another test using clamdscan.
>>> If I scan a file with just the EICAR string the detection is fine.
>>> If I modify that file adding a single character, the detection fails.
>>>
>>> clamdscan file ( file content: X5O!P%@AP
>>> [4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*)
>>> Infected files: 1
>>>
>>> clamdscan file ( file content:
>>> X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=
>>> )
>>> Infected files: 0
>>>
>>> (second test has a '=' added at the end)
>>
>> It seems to me that in your second test there is more than just one
>> single character appended, but when I do what you say you're doing I
>> see the results which I expect.
>>
>> There are 68 characters in the original eicar file and 69 in the file
>> which has the extra '=' character appened:
>
> A trailing '=' and changing the length from 68 to 69 is what base64
> encoding does, since it works in multiples of 3 bytes and pads with
> trailing '='s.

Which base64 implementation are you using ?

Ubuntu21.10# cat ~/viruses/eicar.com.txt
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Ubuntu21.10# base64 ~/viruses/eicar.com.txt | base64 -d
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*
Ubuntu21.10# base64 ~/viruses/eicar.com.txt | base64 -d | diff - ~/viruses/eicar.com.txt | wc
0 0 0

Ubuntu21.10# echo $(cat ~/viruses/eicar.com.txt)"=" | base64 | base64 -d
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*=

... But as I say in another email, it is unusual for the EOF to be a
necessary part of any malware.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

On Fri, 4 Mar 2022, Tuomo Soini via clamav-users wrote:

> On Thu, 3 Mar 2022 22:50:04 -0300
> Jorge Elissalde via clamav-users <clamav-users@lists.clamav.net> wrote:
>
>> Hi,
>>
>> The weird part is that Avira and other Antivirus correctly are able to
>> detect EICAR in any case, having other characters before and/or after
>> the EICAR string.
>
> That is incorrectly detecting it. They must not detect signature in the
> middle. That's clearly in specification. Long time ago there was big
> discussion about eicar detection and at that time ClamAV got fixed not
> to incorrectly detect eicar signature in the middle of other data.

If that particular string of characters appears in the middle of a stream
it may not be "The EICAR virus" but it should be detected as, say
"potentially malicious".

Yes, malware which is defeated when it is not terminated by EOF might
exist (if it exploits a bug in the EOF-handling code, for example).
However something which is executed is likely to have done its damage
before the EOF is processed.

Clamd should detect signatures whether or not they are at the end of the
"file". False positives are undesireble but still better than false
negatives.

--
Andrew C. Aitchison Kendal, UK
andrew@aitchison.me.uk

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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

Hi there,

Sorry, I should have spent more time looking into this.

On Fri, 4 Mar 2022, Tuomo Soini via clamav-users wrote:

> That is incorrectly detecting it. They must not detect signature in the
> middle. That's clearly in specification. Long time ago there was big
> discussion about eicar detection and at that time ClamAV got fixed not
> to incorrectly detect eicar signature in the middle of other data.

The above is correct.

Among the third-party databases used here there's one called 'RFXN'.

This is part of 'Linux Malware Detect'

https://github.com/rfxn/linux-malware-detect

and was installed here by 'clamav-unofficial-sigs'

https://github.com/extremeshok/clamav-unofficial-sigs

8<----------------------------------------------------------------------
$ ls -l /EXPORTS/clamav/databases/rfxn*
-rw-r--r-- 1 clamav clamav 410441 Aug 17 2020 rfxn.yara
-rw-r--r-- 1 clamav clamav 451958 Mar 31 2021 rfxn.ndb
-rw-r--r-- 1 clamav clamav 866954 Feb 25 06:17 rfxn.hdb
8<----------------------------------------------------------------------

The signature which is detecting the modified EICAR string is in the
file 'rfxn.ndb':

{HEX}EICAR.TEST.3:0:*:58354f2150254041505b345c505a58353428505e2937434329377d2445494341522d5354414e444152442d414e544956495255532d544553542d46494c452124482b482a

This is a simple match of the 68-byte EICAR string. It fails to take
account of the EICAR specification change made in 2003 which requires
no detection by anti-virus products if anything other than a limited
number of what it calls 'whitespace' characters is appended to it.

In the RFXN signature there's no protection against detecting the
string within a string which contains non-whitespace characters.

I haven't dropped the signature here (I think this is the only time
it's detected anything) but it's clearly wrong. See for example
reference 7 at

https://en.wikipedia.org/wiki/EICAR_test_file

I've cc'd Mr. MacDonald at the address given on Github to inform him
of the erroneous match.

--

73,
Ged.

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net
https://lists.clamav.net/mailman/listinfo/clamav-users


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

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