Re: [Clamav-devel] OSX resource forks

[Mark Allan]

Hi Gavin (and list),
I'm nearly finished a GUI for Clamav, the only thing I really have left 
to do is stress testing and documentation.

I've made a few changes to the source code which I plan to release in 
due course, in order to make it work with resource forkshowever, 
like you, I don't have access to any test viruses.  The closest I got 
was about 4 years ago when I actually got a virus, but Disinfectant 
took care of that for me.  Bit annoying now though, I could do with 
having it back!!!

I hope to have my program available to others by the end of this week.  
I'll keep you posted if you like?

Also, it's not completely useless for Mac users just cos it didn't scan 
resource forks.  I still get emails from windoze-using friends 
containing viruses (the emails, not the friends!) so it's worthwhile 
checking my attachments folder if not for my own peace of mind, then at 
least I can tell my friends they need to update their virus checker.

Anyway, I'm wasting coding/testing time here!!
Mark
On 4 Aug 2004, at 1:00 pm, Gavin Aiken wrote:
Apologies if this is the wrong place to ask this but it seemed more of 
a
development question than a user one.

I have been testing clamav on OSX and noticed that it does not scan Mac
resource forks, only data forks - which is to be expected as it is a
unix-level port, and most of the ways to get at resource forks are
presumably in different file access API's (carbon/cocoa?).
Several questions arise from that:
1. Does anyone have any plans to add this ability? I think I am right 
in
saying that it could be as simple as scanning file/rsrc as well as 
file
on OSX systems. This could be included by an #ifdef at compile time 
maybe?

2. I don't think any of the classic old Mac resource viruses (MDBF, 
MDEF
etc) are in the clamav virus db. Does anyone have access to these for
testing purposes, and to get signatures for them? If not, how could 
one go
about making sure this worked?

3. I saw on the user list that someone had created an AppleScript 
studio gui
front-end for OSX to run clamav. I was looking for one because I was
considering writing one myself in fact! I would think that without 
resource
fork scanning that clamav would be reasonably useless on Mac. Anyone 
have
any further thoughts or opinions on that? Should there be something in 
the
documentation explaining to OSX users that it probably isn't a good
replacement for Virex etc, at least not yet!?

regards,
Gavin

Mark Allan
IT Support
George Watson's College
W: www.gwc.org.uk
E: [EMAIL PROTECTED]
P: +44 (0)131 446 6070

---
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
___
Clamav-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-devel

[Clamav-devel] clamXav available now (Mac OS X)

[Mark Allan]

Hi all,
I've finally bitten the bullet and released my clamav GUI for Mac OS X.
It's called clamXav, and you can download it from 
http://www.markallan.co.uk/clamXav_v0.8b.zip or from the program info 
page at http://www.markallan.co.uk/clamXav (no trailing slash please, 
it messes up my redirection to the real page!)

As I say when you run the application, having a standard build of 
clamav installed is not sufficient to run my GUI, purely because of the 
changes I made to the source code (see previous emails titled OS X 
resource forks).  With clamXav, I've distributed a pre-built binary 
which includes my modifications but I've also included instructions for 
users telling them where to download the source from clamav.net and how 
to patch it themselves with my mods if they'd prefer.

From what I understand, this is in-keeping with the GPL.  If it's not, 
please let me know so that I can change things.  However, if I'm not 
allowed to do it this way, then I'll need some time to apply my patches 
to the main clamav source tree and I don't know how the changes will 
affect others.  Obviously, having my patches officially in the main 
source code would be preferable, but I don't know how to go about this.

Currently, it's only a front end to clamscan and freshclam, but I may 
extend this to the other programs in the clamav suite in due course if 
there are enough requestsI'll have to figure out what the other 
parts do first though!! ;-)

Ideally, I'd like to be able to say watch this folder and scan any new 
items.  Does that function exist yet or do I have to fiddle around 
with AppleScript and FolderActions?

Anyway, I'd appreciate it if any OS X users on this list would download 
clamXav and try it please.  Let me know what you think.

Thanks,
Mark
PS. It's here: http://www.markallan.co.uk/clamXav_v0.8b.zip

---
This SF.Net email is sponsored by BEA Weblogic Workshop
FREE Java Enterprise J2EE developer tools!
Get your free copy of BEA WebLogic Workshop 8.1 today.
http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click
___
Clamav-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-devel

[Clamav-devel] Option for dummy scan? Option to skip specific file?

[Mark Allan]

Hi,
I'm developing clamXav (clamav GUI for Mac OS X) and I was wondering 
two things:

Firstly, could we add an option for a dummy scan?  What I mean is to 
have clamscan goes through the process of what it would normally do, 
but not actually perform any scanning?  Basically what I'm after is a 
total number of files/directories to be scanned (un-archiving wouldn't 
be necessary) so that I can provide a progress indicator.

Secondly, is there any option to skip a specific file once it has 
started being scanned?  I know clamscan isn't really designed to be 
interactive, but a key-stroke could allow the user to avoid scanning a 
file which appears to be taking forever.  Maybe control-D or control-X 
or something could abort the current file and just move on to the next 
file due to be scanned.

Any thoughts?
Mark

---
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
___
Clamav-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/clamav-devel

Re: [Clamav-devel] PATCH: improvements for Mac OS X/clamXav

[Mark Allan]

D'oh!  I didn't realise .80rc4 was out.  I wrote that email a couple of 
days ago and only just got round to sending it!

Sorry.
On 11 Oct 2004, at 11:35 pm, Tomasz Kojm wrote:
On Mon, 11 Oct 2004 23:32:12 +0100
Mark Allan [EMAIL PROTECTED] wrote:
Hi guys,
With the release of 8.0 imminent, can I ask again why the OS X
resource fork patch has not made it in yet?
We know it works, so I'm a bit confused.  I don't mean to moan, I'm
just surprised not to see it accepted yet.
The change has been included in 0.80rc4.
--
   oo. Tomasz Kojm [EMAIL PROTECTED]
  (\/)\. http://www.ClamAV.net/gpg/tkojm.gpg
 \..._ 0DCA5A08407D5288279DB43454822DC8985A444B
   //\   /\  Tue Oct 12 00:35:00 CEST 2004
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel
___
http://lists.clamav.net/cgi-bin/mailman/listinfo/clamav-devel

[Clamav-devel] Complex Regular Expressions

[Mark Allan]

Having searched the archives to the best of my abilities, I can't  
seem to find an answer to why complex regular expressions are not  
enabled for ClamAV.  Can anyone shed any light on this please?  It  
*appears* to work fine on OS X 10.3 and 10.4 so I'm wondering if it's  
the other Unix variants which are having problems or is there some  
other reason?


Thanks
Mark
--
Author of ClamXav for Mac OS X
http://www.clamxav.com
___
http://lurker.clamav.net/list/clamav-devel.html

[Clamav-devel] Vulnerability with using ditto on OS X

[Mark Allan]

As there is no date to show when this article was written, I'm not  
sure if it takes into account 0.85.1  Can anyone comment?


http://www.securityfocus.com/bid/13795/discussion/

Thanks,
Mark


Article contents:

Clam Anti-Virus ClamAV running on Mac OS X is affected by a command  
execution vulnerability.


Reportedly, when a suspected infected file is handled by the  
application and it cannot be removed, the application may attempt to  
copy it to another location using the Mac OS X 'ditto' utility. The  
'ditto' utility is called in an insecure manner and the responsible  
function fails to sanitize the file name allowing an attacker to  
include arbitrary commands in the file name that will be executed in  
the context of ClamAV.


This can allow an attacker to gain unauthorized access to an affected  
computer. It should be noted that the exploitation of vulnerability  
is only possible when a malicious file is copied.


ClamAV versions 0.80rc4 to 0.84rc2 to are affected by this issue.
___
http://lurker.clamav.net/list/clamav-devel.html

Re: [Clamav-devel] Vulnerability with using ditto on OS X

[Mark Allan]

Take a look at the FIRST line.  I said I don't know when the article  
was written - it may have been before 0.85.1 and maybe even before 0.84!


On 28 May 2005, at 11:15 pm, Jakub Jankowski wrote:

Take a look at the last line you've pasted:

___
http://lurker.clamav.net/list/clamav-devel.html

Re: [Clamav-devel] Vulnerability with using ditto on OS X

[Mark Allan]

On 28 May 2005, at 11:25 pm, Jakub Jankowski wrote:

http://www.securityfocus.com/bid/13795

quote
not vulnerable  Clam Anti-Virus ClamAV 0.84
Clam Anti-Virus ClamAV 0.85
Clam Anti-Virus ClamAV 0.85.1
/quote


Ok, now I feel stupid - I never even noticed that menu bar!  :-(

Thanks


PS. Top-posting is bad.


Not something I've heard before, but point taken.
___
http://lurker.clamav.net/list/clamav-devel.html

Re: [Clamav-devel] Re: [Patch] Progress Indicator for DB Updates

[Mark Allan]

What ever happened to this feature?  I'd really like to use it,  
especially in my GUI front end, but with 0.88.2 I'm still getting the  
rotating pipe character.


Thanks,
Mark

On 8 Mar 2006, at 13:29pm, Tomasz Kojm wrote:


On Thu, 2 Feb 2006 18:20:19 +
Robert Hogan [EMAIL PROTECTED] wrote:


On Wednesday 01 February 2006 23:09, Robert Hogan wrote:
This feature-request in the form of a very basic patch replaces  
the rotor
with a percentage indicator if the content-length of the db is  
greater

than 0.

Would such a feature be acceptable? It would be really handy for
front-ends, and might even appeal to other users.

thanks,
robert


looks like the list is still scrubbing attachments that aren't
content-type'd text/plain. either that or Mailman knows a dodgy  
patch when

he sees it...


Nice thing, patch applied in CVS. Thank you!

--
   oo. Tomasz Kojm [EMAIL PROTECTED]
  (\/)\. http://www.ClamAV.net/gpg/tkojm.gpg
 \..._ 0DCA5A08407D5288279DB43454822DC8985A444B
   //\   /\  Wed Mar  8 14:28:19 CET 2006
___
http://lurker.clamav.net/list/clamav-devel.html


___
http://lurker.clamav.net/list/clamav-devel.html

[Clamav-devel] Using clamd with --exclude or --include settings

[Mark Allan]

Hi,

Is there a reason for clamd not supporting the include, exclude and  
exclude-dir options?  I've tried adding them as switches to clamdscan  
but I get a message back saying:

WARNING: Ignoring option --exclude: please edit clamd.conf instead

So I then tried editing clamd.conf but can see no option for include/ 
exclude (other than clamuko which can't be used).  Simply adding  
exclude PATTERN to clamd.conf doesn't work either as I then get the  
following error when I launch clamd:

ERROR: Parse error at line 6: Unknown option exclude.
ERROR: Can't parse the configuration file.

Have I missed something or does the option just not exist for clamd/ 
clamdscan?  I'd rather not have to use the standalone clamscan if I  
can help it, especially since v0.90 added support for MP.


Many thanks

Mark
___
http://lurker.clamav.net/list/clamav-devel.html

[Clamav-devel] Configure patch for OS X 10.5 Leopard

[Mark Allan]

Hi folks,

Here's a patch to allow ClamAV to configure properly on Mac OS X  
10.5.  The nidump tool was deprecated a long time ago and is no longer  
included in 10.5 as netinfo doesn't exist any more.  The dscl tool is  
the preferred method from at least 10.3 onwards.  Unfortunately I  
don't have any machines with 10.2 on which I can test to see if it  
works there too.

The patch is against the release version of ClamAV 0.92 and doesn't  
check which Mac OS version is in use, I've simply replaced the nidump  
call with the correct dscl call.  FWIW, 10.2 is almost 6 years old now  
so I doubt very much if anyone is still running it.

The second part of the patch delays endian checking until compile-time  
to permit cross-compiling for PPC and i386 architectures within the  
same binaries.

Mark

[~/Desktop/clamav_0.92]  diff -Naur configureOrig configure

--- configureOrig   2008-02-08 21:38:58.0 +
+++ configure   2008-02-08 21:53:43.0 +
@@ -25400,8 +25400,8 @@
  then
{ echo $as_me:$LINENO: checking for $clamav_user using netinfo 5
  echo $ECHO_N checking for $clamav_user using netinfo... $ECHO_C  
 6; }
-clamavuser=`/usr/bin/nidump passwd . |grep ${clamav_user}`
-clamavgroup=`/usr/bin/nidump group . |grep ${clamav_group}`
+clamavuser=`/usr/bin/dscl . -list /Users | grep ${clamav_user}`
+clamavgroup=`/usr/bin/dscl . -list /Groups | grep $ 
{clamav_group}`
  fi

  if test $use_yp = yes
@@ -25827,7 +25827,7 @@
yes)

  cat confdefs.h \_ACEOF
-#define WORDS_BIGENDIAN 1
+#define WORDS_BIGENDIAN (defined(__BIG_ENDIAN__)  __BIG_ENDIAN__)
  _ACEOF
   ;;
no)
@@ -25843,13 +25843,13 @@
  if test $ac_cv_c_bigendian = yes; then

  cat confdefs.h \_ACEOF
-#define WORDS_BIGENDIAN 1
+#define WORDS_BIGENDIAN (defined(__BIG_ENDIAN__)  __BIG_ENDIAN__)
  _ACEOF

  else

  cat confdefs.h \_ACEOF
-#define WORDS_BIGENDIAN 0
+#define WORDS_BIGENDIAN (defined(__BIG_ENDIAN__)  __BIG_ENDIAN__)
  _ACEOF

  fi


___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] PATCH: Enhanced exclude / include support for clamscan

[Mark Allan]

 The regular expressions being excluded or included are compiled  
 just once and stored in memory


Brilliant!

 On the one hand, you're right that were clamscan to have a command- 
 line option to tell it to read a list of files on stdin, the logic I  
 built into it could be implemented externally, either with home- 
 grown scripts or with a separate utility bundled with clamav.  I  
 certainly wouldn't be adverse to achieving my goal that way, where  
 that functionality to be provided by clamscan.

I think this way would be much better than changing the interface, and  
would have the added benefit of being significantly more powerful than  
you probably realise.  If we could supply a list of files either on  
stdin or within a single text file passed on the command line with eg.  
a -f flag, users and admins could incorporate ClamAV into scripts/ 
tasks and automated jobs a lot more easily than is currently  
possible.  It would also eliminate another issue I've had to work  
around which is the lack of case-insensitive regex matching - I could  
perform my own matching and just supply filenames within a temporary  
file or via stdin.

 Other applications in the same genre with similar functionality  
 include rsync, rdiff-backup, and GNU tar.  All of those, like  
 clamscan, could force the user to implement exclude / include  
 functionality externally and then feed a file list into the  
 application, and yet all of them provide complex, flexible built-in  
 filtering functionality of their own.

Indeed.  I don't think anyone's suggesting that the existing  
functionality be removed.

 Perhaps what is needed is a compromise -- basic filtering of the  
 sort I implemented, *plus* the -f flag (or the equivalent) for  
 people who want to roll their own logic?

In my opinion, that would be an ideal solution.

 Interfaces change.  Such is life.  Remaining wedded to broken  
 interfaces leads over time to difficult to maintain code with  
 inferior functionality and performance.  The changes should be  
 visibly documented, and people who are using ClamAV should be smart  
 enough to read the release notes when they upgrade.

The problem isn't with changing the interface, the problem is that  
your solution doesn't actually change the interface, it changes the  
implementation - you've just placed extra importance on the order of  
the items, which wasn't there before.  This could have the subtle  
effect of still appearing to work, but no longer doing what the user  
expected.  Files which should be scanned may end up getting missed and  
the user might not realise.  If the interface actually changes, then  
that's not such a big deal as it will simply and very obviously break  
any existing procedures a user has set up, and they'll have no choice  
but to change how they work.

Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] Adding targets for the bytecode interpreter

[Mark Allan]

On 17 May 2010, at 7:32 pm, Török Edwin wrote:
A real fix would be to detect the Apple-style universal build  
(configure

does this already), and build both ppc and x86 then.
If you open a bugreport I'll try to do that for 0.96.2.


OK, filed as bug 2030.  https://wwws.clamav.net/bugzilla/show_bug.cgi?id=2030

Thanks very much for the explanation and the --enable-all-jit-targets  
fix in the meantime.


Mark
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] [clamav-users] Flashback

[Mark Allan]

Hi Don,

This is the mailing list for ClamAV - the separate software which does the 
actual malware scanning.

For information about developments in ClamXav, you should check the website at 
www.clamxav.com and the support forums at www.clamxav.com/support

Mark

On 11 Apr 2012, at 20:20, Don Montalvo wrote:

 Is there an RSS we can subscribe to so we can keep up to speed on ClamXav 
 changes?
 
 I have to admit, ClamXav is going become quite attractive to many people very 
 soon...
 
 Don
 
 On Apr 9, 2012, at 7:36 AM, Joel Esler wrote:
 
 Yes.  I've written protection for all the current versions of Flashback that 
 we know of.
 
 Cc'ed to the ClamAV-users list.
 
 On Apr 8, 2012, at 4:51 PM, Jeremy Neptune wrote:
 
 Does ClamAV detect the Flashback malware? I have an old Mac (running
 10.4.11) and running clamxav.
 
 Am I protected?
 
 If this is the wrong list, I'm sorry, and please direct me to the correct 
 one.

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] Introducing OpenSSL as a dependency to ClamAV

[Mark Allan]

Looks like relying on OpenSSL might cause problems for ClamAV on OS X.

Al (a regular contributor to this list) pointed me towards the following blog 
post

https://hynek.me/articles/apple-openssl-verification-surprises/

It explains some of the problems with Apple's installation of OpenSSL, and 
offers some workarounds.  Relying on homebrew or MacPorts isn't an option for 
me because I produce compiled pre-packaged installers for ClamAV on OS X; I 
provide these to the general public, so have to expect users to be running the 
standard Apple-supplied OpenSSL.

Can I ask you to consider one of the two code-level solutions proposed in that 
blog post please?  Presumably it would have to be implemented as a configure 
flag rather than for all Mac builds as I suspect some of the more advanced 
ClamAV users out there *will* have compiled their own OpenSSL.

Thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] 0.98.1 not compiling on OS/X Mavericks

[Mark Allan]

 It used to compile on OSX just fine as recently as a month ago.
 
 I haven't built from source manually in a while but it does 0.98.1 did
 build for me using MacPorts on Mavericks back in January. That was XCode 5
 but not 5.1. MacPorts builds with CFLAGS -O0.
 
 I can confirm that the update from xcode 5 to 5.1 broke the compilation
 on Mac OS X.
 
 Remi
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 
 
 Thanks for the research on this problem. I added this to our Bugzilla as
 bug # 10757 so we can track it.
 
 Dave R.
 
 --
 ---
 Dave Raynor
 Vulnerability Research Team
 
 
 This error is reported from upstream LLVM code. The LLVM team has made
 bigger changes to this header since this file was included in ClamAV, so I
 cannot simply apply changes from them or the patch impact increases beyond
 this file.
 
 The root problem is the handling of the iterators and templates in this one
 spot. In short, clang is checking something earlier than gcc, even though
 the type should be available in the end.
 
 Please try this candidate patch to the LoopInfo.h header.
 
 --- a/libclamav/c++/llvm/include/llvm/Analysis/LoopInfo.h
 +++ b/libclamav/c++/llvm/include/llvm/Analysis/LoopInfo.h
 @@ -814,8 +814,12 @@ public:
typedef GraphTraitsInverseBlockT*  InvBlockTraits;
 
// Add all of the predecessors of X to the end of the work stack...
 -TodoStack.insert(TodoStack.end(), InvBlockTraits::child_begin(X),
 - InvBlockTraits::child_end(X));
 +for (typename InvBlockTraits::ChildIteratorType PI =
 +  InvBlockTraits::child_begin(X), PE =
 InvBlockTraits::child_end(X);
 +  PI != PE; ++PI) {
 +  typename InvBlockTraits::NodeType *N = *PI;
 +  TodoStack.push_back(N);
 +}
  }
}
 
 Dealing with a larger LLVM upgrade is a task for a future release, but this
 should let you move forward under Xcode 5.1 in the near term.
 
 Let us know how it goes,
 
 Dave R.

Another workaround is to compile with support for older versions of OS X.  I 
routinely compile with support for OSX 10.6+ and was confused when I saw the 
original email as I compiled under 10.9.2 and Xcode 5.1 a couple of days ago 
without any issue.

Here's what I use to configure the build:

CFLAGS=-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.6 -arch x86_64 
CXXFLAGS=-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.6  -arch 
x86_64 ./configure --disable-dependency-tracking  --enable-llvm 
--enable-clamdtop --with-user=_clamav --with-group=_clamav 
--enable-all-jit-targets

If I get rid of mmacosx-version flag, the build fails.  If I set it to any 
valid value (e.g. 10.8), it works.

Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] enabling DMG and XAR support

[Mark Allan]

Just out of interest, did you test to see if it *actually* worked?

My configure output shows that dmg and xar are supported, but it doesn't 
actually detect the Eicar test file within a disk image.

configure: Summary of engine detection features
  autoit_ea06 : yes
  bzip2   : ok
  zlib: /usr
  unrar   : yes
  dmg and xar : yes, from /usr

When I create a new disk image, copy the Eicar test file in, and scan the dmg, 
it shows up as being clean.

 clamscan test.dmg 
 test.dmg: OK
 
 --- SCAN SUMMARY ---
 Known viruses: 3259558
 Engine version: 0.98.1
 Scanned directories: 0
 Scanned files: 1
 Infected files: 0
 Data scanned: 10.07 MB
 Data read: 10.02 MB (ratio 1.01:1)
 Time: 4.845 sec (0 m 4 s)

Does this work as expected for anyone else?

Mark

On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote:

 That worked, thanks! 
 
 On February 10, 2014 at 4:29:41 PM, Steven Morgan (smor...@sourcefire.com) 
 wrote:
 
 Rafael,  
 
 Probably all you need to do install libxmllibxml2-dev, which is used by  
 dmg and xar, then do your configure/make.
 
 Steve  
 
 
 On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.comwrote:
 
 
 Folks,  
 
 I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not  
 getting the new super awesome DMG and XAR file support:  
 
 configure: Summary of detected features follows
 OS : linux-gnu  
 pthreads : yes (-lpthread)  
 configure: Summary of miscellaneous features  
 check : no (auto)  
 fanotify : yes  
 fdpassing : 1  
 IPv6 : yes  
 configure: Summary of optional tools  
 clamdtop : (auto)  
 milter : yes (disabled)  
 configure: Summary of engine performance features)  
 release mode: yes  
 jit : yes (auto)
 mempool : yes  
 configure: Summary of engine detection features  
 autoit_ea06 : yes  
 bzip2 : ok  
 zlib : /usr  
 unrar : yes  
 dmg and xar : no  
 
 Am I missing a configure flag or third party library?  
 
 Thanks in advance,  
 
 - Rafael  
 
   
 scanii.com - the web friendly malware scanner!  
 ___
 http://lurker.clamav.net/list/clamav-devel.html  
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 ___
 http://lurker.clamav.net/list/clamav-devel.html  
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] enabling DMG and XAR support

[Mark Allan]

My test disk is indeed a raw image.  I've also tried read only as well as 
compressed, and nothing gets detected in any of those.

As you say, Disk Utility creates raw images by default, and while some software 
packagers do create UDIF formatted images, I suspect Disk Utility is the most 
common way of making disk images on OS X.

What would be required to provide full DMG support?

Also, is there a similar caveat for xar archives?  I've done a similar test for 
those and they slip by undetected as well.

xar -c -f new.xar DirWithManyKnownDetectedMalwareSamples

clamscan new.xar 
new.xar: OK

--- SCAN SUMMARY ---
Known viruses: 3259558
Engine version: 0.98.1
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.00 MB
Data read: 31.34 MB (ratio 0.00:1)
Time: 4.612 sec (0 m 4 s)

Mark

On 19 Mar 2014, at 15:43, David Raynor dray...@sourcefire.com wrote:

 DMG is an odd filetype, since there are really 2 or 3 different filetypes
 lumped into that category.
 
 What we have included in ClamAV 0.98.1 is scanning of UDIF format DMG
 files, which have a definitive trailer block and may have compressed
 sections.
 We have not yet included support for scanning raw disk format DMG files,
 which are nearly indistinguishable from disk dumps. No separate compression
 is allowed.
 
 So let me ask you this question. How did you create your DMG? Most software
 packagers create UDIF format to reduce the file size for downloads. Disk
 Utility and the hdiutil command can create a raw disk unless another format
 is checked.
 
 To find out what format your testfile is really in, you can use the
 imageinfo sub-command of hdiutil (e.g. hdiutil imageinfo yourfile.dmg).
 Then you can use the convert sub-command of hdiutil to switch the format.
 
 Hope this helps,
 
 Dave R.
 
 -- 
 ---
 Dave Raynor
 Vulnerability Research Team
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 
 On Wed, Mar 19, 2014 at 11:34 AM, Rafael Ferreira r...@uvasoftware.comwrote:
 
 Interesting... let me run some tests and get back to you.
 
 On Mar 19, 2014, at 8:33 AM, Mark Allan markjal...@gmail.com wrote:
 
 Just out of interest, did you test to see if it *actually* worked?
 
 My configure output shows that dmg and xar are supported, but it doesn't
 actually detect the Eicar test file within a disk image.
 
 configure: Summary of engine detection features
 autoit_ea06 : yes
 bzip2   : ok
 zlib: /usr
 unrar   : yes
 dmg and xar : yes, from /usr
 
 When I create a new disk image, copy the Eicar test file in, and scan
 the dmg, it shows up as being clean.
 
 clamscan test.dmg
 test.dmg: OK
 
 --- SCAN SUMMARY ---
 Known viruses: 3259558
 Engine version: 0.98.1
 Scanned directories: 0
 Scanned files: 1
 Infected files: 0
 Data scanned: 10.07 MB
 Data read: 10.02 MB (ratio 1.01:1)
 Time: 4.845 sec (0 m 4 s)
 
 Does this work as expected for anyone else?
 
 Mark
 
 On 10 Feb 2014, at 23:38, Rafael Ferreira r...@uvasoftware.com wrote:
 
 That worked, thanks!
 
 On February 10, 2014 at 4:29:41 PM, Steven Morgan (
 smor...@sourcefire.com) wrote:
 
 Rafael,
 
 Probably all you need to do install libxmllibxml2-dev, which is used by
 dmg and xar, then do your configure/make.
 
 Steve
 
 
 On Mon, Feb 10, 2014 at 6:05 PM, Rafael Ferreira r...@uvasoftware.com
 wrote:
 
 
 Folks,
 
 I'm compiling clamav 0.98.1 on Linux (Ubuntu 12.04 LTS) and I'm not
 getting the new super awesome DMG and XAR file support:
 
 configure: Summary of detected features follows
 OS : linux-gnu
 pthreads : yes (-lpthread)
 configure: Summary of miscellaneous features
 check : no (auto)
 fanotify : yes
 fdpassing : 1
 IPv6 : yes
 configure: Summary of optional tools
 clamdtop : (auto)
 milter : yes (disabled)
 configure: Summary of engine performance features)
 release mode: yes
 jit : yes (auto)
 mempool : yes
 configure: Summary of engine detection features
 autoit_ea06 : yes
 bzip2 : ok
 zlib : /usr
 unrar : yes
 dmg and xar : no
 
 Am I missing a configure flag or third party library?
 
 Thanks in advance,
 
 - Rafael
 
 
 scanii.com - the web friendly malware scanner!
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] enabling DMG and XAR support

[Mark Allan]

Sorry, I'm not sure if you're talking to me or Dale.  If you're talking to me, 
my testing was done two days ago using ClamAV 0.98.1

Mark

On 21 Mar 2014, at 13:16, Joel Esler (jesler) jes...@cisco.com wrote:

 DMG support was just added in the last version of ClamAV.  How long ago did 
 you do this testing?
 
 
 On Mar 20, 2014, at 8:22 PM, Dale Walsh d...@daleenterprise.com wrote:
 
 You did miss it but it's a two headed nail.
 
 PDF, DMG, XAR and RAR have had issues not recognizing the test viruses to 
 name just a couple that spring to mind that we've had trouble with and this 
 all started happening when the clang and crap entered the picture.
 
 I've worked with the developers in the past, once the build environment 
 dependancies changed and I was told I had to upgrade my OS and build tools 
 is when it was no longer possible to resolve these issues as the update 
 solely for the purpose of building ClamAV is not an option and I shouldn't 
 be forced to use someone else's built tool preferences just because they 
 have the luxury of updating on a whim or purely for bragging rights.
 
 It does not matter if my OS is dated, security patches are applied to the 
 build tools as they become available and this seems to satisfy all other 
 software that build from source except ClamAV.
 
 Having everything build with GCC 4.0 would allow me/us to re-deploy ClamAV 
 and contribute to the code base again (I have in the past) but the chances 
 of this are slim to non from what I recall because my OS and build tools are 
 dated and listening to rants about ancient and deprecated is nothing more 
 than someone spewing stupidity.
 
 The fact that I ensure all bugs and updates to the build tools are 
 fixed/added allows me to keep everything in harmony and there is no reason 
 to update anything to build a single software package when all other 
 software sources seem to be content with the existing build environment.
 
 If you wish to go off-list to continue the discussion I have no objections.
 
 
 -- Dale
 
 
 
 On Mar 20, 2014, at 16:35 PM, Joel Esler (jesler) wrote:
 
 Dale,
 
 Thanks for your email.  I’m not sure exactly what you are referring to.  
 Maybe I am missing a connection here or something, but the discussion was 
 around scanning DMG and XAR, which I think, if there’s a issue with, we’d 
 be more than happy to work with anyone to try and square away.
 
 You seem to be discussing a build issue, and you say that it’s a waste of 
 time.  When did you get the impression that working with the developers was 
 a waste of time?  If we’re not communicating well enough, we can fix that.  
 But I think the team is doing a good job of that judging by the amount of 
 complaints I have received since we took over the project from the old 
 ClamAV team.
 
 Please let me know if we need to take this offline and discuss or anything 
 I can do to help.
 
 --
 Joel Esler
 Open Source Manager
 Threat Intelligence Team Lead
 Vulnerability Research Team
 
 On Mar 20, 2014, at 3:55 PM, Dale Walsh 
 d...@daleenterprise.commailto:d...@daleenterprise.com wrote:
 
 Mark, this has been an issue for many versions along with a slew of others 
 things not working as expected.
 
 As much as I liked ClamAV, we've abandoned it as a mail solution shortly 
 after things stopped working correctly and they changed the required build 
 tools so you can no longer build it with GCC 3.3/4.0/4.1/4.2 and have a 
 fully functional app.
 
 Yes there are flags to get it to build but certain modules and features 
 don't build and making an incomplete and partially functional binary isn't 
 appealing.
 
 Advice on updating build tools is a waste of time as there is no reason to 
 update the build tools just to build ClamAV as it's the only one that has 
 this ridiculous built-tool requirement and only an idiot would tell me to 
 update.
 
 My thoughts on this is simple, if it doesn't build with the basic GNU GCC 
 compiler tools then it's seriously flawed and needs these other tools to 
 overcome the short-comings of poorly written/implemented code.
 
 When I say build, I mean build with full functionality so don't go off the 
 deep-end stating it builds, partial functionality may be acceptable to you 
 bhut it isn't to me.
 
 At this time, for personal use, I use the source code but repackage the 
 build environment to work with what I have and I'm comfortable with 
 submitting corrections and patches, too much focus and complaints on my 
 build tools so why waste my time.
 
 -- Dale
 
 On Mar 19, 2014, at 11:34 AM, Rafael Ferreira wrote:
 
 Interesting... let me run some tests and get back to you.
 
 On Mar 19, 2014, at 8:33 AM, Mark Allan 
 markjal...@gmail.commailto:markjal...@gmail.com wrote:
 
 Just out of interest, did you test to see if it *actually* worked?
 
 My configure output shows that dmg and xar are supported, but it doesn't 
 actually detect the Eicar test file within a disk image.
 
 configure: Summary of engine detection

[Clamav-devel] Release Candidates?

[Mark Allan]

Hi all,

Given the (as yet undisclosed) problems with 0.98.2 and its subsequent pulling, 
and the release of 0.98.3 which followed shortly thereafter and which also 
appears to be problematic for some, might it be worth considering reinstating 
Release Candidates again?

If an announcement had been made either via the blog or this mailing list, it 
would allow people to test and find these issues before they hit the general 
public.

Just a thought.  Not sure what anyone else thinks about this, or why the RC 
announcements/builds stopped in the first place.

Cheers,
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] Release Candidates?

[Mark Allan]

Hi Joel,

I fully understand the frustration of sending out beta/RC builds for testing, 
receiving no feedback, and then getting bug reports *after* release.  It 
happens to me as well, so I simply don't do the RC thing for smaller releases, 
but I do for the bigger updates - and I think including a new reliance on a 3rd 
party library would probably count as a bigger update.

Now, I know I can checkout the current git code and test that, but I'm 
certainly not going to do that on a regular basis, just on spec that a release 
might be around the corner.

If RCs were to be announced, I would definitely download it to test.  When I 
build ClamAV, I usually do it for distribution, so I currently run my own tests 
against OS X 10.6, 10.7, 10.8, and 10.9.  I would be happy to include a test 
suite of your own as well.

For what it's worth 'make check' only ever runs 6 tests for me - all 6 pass, 7 
get skipped.  Is there a more thorough integration test I could run for you?

Mark

On 9 May 2014, at 01:36 pm, Joel Esler (jesler) jes...@cisco.com wrote:

 Mark,
 
 We found an internal issue with only the Windows build of ClamAV containing 
 some debug code in a certain situation, so we had to correct that.
 
 We used to do RCs for ClamAV, but we rarely heard any feedback during the RC, 
 and then we’d get bug reports when we did the actual release.
 
 If we could get a dedicated group of people to commit to testing an RC/Beta, 
 etc, we could start doing it again.
 
 --
 Joel Esler
 Open Source Manager
 Threat Intelligence Team Lead
 Vulnerability Research Team
 
 On May 8, 2014, at 12:30 PM, Mark Allan 
 markjal...@gmail.commailto:markjal...@gmail.com wrote:
 
 Hi all,
 
 Given the (as yet undisclosed) problems with 0.98.2 and its subsequent 
 pulling, and the release of 0.98.3 which followed shortly thereafter and 
 which also appears to be problematic for some, might it be worth considering 
 reinstating Release Candidates again?
 
 If an announcement had been made either via the blog or this mailing list, it 
 would allow people to test and find these issues before they hit the general 
 public.
 
 Just a thought.  Not sure what anyone else thinks about this, or why the RC 
 announcements/builds stopped in the first place.
 
 Cheers,
 Mark
 
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net
 
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] ClamAV®: ClamAV 0.98.4rc1 is now available!

[Mark Allan]

All works fine for me on OS X 10.6 - 10.9.

For info, compiled on 10.9.2 with support for 10.6 onwards.

CFLAGS=-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.6 -arch x86_64 
CXXFLAGS=-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.6  -arch 
x86_64 ./configure --disable-dependency-tracking  --enable-llvm 
--enable-clamdtop --with-user=_clamav --with-group=_clamav 
--enable-all-jit-targets

Mark

On 16 May 2014, at 02:01 pm, Joel Esler (jesler) jes...@cisco.com wrote:

 http://blog.clamav.net/2014/05/clamav-0984rc1-is-now-available.html
 
 ClamAV 0.98.4rc1 is now available for download.  Shown below are the notes 
 concerning this release:
 
 
 0.98.4rc1
 --
 
 ClamAV 0.98.4 is a bug fix release. The following issues are now resolved:
 
 - Various build problems on Solaris, OpenBSD, AIX.
 
 - Crashes of clamd on Windows and Mac OS X platforms when reloading
 the virus signature database.
 
 - Infinite loop in clamdscan when clamd is not running.
 
 - Freshclam failure on Solaris 10.
 
 - Buffer underruns when handling multi-part MIME email attachments.
 
 - Configuration of OpenSSL on various platforms.
 
 
 
 ClamAV 0.98.4rc1 is available for download here: 
 http://sourceforge.net/projects/clamav/files/RC/clamav-0.98.4-rc1/.  Please 
 download, test, and provide feedback to the mailing list here:
 
 http://lists.clamav.net/mailman/listinfo/clamav-users
 
 
 --
 The ClamAV team (http://www.clamav.net/team)
 
 ___
 http://lurker.clamav.net/list/clamav-devel.html
 Please submit your patches to our Bugzilla: http://bugs.clamav.net

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

Re: [Clamav-devel] [clamav-users] ClamAV®: ClamAV 0.98.5 beta has been posted!

[Mark Allan]

On 9 Jul 2014, at 12:15 am, Joel Esler (jesler) jes...@cisco.com wrote:

 ClamAV 0.98.5 beta has been posted!
 The ClamAV team is proud to announce the availability of ClamAV 0.98.5 beta 
 ready for testing!
 
 http://blog.clamav.net/2014/07/clamav-0985-beta-has-been-posted.html

Compiled and appears to work fine on OS X 10.9 - also compiles fine on 10.10.

For quite a while, there's been a huge number (several hundred) of compiler 
warnings - many ironically generated by code which has a comment alongside 
//silence compiler warning!

Most warnings are about booleans being assigned to themselves, or unused 
variables and parameters.  Would it be of any help to try and remove these or 
would you prefer I just silence the warnings at my end with compiler flags?   
-Wno-self-assign -Wno-unused-parameter -Wno-unused-variable

Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

[Clamav-devel] Increase in FP for Heuristics.Phishing.Email

[Mark Allan]

Hi,

I'm seeing an increase in instances of false positive reports for emails marked 
as phishing. In particular Heuristics.Phishing.Email.SpoofedDomain.

This is typically showing up in genuine PayPal or eBay emails but I've also 
seen it with genuine emails from credit card suppliers.

These never used to trigger warnings so I'm wondering if something has changed 
recently?

Cheers
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] ClamAV(R) blog: ClamAV 0.99 Release Candidate has been posted!

[Mark Allan]

Hi Steve,

Thanks for getting back to me. Yes, I'm aware of the workarounds - I was merely 
mentioning that they were still required despite the fix being targeted at v0.99

The main reasons for my email were freshclam producing warnings that weren't 
being suppressed with the "--no-warnings" flag (now filed as bugzilla 11411); 
and  to raise awareness of the fact that ClamAV won't compile at all on OS X 
10.11.

On that last note, having spent a chunk of yesterday working on this, I believe 
I have a workaround. It's not ideal, but as a binary package maintainer, it 
sure beats bundling and exporting OpenSSL myself!

First thing is to grab a copy of the OS X 10.10 SDK.
Add the directory /usr/local/include if it doesn't already exist.
Add a symlink in there to the openssl header directory within the 10.10 SDK.

If anyone else reads this message and follows the above instructions, you 
should bear in mind that Apple deprecated OpenSSL in OS X 10.7 (back in 2011) 
and they removed the headers this year, so it stands to reason that in the 
not-to-distant future, the OpenSSL binaries will also be removed from OS X.

Mark

> On 16 Oct 2015, at 10:50 pm, Steven Morgan <smor...@sourcefire.com> wrote:
> 
> Hi Mark,
> 
> Thanks for your feedback.
> 
> Three work arounds were provided in comment 22 of bugzilla 11309 toward the
> problem of compiling built-in llvm on recent OS X 10.10 releases:
> 
> - compile llvm unoptimized: ./configure CXXFLAGS='-O0'
> - use llvm library already your system: ./configure --with-system-llvm
> - use the bytecode interpreter instead of LLVM JIT: ./configure 
> --enable-llvm=no
> 
> <https://bugzilla.clamav.net/show_bug.cgi?id=11309#>
> The ticket is left open until we decide on the future direction for using
> llvm within ClamAV and that is still under discussion as there are
> additional considerations for other non-Mac OS X platforms.
> 
> As far as compiling on OS X 10.11 with OpenSSL, OpenSSL is required for
> ClamAV since ClamAV 0.98.2. There should be a resource for obtaining and
> installing OpenSSL for that platform.
> 
> libxml2 is not required, but is highly recommended (since ClamAV 0.98.1),
> so sounds like you'll need to install that as well. Please let us know if
> this persists after libxml2 is installed(libxml2 dev version).
> 
> The PCRE warning messages are apparently due to not having PCRE installed.
> PCRE is optional, but the new capabilities of using logical signatures
> containing PCRE and YARA rules require PCRE. Please advise if it is a
> problem when PCRE(dev version again) is installed.
> 
> For the warnings you get from 'freshclam ---no-warnings', please open a
> bugzilla ticket containing the warning messages and we can get those fixed.
> 
> Let us know how things work out with OpenSSL, libxml2, and PCRE installed.
> 
> Thanks,
> Steve
> 
> On Fri, Oct 16, 2015 at 12:30 PM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi Joel,
>> 
>> Compiled OK on OS X 10.10.5 using Xcode 6, but I still needed to add the
>> "--enable-llvm=no" configure flag to get freshclam to work. The issue 11309
>> in Bugzilla is still open, but the target was 0.99
>>https://bugzilla.clamav.net/show_bug.cgi?id=11309
>> 
>> ClamAV will NOT compile on OS X 10.11 with Xcode 7 as Apple doesn't supply
>> OpenSSL headers any more.  I also tried using Xcode 6 and the 10.10 SDK
>> (passing -sysroot in CFLAGS and CXXFlags) but it still says OpenSSL not
>> found. It also fails to find xmlreader.h
>> 
>> OpenSSL binaries are still available, so it's possible to compile on 10.10
>> and run on 10.11, but compilation on OS X 10.11 doesn't appear to be
>> possible any more.
>> 
>> Regardless of how ClamAV is compiled, there is also a minor issue with
>> freshclam:
>> 
>> Running
>>freshclam --no-warnings
>> still prints out a load of warnings
>>[LibClamAV] cli_loadldb: logical signature for
>> Win.Trojan.ssid16667 uses PCREs but support is disabled, skipping
>>...
>>[LibClamAV] cli_loadldb: logical signature for
>> Win.Trojan.ssid15873 uses PCREs but support is disabled, skipping
>> 
>> Regards
>> Mark
>> 
>>> On 15 Oct 2015, at 10:13 pm, Joel Esler (jesler) <jes...@cisco.com>
>> wrote:
>>> 
>>> 
>>> 
>> http://blog.clamav.net/2015/10/clamav-099-release-candidate-has-been.html
>>> 
>>> ClamAV 0.99 Release Candidate has been posted!
>>> ClamAV 0.99 Release Candidate has been posted for download!  Please
>> check out the below release notes:
>>> 
>>> This the first release of ClamAV that is being done on both C

[Clamav-devel] Building ClamAV 0.99 with PCRE support

[Mark Allan]

Hi all,

Are there any recommendations for compilation options on/with pcre?

I've tried several things but can't seem to get the build to work on anything 
other than OS X 10.11.  I never have a problem moving my ClamAV builds between 
machines, but something's going wrong with PCRE support - even when I build 
PCRE on the destination machine, I always end up with the following error from 
clamscan:

LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0: unknown 
option bit(s) set
LibClamAV Error: cli_pcre_build: failed to build pcre regex
ERROR: Database initialization error: Malformed database


Here's a section of the output with --debug on:

LibClamAV debug: Ignoring signature Email.Trojan-417
LibClamAV debug: main.ndb loaded
LibClamAV debug: main.zmd loaded
LibClamAV debug: main.fp loaded
LibClamAV debug: in cli_tgzload_cleanup()
LibClamAV debug: /usr/local/share/clamav/main.cvd loaded
LibClamAV debug: Using filter for trie 0
LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0: unknown 
option bit(s) set
LibClamAV Error: cli_pcre_build: failed to build pcre regex
ERROR: Database initialization error: Malformed database
LibClamAV debug: Cleaning up phishcheck
LibClamAV debug: Freeing phishcheck struct
LibClamAV debug: Phishcheck cleaned up

These are the options I'm passing to pcre's configure phase:
./configure --prefix=/usr/local --enable-newline-is-any --enable-utf 
--enable-unicode-properties --enable-rebuild-chartables --enable-pcre16 
--enable-pcre32 --enable-jit

This is what I'm passing to ClamAV's configure phase:
./configure --disable-dependency-tracking  --enable-llvm=no --enable-clamdtop 
--with-user=_clamav --with-group=_clamav --enable-all-jit-targets 
--with-pcre=/usr/local --prefix=/usr/local

I get the same results regardless of what options I pass to PCRE's configure 
script. I've also tried pcre-8.37 and pcre-8.38.

Can anyone suggest anything?

Many thanks
Mark

> On 20 Nov 2015, at 6:01 pm, Mickey Sola <ms...@sourcefire.com> wrote:
> 
> Hi Mark,
> 
> Unfortunately, as of right now the only way to get pcre 8.38 is via their
> rc1 candidate (check the pcre-dev mailing list for a tarball).
> 
> In practice, the pcre exploit ClamAV warns about (
> http://www.securitytracker.com/id/1032453) relies upon an explicitly
> malicious regex, so you don't have to worry too much unless you're using
> untrusted sigs. Everything should still compile and run just fine, even
> with 8.37.
> 
> - Mickey
> 
> On Fri, Nov 20, 2015 at 8:08 AM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> I saw the blog post about v0.99 rc 2 and have downloaded it for testing.
>> 
>> It looks like bug 11411 [
>> https://bugzilla.clamav.net/show_bug.cgi?id=11411 ] is still open, so I
>> decided to download and build PCRE as well.
>> 
>> I initially tried the PCRE2 branch but it wasn't recognised by ClamAV's
>> configure script, so I went with the most up-to-date version of PCRE (which
>> is currently 8.37) but now configure outputs the following:
>> 
>> configure: WARNING: The installed pcre version may contain a security bug.
>> Please upgrade to 8.38 or later: http://www.pcre.org
>> 
>> There is no 8.38 that I can see:
>>https://sourceforge.net/projects/pcre/files/pcre/
>> 
>> Are you just assuming that 8.38 will be coming soon to fix the bug, or is
>> there a download somewhere that I'm not seeing?
>> 
>> Thanks
>> Mark
>> 
>> ___
>> http://lurker.clamav.net/list/clamav-devel.html
>> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>> 
>> http://www.clamav.net/contact.html#ml
>> 
> ___
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Building ClamAV 0.99 with PCRE support

[Mark Allan]

Hi Kevin,

Thanks.

Yes, the configure options are definitely the same. In fact PCRE isn't 
installed on OS X by default, so I'm compiling it as well and copying all the 
binaries & libraries etc over to the destination machines at the same time as 
copying the ClamAV binaries.

Mark

> On 8 Dec 2015, at 6:36 pm, Kevin Lin <k...@sourcefire.com> wrote:
> 
> It appears that the PCRE library is correctly linking in and ClamAV is
> making calls to it. The error message:
> 
> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
> unknown option bit(s) set
> 
> results directly from a failed compilation of PCRE regex which in this case
> is due to an unknown option bit being set.
> 
> Looking into it, the options that can be passed to pcre_compile are fairly
> common ones; the only real exception is PCRE_NEVER_UTF which was added in
> 8.33. It's possible that the flag existed on the source machine but not the
> destination.Are the PCRE configure options consistent across the source and
> all the destination machines?
> 
> -Kevin
> 
> 
> 
> On Tue, Dec 8, 2015 at 12:15 PM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> Are there any recommendations for compilation options on/with pcre?
>> 
>> I've tried several things but can't seem to get the build to work on
>> anything other than OS X 10.11.  I never have a problem moving my ClamAV
>> builds between machines, but something's going wrong with PCRE support -
>> even when I build PCRE on the destination machine, I always end up with the
>> following error from clamscan:
>> 
>> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
>> unknown option bit(s) set
>> LibClamAV Error: cli_pcre_build: failed to build pcre regex
>> ERROR: Database initialization error: Malformed database
>> 
>> 
>> Here's a section of the output with --debug on:
>> 
>> LibClamAV debug: Ignoring signature Email.Trojan-417
>> LibClamAV debug: main.ndb loaded
>> LibClamAV debug: main.zmd loaded
>> LibClamAV debug: main.fp loaded
>> LibClamAV debug: in cli_tgzload_cleanup()
>> LibClamAV debug: /usr/local/share/clamav/main.cvd loaded
>> LibClamAV debug: Using filter for trie 0
>> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
>> unknown option bit(s) set
>> LibClamAV Error: cli_pcre_build: failed to build pcre regex
>> ERROR: Database initialization error: Malformed database
>> LibClamAV debug: Cleaning up phishcheck
>> LibClamAV debug: Freeing phishcheck struct
>> LibClamAV debug: Phishcheck cleaned up
>> 
>> These are the options I'm passing to pcre's configure phase:
>> ./configure --prefix=/usr/local --enable-newline-is-any --enable-utf
>> --enable-unicode-properties --enable-rebuild-chartables --enable-pcre16
>> --enable-pcre32 --enable-jit
>> 
>> This is what I'm passing to ClamAV's configure phase:
>> ./configure --disable-dependency-tracking  --enable-llvm=no
>> --enable-clamdtop --with-user=_clamav --with-group=_clamav
>> --enable-all-jit-targets --with-pcre=/usr/local --prefix=/usr/local
>> 
>> I get the same results regardless of what options I pass to PCRE's
>> configure script. I've also tried pcre-8.37 and pcre-8.38.
>> 
>> Can anyone suggest anything?
>> 
>> Many thanks
>> Mark
>> 
>>> On 20 Nov 2015, at 6:01 pm, Mickey Sola <ms...@sourcefire.com> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> Unfortunately, as of right now the only way to get pcre 8.38 is via their
>>> rc1 candidate (check the pcre-dev mailing list for a tarball).
>>> 
>>> In practice, the pcre exploit ClamAV warns about (
>>> http://www.securitytracker.com/id/1032453) relies upon an explicitly
>>> malicious regex, so you don't have to worry too much unless you're using
>>> untrusted sigs. Everything should still compile and run just fine, even
>>> with 8.37.
>>> 
>>> - Mickey
>>> 
>>> On Fri, Nov 20, 2015 at 8:08 AM, Mark Allan <markjal...@gmail.com>
>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> I saw the blog post about v0.99 rc 2 and have downloaded it for testing.
>>>> 
>>>> It looks like bug 11411 [
>>>> https://bugzilla.clamav.net/show_bug.cgi?id=11411 ] is still open, so I
>>>> decided to download and build PCRE as well.
>>>> 
>>>> I initially tried the PCRE2 branch but it wasn't recognised by ClamAV's
>>>> configure script, so I went with the most up-to-date version of PC

Re: [Clamav-devel] Building ClamAV 0.99 with PCRE support

[Mark Allan]

Hi Kevin,

Yes, that's fixed it. Thanks so much.

I still can't fathom why it would work differently on different versions of OS 
X, but it looks like you've solved the problem I'm seeing for now.

Thanks again
Mark

> On 8 Dec 2015, at 8:21 pm, Kevin Lin <k...@sourcefire.com> wrote:
> 
> Can I ask you to try this patch and tell me if it fixes the issue? If the
> issue persists, please submit the debug log. Thanks.
> 
> -Kevin
> 
> On Tue, Dec 8, 2015 at 2:00 PM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi Kevin,
>> 
>> Thanks.
>> 
>> Yes, the configure options are definitely the same. In fact PCRE isn't
>> installed on OS X by default, so I'm compiling it as well and copying all
>> the binaries & libraries etc over to the destination machines at the same
>> time as copying the ClamAV binaries.
>> 
>> Mark
>> 
>>> On 8 Dec 2015, at 6:36 pm, Kevin Lin <k...@sourcefire.com> wrote:
>>> 
>>> It appears that the PCRE library is correctly linking in and ClamAV is
>>> making calls to it. The error message:
>>> 
>>> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
>>> unknown option bit(s) set
>>> 
>>> results directly from a failed compilation of PCRE regex which in this
>> case
>>> is due to an unknown option bit being set.
>>> 
>>> Looking into it, the options that can be passed to pcre_compile are
>> fairly
>>> common ones; the only real exception is PCRE_NEVER_UTF which was added in
>>> 8.33. It's possible that the flag existed on the source machine but not
>> the
>>> destination.Are the PCRE configure options consistent across the source
>> and
>>> all the destination machines?
>>> 
>>> -Kevin
>>> 
>>> 
>>> 
>>> On Tue, Dec 8, 2015 at 12:15 PM, Mark Allan <markjal...@gmail.com>
>> wrote:
>>> 
>>>> Hi all,
>>>> 
>>>> Are there any recommendations for compilation options on/with pcre?
>>>> 
>>>> I've tried several things but can't seem to get the build to work on
>>>> anything other than OS X 10.11.  I never have a problem moving my ClamAV
>>>> builds between machines, but something's going wrong with PCRE support -
>>>> even when I build PCRE on the destination machine, I always end up with
>> the
>>>> following error from clamscan:
>>>> 
>>>> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
>>>> unknown option bit(s) set
>>>> LibClamAV Error: cli_pcre_build: failed to build pcre regex
>>>> ERROR: Database initialization error: Malformed database
>>>> 
>>>> 
>>>> Here's a section of the output with --debug on:
>>>> 
>>>> LibClamAV debug: Ignoring signature Email.Trojan-417
>>>> LibClamAV debug: main.ndb loaded
>>>> LibClamAV debug: main.zmd loaded
>>>> LibClamAV debug: main.fp loaded
>>>> LibClamAV debug: in cli_tgzload_cleanup()
>>>> LibClamAV debug: /usr/local/share/clamav/main.cvd loaded
>>>> LibClamAV debug: Using filter for trie 0
>>>> LibClamAV Error: cli_pcre_parse: PCRE compilation failed at offset 0:
>>>> unknown option bit(s) set
>>>> LibClamAV Error: cli_pcre_build: failed to build pcre regex
>>>> ERROR: Database initialization error: Malformed database
>>>> LibClamAV debug: Cleaning up phishcheck
>>>> LibClamAV debug: Freeing phishcheck struct
>>>> LibClamAV debug: Phishcheck cleaned up
>>>> 
>>>> These are the options I'm passing to pcre's configure phase:
>>>> ./configure --prefix=/usr/local --enable-newline-is-any --enable-utf
>>>> --enable-unicode-properties --enable-rebuild-chartables --enable-pcre16
>>>> --enable-pcre32 --enable-jit
>>>> 
>>>> This is what I'm passing to ClamAV's configure phase:
>>>> ./configure --disable-dependency-tracking  --enable-llvm=no
>>>> --enable-clamdtop --with-user=_clamav --with-group=_clamav
>>>> --enable-all-jit-targets --with-pcre=/usr/local --prefix=/usr/local
>>>> 
>>>> I get the same results regardless of what options I pass to PCRE's
>>>> configure script. I've also tried pcre-8.37 and pcre-8.38.
>>>> 
>>>> Can anyone suggest anything?
>>>> 
>>>> Many thanks
>>>> Mark
>>>> 
>>>>> On 20 Nov 2015, at 6:01 pm, Mickey Sola <ms...@s

[Clamav-devel] Patch to force freshclam download progress meter

[Mark Allan]

Hi all,

With the release of 0.99, I got caught out by a change to freshclam's output.  
The end result is the same (defs do/don't get updated) so none of my automated 
tests caught it, but when you actually sit and watch the output, I'm not 
getting the download progress meter in my GUI any more.

The change that tripped it up was commit #cf5ba11 - Avoid emitting incremental 
progress messages when not outputting to a terminal.

I've included a patch which works against 0.99 stable as well as current HEAD 
(#1f85811) to add a new command line flag --show-progress to freshclam to force 
the output of the progress meter if freshclam isn't being called via a terminal.

Hopefully the additional flag won't cause problems for anyone, so it would be 
really great if the patch could be included please.

Many thanks,
Mark




freshclam_show-progress.patch
Description: Binary data
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] ClamAV 0.99 RC 2

[Mark Allan]

Hi all,

I saw the blog post about v0.99 rc 2 and have downloaded it for testing.

It looks like bug 11411 [ https://bugzilla.clamav.net/show_bug.cgi?id=11411 ] 
is still open, so I decided to download and build PCRE as well.

I initially tried the PCRE2 branch but it wasn't recognised by ClamAV's 
configure script, so I went with the most up-to-date version of PCRE (which is 
currently 8.37) but now configure outputs the following:

configure: WARNING: The installed pcre version may contain a security bug. 
Please upgrade to 8.38 or later: http://www.pcre.org

There is no 8.38 that I can see:
https://sourceforge.net/projects/pcre/files/pcre/

Are you just assuming that 8.38 will be coming soon to fix the bug, or is there 
a download somewhere that I'm not seeing?

Thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] ClamAV 0.99 RC 2

[Mark Allan]

Hi Mickey,

Yes, I found details of the exploit after sending my email and assumed it was a 
very low risk for ClamAV users (presumably limited to the downloading of 3rd 
party sigs). Thanks for confirming my suspicions.

I've also now found the RC1 on their FTP site but will stick with the stable 
release.

Cheers
Mark

> On 20 Nov 2015, at 6:01 pm, Mickey Sola <ms...@sourcefire.com> wrote:
> 
> Hi Mark,
> 
> Unfortunately, as of right now the only way to get pcre 8.38 is via their
> rc1 candidate (check the pcre-dev mailing list for a tarball).
> 
> In practice, the pcre exploit ClamAV warns about (
> http://www.securitytracker.com/id/1032453) relies upon an explicitly
> malicious regex, so you don't have to worry too much unless you're using
> untrusted sigs. Everything should still compile and run just fine, even
> with 8.37.
> 
> - Mickey
> 
> On Fri, Nov 20, 2015 at 8:08 AM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> I saw the blog post about v0.99 rc 2 and have downloaded it for testing.
>> 
>> It looks like bug 11411 [
>> https://bugzilla.clamav.net/show_bug.cgi?id=11411 ] is still open, so I
>> decided to download and build PCRE as well.
>> 
>> I initially tried the PCRE2 branch but it wasn't recognised by ClamAV's
>> configure script, so I went with the most up-to-date version of PCRE (which
>> is currently 8.37) but now configure outputs the following:
>> 
>> configure: WARNING: The installed pcre version may contain a security bug.
>> Please upgrade to 8.38 or later: http://www.pcre.org
>> 
>> There is no 8.38 that I can see:
>>https://sourceforge.net/projects/pcre/files/pcre/
>> 
>> Are you just assuming that 8.38 will be coming soon to fix the bug, or is
>> there a download somewhere that I'm not seeing?
>> 
>> Thanks
>> Mark
>> 
>> ___
>> http://lurker.clamav.net/list/clamav-devel.html
>> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>> 
>> http://www.clamav.net/contact.html#ml
>> 
> ___
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] GPL license question

[Mark Allan]

Sorry to dredge up an old thread, but I'm still curious about this.

Joel, your last two replies seem to indicate that it's OK for commercial, 
closed-source applications to link against LibClamav - presumably via dynamic 
linking rather than static linking so as to maintain the distinction between 
"work that uses the library" and "work based on the library" (as per the LGPL).

That's all well-and-good, but the documentation (clamdoc.pdf) which ships with 
ClamAV 0.99.2 clearly states the following on page 25:

> Libclamav is licensed under the GNU GPL v2 license. This means you are not 
> allowed to link commercial, closed-source software against it. All software 
> using libclamav must be GPL compliant.

So I'm wondering what's the definitive answer - is it legal for all those 
commercial closed-source applications you refer to to link against LibClamAV 
even though they're not licensed under the GPL?

If LibClamav is licensed under GPL (as the documentation suggests, and as 
stated in the source code itself), how are they allowed to do this, and which 
parts of ClamAV are covered by the LGPL?

Thanks
Mark

> On 19 Sep 2016, at 2:06 pm, Joel Esler (jesler)  wrote:
> 
> Who is in charge of the issue = me.
> 
> Lots of people make money with ClamAV, millions and millions of dollars a 
> month, and don’t give us a dime, don’t contribute code back, nor do they 
> provide the detection they make back to the community.  But it’s perfectly 
> legal.  Such is the nature with some Open Source products.
> 
> --
> Joel Esler
> Manager
> Talos Group
> http://www.talosintelligence.com 
> 
> 
> On Sep 17, 2016, at 9:59 PM, Borough Rumford   >> wrote:
> 
> Hi Joel,
> 
> You are right. It depends on how you link to clamav. But for this case, It is 
> obvious that "BitMedic" links libclamav  internally and ship it on Mac app 
> store. Those guys make money with clamav, it is unfair for clamav development 
> team and community members. I am wondering who is in charge of this issue in 
> clamav team.
> 
> 
> Best Regards,
> Patrick
> 
> On Sep 17, 2016, at 11:08 am, "Joel Esler (jesler)"  >> 
> wrote:
> 
> I'm not a lawyer. Nor do I play one on TV. But I am the community manager, 
> and I have a lawyer that I ask my questions to, so if I really need to go to 
> him.
> 
> That being said.
> 
> There are a ton of commercial applications that use Clam. You'd frankly be 
> surprised. I still am. It depends on how you link to clamav. You can use 
> clamav and parse results, things like that.
> 
> Where it gets tricky is if you modify code or do internal links to the code. 
> But you can ship clamav packaged with something else, if you do it right. 
> That is possible, yes.
> 
> Sent from my iPhone
> 
> On Sep 17, 2016, at 1:44 PM, Nibin V M   > >> wrote:
> 
> Good question Patric. I am also noticing bunch of commercial security tools
> for web hosting servers, which are directly or indirectly using ClamAV
> libs/binaries so far. I have been wondering same because it shouldn't be
> use that based on the docs!
> 
> On Sat, Sep 17, 2016 at 5:04 PM, Borough Rumford   > >>
> wrote:
> 
> Hi,
> 
> I know clamav is released under GPL license, and third-party commercial
> app shouldn't link libclamav.
> 
> However I find there is one anti-virus app link libclamav directly and is
> published on Mac app store.
> 
> This app is
> https://itunes.apple.com/us/app/bitmedic-antivirus-malware/
> id1001746820?mt=12
> 
> Below is otool result of BitMedic binary otool -L BitMedic
> BitMedic:
> 
> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
> (compatibility version 1.0.0, current version 559.20.9)
> 
> @rpath/libclamav.6.dylib (compatibility version 8.0.0, current version
> 8.25.0)
> 
> /usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version
> 168.0.0)
> 
> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
> (compatibility version 300.0.0, current version 1153.20.0)
> 
> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version
> 228.0.0)
> 
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
> 120.0.0)
> 
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
> 1213.0.0)
> 
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1347.57.0)
> 
> 

Re: [Clamav-devel] [clamav-users] how to avoid false positive in clamAV

[Mark Allan]

To whitelist specific files this way, you need to add the m5sum to a file with 
the .fp extension.  So, in your example, it should be sigtool --md5  
my_file_name.exe >> local.fp

If you want to ignore the signature altogether, you add the signature name to a 
file with the extension ign2.

For what it's worth, this is on page 23 of the "signatures.pdf" document that 
ships with the ClamAV source code.

Best regards
Mark 

> On 5 Apr 2017, at 9:49 am, Gaurav Kumar Garg  wrote:
> 
> Hi ClamAV user, developer,
> 
> I am new to clamAV. I like its design.
> 
> While scanning i saw few false positive virus. I search on internet and found 
> out that i can avoid these false positive by writing md5 sum to local.ign 
> file and putting this file in /var/lib/clamav/*  directory. then restarting 
> clamd daemon.
> 
> 
> Its partially working, means it working when i scan false positive file with 
> clamscan -d and its not working with clamdscan.
> 
> 
> Steps for creating local.ign file:
> 
> 
> $ sigtool --md5  my_file_name.exe >> local.ign
> 
> 
> after that i put this file in /var/lib/clamav/* directory and restarted clamd 
> daemon.
> 
> 
> when i execute $ clamscan -d /var/lib/clamav/local.ign my_file_name.exe then 
> its not reporting false positive, its working perfectly.
> 
> 
> But when i scan this file using clamdscan then its still reporting false 
> positive.
> 
> 
> Could anyone help me regarding this false positive avoidance.
> 
> 
> I can not submit my false positive file because of some business ethics and 
> compliance.
> 
> 
> Thank you in advance,
> 
> 
> Regards,
> 
> Gaurav
> 
> 
> ___
> clamav-users mailing list
> clamav-us...@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

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] More issues with 0.99.3 beta 1

[Mark Allan]

I have two files which are being wrongly reported as infected by 0.99.3 beta 1. 
 ClamAV 0.99.2 doesn't detect any issues with the files.

The first is a single email file (extension .emlx) with md5 checksum of 
245ec37768c235da265014add38bdf4d and a file size of 2777 bytes. It's being 
detected as Win.Trojan.Agent-6319774-0 which has the following signature in 
daily.cvd

[daily.hsb] 6f8f57715090da2632453988d9a1501b:1:Win.Trojan.Agent-6319774-0:73

Three things strike me as odd about this:
1) The length of that hash surely matches md5 rather than sha1/sha256 and 
therefore ought to be in an hdb file rather than hsb?
2) It specifies a length of 1 byte, but also has :73 at the end which means 
"file size unknown".
3) The hash doesn't even match the hash of the email file in question. FWIW 163 
other different email files are also triggering the same infection on 0.99.3 
but not 0.99.2

Wouldn't either of the first two be enough for the sig to be marked as corrupt?

Lastly, why are ClamAV 0.99.2 and 0.99.3 treating that signature differently?


The other file is a PDF being wrongly detected as Win.Trojan.Agent-5520346-0. 
It appears to have the same issue with the signature definition inside 
daily.hsb, and also the file hash (c6721e7c77846b5a1d0efe3a708d8dc7) doesn't 
match the signature hash but is still being detected by 0.99.3 That hash can be 
found on VirusTotal with zero other detections.

[daily.hsb] 8fa14cdd754f91cc6554c9e71929cce7:1:Win.Trojan.Agent-5520346-0:73

While I could just add those two signatures to a local exclude file, I suspect 
there may be a bigger issue at play with 0.99.3

Hope this is helpful.

Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] ClamAV® blog: ClamAV 0.99.3 beta has been released!

[Mark Allan]

Hi all

This email is two-part: an FP report and a bug report - both only concerning 
0.99.3

I just uploaded an FP which is only being detected by 0.99.3 beta 1.  The 
checksum for the submitted file (PDFSigQFormalRep.pdf) is 
1a29b1f3d6df9f1e47c8a77dde142238

It's part of Adobe Acrobat and is showing up as Heuristic.PDF.TooManyFilters.

Now the bug-report part.

I added the relevant line to a local FP file exclude.fp in the clamav database 
directory, and it correctly prevents the file from reporting as being infected, 
however the summary still shows "1 infected file".

$ clamscan  ~/Desktop/temp/PDFSigQFormalRep.pdf 

--- SCAN SUMMARY ---
Known viruses: 7305825
Engine version: 0.99.3-beta1
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.22 MB
Data read: 0.45 MB (ratio 0.49:1)
Time: 21.459 sec (0 m 21 s)

Cheers
Mark


> On 4 Aug 2017, at 12:04 am, Joel Esler (jesler)  wrote:
> 
> http://blog.clamav.net/2017/08/clamav-0993-beta-has-been-released.html
> 
> ClamAV 0.99.3 beta has been released!
> Join us as we welcome ClamAV 0.99.3 beta for testing!  Be sure and grab the 
> beta release on our official ClamAV download 
> site.
> 
> Welcome to ClamAV 0.99.3. In this release, we have included many code
> submissions from the ClamAV community:
> 
> 
>  *   Interfaces to the Prelude SIEM open source package for collecting ClamAV 
> virus events.
>  *   Visual Studio 2015 for building Microsoft Windows binaries.
>  *   Support libmspack internal code or as a shared object library. The 
> internal library is the default and contains additional integrity checks.
>  *   Linking with openssl 1.1.0.
>  *   Numerous code patches, typos, and compiler warning fixes.
> 
> 
> Additionally, we have introduced important changes and new features in
> ClamAV 0.99.3, including:
> 
> 
>  *   Deprecating internal LLVM code support. The configure script has changed 
> to search the system for an installed instance of the LLVM development 
> libraries, and to otherwise use the bytecode interpreter for ClamAV bytecode 
> signatures. To use the LLVM Just-In-Time compiler for executing bytecode 
> signatures, please ensure that the LLVM development package at version 3.6 or 
> lower is installed. Using the deprecated LLVM code is possible with the 
> command: './configure --with-system-llvm=3Dno', but it no longer compile on 
> all platforms.
>  *   Compute and check PE import table hash (a.k.a. "imphash") signatures.
>  *   Support file property collection and analysis for MHTML files.
>  *   Raw scanning of PostScript files.
>  *   Fix clamsubmit to use the new virus and false positive submission web 
> interface.
>  *   Optionally, flag files with the virus "Heuristic.Limits.Exceeded" when 
> size limitations are exceeded.
>  *   Improve decoders for PDF files.
> 
> 
> The ClamAV community thanks the following individuals for their ClamAV 0.99.3 
> code submissions:
> 
> Sebastian Andrzej Siewior
> Keith Jones
> Bill Parker
> Chris Miserva
> Daniel J. Luke
> Matthew Boedicker
> Ningirsu
> Michael Pelletier
> Anthony Chan
> Stephen Welker
> 
> Following are issues discovered during release testing. For additional 
> information, please review the corresponding tickets on 
> bugzilla.clamav.net:
> 
> 11879 - cli_scanmscan() Failed to extract 4 in Windows beta when scanning cab 
> files
> 11882 - ./configure does not automatically detect libxml2 on FreeBSD 10.3 and 
> 11.0
> 11884 - 'sudo make install' on FreeBSD 10.3 and 11.0 leaves files owned by 
> root, subsequent make command fails
> 11885 - clamsubmit not building on FreeBSD 10.3 and 11.0
> 11887 - Failures of 'make check VG=1' on FreeBSD 10.3 and 11.0
> 
> We ask that feedback be provided via the ClamAV mailing 
> lists.
> 
> 
> --
> Joel Esler | Talos: Manager | jes...@cisco.com
> 
> 
> 
> 
> 
> 
> ___
> clamav-users mailing list
> clamav-us...@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

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] Another bug with ClamAV 0.99.3 beta 1

[Mark Allan]

Hi all,

Another issue with 0.99.3 beta 1.

The clamd process crashes on macOS 10.6.8 because it can't find the strndup 
symbol.  There are a couple of references to strndup in the source for clamd 
and libclamav - should these be changed to cli_strndup or am I better to 
include a static replacement function of strndup in the appropriate files that 
would only be used on 10.6 or earlier?

Thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Another bug with ClamAV 0.99.3 beta 1

[Mark Allan]

I just had another look at this today with fresh eyes and I see you've already 
got a static replacement of strndup for Solaris, so I've included a patch which 
uses the same function on macOS 10.6.8 or lower.  It relies on the appropriate  
(-mmacosx-version-min=10.6) setting on the configure phase, but the chances are 
if anyone's compiling with 10.6 support, they probably ain't compiling on 10.6 
so it's likely being supplied already.




diff -Naurw clamav-0.99.3-beta1/clamd/localserver.c 
clamav-0.99.3-beta1_patched/clamd/localserver.c
--- clamav-0.99.3-beta1/clamd/localserver.c 2017-07-31 19:34:32.0 
+0100
+++ clamav-0.99.3-beta1_patched/clamd/localserver.c 2017-08-14 
14:24:08.0 +0100
@@ -25,7 +25,7 @@
 
 #include 
 #include 
-#if defined(C_SOLARIS)
+#if defined(C_SOLARIS) || 
(defined(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__) && 
(__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ <= 1068))
 size_t strnlen(const char *s, size_t n) __attribute__((weak));
 size_t strnlen(const char *s, size_t n)
 {



Hope that's useful.

Mark


> On 13 Aug 2017, at 10:25 pm, Mark Allan <markjal...@gmail.com> wrote:
> 
> Hi all,
> 
> Another issue with 0.99.3 beta 1.
> 
> The clamd process crashes on macOS 10.6.8 because it can't find the strndup 
> symbol.  There are a couple of references to strndup in the source for clamd 
> and libclamav - should these be changed to cli_strndup or am I better to 
> include a static replacement function of strndup in the appropriate files 
> that would only be used on 10.6 or earlier?
> 
> Thanks
> Mark
> 

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] Compiling against LibreSSL instead of OpenSSL

[Mark Allan]

Hi all,

Is there a way to compile ClamAV using LibreSSL instead of OpenSSL?

I keep getting an error during ./config phase:

> configure: error: Your OpenSSL installation is misconfigured or missing


I eventually figured it's because the system I'm compiling on has LibreSSL 
2.2.7 instead of OpenSSL that I was expecting.

I don't really want to start having to build and bundle OpenSSL with my ClamAV 
build.

Thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] Problem compiling with libxml2 and Xcode 9

[Mark Allan]

Hi all,

I just updated Xcode (Apple's developer tools for macOS) to version 9 and I'm 
no longer able to compile ClamAV 0.99.2 with libxml2 support.

Here's the relevant output from the configure script:

> ...
> checking for libxml2 installation... /usr
> checking xml2-config version... 2.9.4
> checking for xmlreader.h in /usr... found
> checking for xmlTextReaderRead in -lxml2... no
> configure: ** libxml2 support unavailable
> ...
> configure: Summary of engine detection features
>   bzip2   : ok
>   zlib: /usr
>   unrar   : yes
>   pcre: /usr/local/clamXav
>   libxml2 : no
>   yara: yes

I'm aware that things tend to break when updating Xcode, so I did this test in 
a virtual machine, which means I can say with certainty that the devtools are 
the only things to have changed. If I revert to the snapshot with Xcode 8.3, 
the configure script finds everything it needs to within /usr:

> ...
> checking for libxml2 installation... /usr
> checking xml2-config version... 2.9.4
> checking for xmlreader.h in /usr... found
> checking for xmlTextReaderRead in -lxml2... yes
> configure: Compiling and linking with libxml2 from /usr
> ...
> configure: Summary of engine detection features
>   bzip2   : ok
>   zlib: /usr
>   unrar   : yes
>   pcre: /usr/local/clamXav
>   libxml2 : yes, from /usr
>   yara: yes

If I update again (or go back to the snapshot with Xcode 9) it fails.

I've compared the checksums of the libraries in /usr/lib/libxml2.* and they're 
identical before and after the upgrade. Similarly, diffing the contents of 
/usr/include/libxml2/libxml shows they're exactly the same too, so I'm not 
quite sure what's going on.

Can anyone help shed some light on the matter please?

Many thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Problem compiling with libxml2 and Xcode 9

[Mark Allan]

Hi Steve,

Attached are the extracted lines from the config.log of the non-working 
version.  The one which works just gives the following output:

> configure:17809: checking for xmlTextReaderRead in -lxml2
> configure:17834: gcc -o conftest -O2 -g -D_FILE_OFFSET_BITS=64 
> -mmacosx-version-min=10.6  -arch x86_64 -w  
> -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/include/libxml2
>   
> -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib
>  -lxml2 -lz -lpthread -licucore -lm conftest.c -lxml2 
> -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib
>  -lxml2 -lz -lpthread -licucore -lm  >&5
> configure:17834: $? = 0
> configure:17843: result: yes



From a quick glance, I suspect that means there's a problem with the 10.13 SDK 
and I'll need to get in touch with Apple.  Can you confirm that I'm right?

Thanks
Mark



config.log
Description: Binary data



> On 10 Oct 2017, at 4:46 pm, Steven Morgan <smor...@sourcefire.com> wrote:
> 
> Mark,
> 
> The file config.log should contain the details of the configure test
> performed for -lxml2.
> 
> Can you tell what are the relevant differences in those files?
> 
> Thanks,
> Steve
> 
> On Tue, Oct 10, 2017 at 7:48 AM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi all,
>> 
>> I just updated Xcode (Apple's developer tools for macOS) to version 9 and
>> I'm no longer able to compile ClamAV 0.99.2 with libxml2 support.
>> 
>> Here's the relevant output from the configure script:
>> 
>>> ...
>>> checking for libxml2 installation... /usr
>>> checking xml2-config version... 2.9.4
>>> checking for xmlreader.h in /usr... found
>>> checking for xmlTextReaderRead in -lxml2... no
>>> configure: ** libxml2 support unavailable
>>> ...
>>> configure: Summary of engine detection features
>>>  bzip2   : ok
>>>  zlib: /usr
>>>  unrar   : yes
>>>  pcre: /usr/local/clamXav
>>>  libxml2 : no
>>>  yara: yes
>> 
>> I'm aware that things tend to break when updating Xcode, so I did this
>> test in a virtual machine, which means I can say with certainty that the
>> devtools are the only things to have changed. If I revert to the snapshot
>> with Xcode 8.3, the configure script finds everything it needs to within
>> /usr:
>> 
>>> ...
>>> checking for libxml2 installation... /usr
>>> checking xml2-config version... 2.9.4
>>> checking for xmlreader.h in /usr... found
>>> checking for xmlTextReaderRead in -lxml2... yes
>>> configure: Compiling and linking with libxml2 from /usr
>>> ...
>>> configure: Summary of engine detection features
>>>  bzip2   : ok
>>>  zlib: /usr
>>>  unrar   : yes
>>>  pcre: /usr/local/clamXav
>>>  libxml2 : yes, from /usr
>>>  yara: yes
>> 
>> If I update again (or go back to the snapshot with Xcode 9) it fails.
>> 
>> I've compared the checksums of the libraries in /usr/lib/libxml2.* and
>> they're identical before and after the upgrade. Similarly, diffing the
>> contents of /usr/include/libxml2/libxml shows they're exactly the same too,
>> so I'm not quite sure what's going on.
>> 
>> Can anyone help shed some light on the matter please?
>> 
>> Many thanks
>> Mark
>> 
>> ___
>> http://lurker.clamav.net/list/clamav-devel.html
>> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>> 
>> http://www.clamav.net/contact.html#ml
>> 
> ___
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Problem compiling with libxml2 and Xcode 9

[Mark Allan]

Thanks. I've reported the issue and will see what comes of it...

Mark

> On 10 Oct 2017, at 6:05 pm, Steven Morgan <smor...@sourcefire.com> wrote:
> 
> Yes, I see it fail in the libxml2 test in looking for
> /usr/lib/system/libsystem_darwin.dylib for x64.
> 
> Steve
> 
> On Tue, Oct 10, 2017 at 12:02 PM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi Steve,
>> 
>> Attached are the extracted lines from the config.log of the non-working
>> version.  The one which works just gives the following output:
>> 
>>> configure:17809: checking for xmlTextReaderRead in -lxml2
>>> configure:17834: gcc -o conftest -O2 -g -D_FILE_OFFSET_BITS=64
>> -mmacosx-version-min=10.6  -arch x86_64 -w  -I/Applications/Xcode.app/
>> Contents/Developer/Platforms/MacOSX.platform/Developer/
>> SDKs/MacOSX10.12.sdk/usr/include/libxml2  -L/Applications/Xcode.app/
>> Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib
>> -lxml2 -lz -lpthread -licucore -lm conftest.c -lxml2
>> -L/Applications/Xcode.app/Contents/Developer/Platforms/
>> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib -lxml2 -lz
>> -lpthread -licucore -lm  >&5
>>> configure:17834: $? = 0
>>> configure:17843: result: yes
>> 
>> 
>> 
>> From a quick glance, I suspect that means there's a problem with the 10.13
>> SDK and I'll need to get in touch with Apple.  Can you confirm that I'm
>> right?
>> 
>> Thanks
>> Mark
>> 
>> 
> ___
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Why is error 13 fatal?

[Mark Allan]

Hi Steve,

No, this patch is designed to permit scans of subsequent files to proceed.  
When error 13 is encountered, the whole clamscan process terminates.

Mark

> On 30 Oct 2017, at 7:43 pm, Steven Morgan <smor...@sourcefire.com> wrote:
> 
> Mark,
> 
> To clarify, this patch allows the scan of the current file to continue.
> ClamAV is not aborting scans of subsequent files, right?
> 
> THanks,
> Steve
> 
> 
> On Mon, Oct 30, 2017 at 1:03 PM, Mark Allan <markjal...@gmail.com> wrote:
> 
>> Hi Micah,
>> 
>> Thanks for getting back to me.
>> 
>> Just so you know, I also received an email (off-list) from Tom McCourt
>> about the same issue.
>> 
>> Unfortunately I don't know what files are causing the issue because it
>> seems to stop at a different point in the scan every time. Sometimes
>> (rarely) the scan will even run to completion without giving the error.
>> 
>> I'll run the scans again a few times this evening and pick out any files
>> it stops on.
>> 
>> Lastly, as requested, below is my patch for switch statement. (odd. I just
>> noticed the CL_ESTAT case above ESEEK, has a comment at the end. That's
>> unintentional)
>> 
>> Thanks
>> Mark
>> 
>> diff -Naurw clamav-0.99.2_clean/libclamav/scanners.c
>> clamav-0.99.2/libclamav/scanners.c
>> --- clamav-0.99.2_clean/libclamav/scanners.c2016-04-22
>> 16:02:19.0 +0100
>> +++ clamav-0.99.2/libclamav/scanners.c  2016-10-17 16:13:57.0
>> +0100
>> @@ -3214,8 +3340,8 @@
>>switch(res) {
>>/* List of scan halts, runtime errors only! */
>>case CL_EUNLINK:
>> -   case CL_ESTAT:
>> -   case CL_ESEEK:
>> +   case CL_ESTAT://
>> +// case CL_ESEEK:
>>case CL_EWRITE:
>>case CL_EDUP:
>>case CL_ETMPFILE:
>> @@ -3242,6 +3368,11 @@
>>cli_dbgmsg("Descriptor[%d]: Continuing after
>> cli_scanraw reached %s\n",
>>fmap_fd(*ctx->fmap), cl_strerror(res));
>>break;
>> +   case CL_ESEEK:
>> +   res = CL_CLEAN;
>> +   ret = res;
>> +   cli_errmsg("Descriptor[%d]: Continuing after
>> cli_scanraw SEEK error %s\n", fmap_fd(*ctx->fmap), cl_strerror(res));
>> +   break;
>>/* Other errors must not block further scans below
>> * This specifically includes CL_EFORMAT & CL_EREAD &
>> CL_EUNPACK
>> * Malformed/truncated files could report as any of these
>> three.
>> 
>> 
>>> On 30 Oct 2017, at 4:36 pm, Micah Snyder (micasnyd) <micas...@cisco.com>
>> wrote:
>>> 
>>> Hi Mark,
>>> 
>>> I'm curious if there are any particular files that it scans that causes
>> a seek to fail / causes the CL_ESEEK error to bubble up to that switch
>> statement in magic_scandesc().  I wouldn't be surprised if an invalid
>> offset in a file header caused a seek to an invalid offset.  I don't know
>> if APFS handles seeks to offsets outside of the actual file differently
>> than other file systems.  What is more typical is a read error if you seek
>> outside of the file and then read.  Anyhow, if you can identify any samples
>> that cause the issue I'd like to test with it.
>>> 
>>> Can you send us your patch to tweak the switch statement for review?  I
>> agree that a seek error in one file shouldn't halt the entire scan.
>>> 
>>> Cheers,
>>> Micah
>>> 
>>> Micah Snyder
>>> Software Engineer
>>> Talos Intelligence
>>> Cisco Systems, Inc.
>>> 
>>> -Original Message-
>>> From: clamav-devel [mailto:clamav-devel-boun...@lists.clamav.net] On
>> Behalf Of Mark Allan
>>> Sent: Friday, October 27, 2017 10:44 AM
>>> To: ClamAV Development <clamav-devel@lists.clamav.net>
>>> Subject: [Clamav-devel] Why is error 13 fatal?
>>> 
>>> Hi there,
>>> 
>>> For a while now, ClamAV 0.99.2 has been terminating unexpectedly with
>> error 13 when running on the latest version of OS X (macOS 10.13) but only
>> on drives formatted with the new APFS, so I chalked it up to an APFS issue
>> and reported it to Apple.  Today, however, I received a report of the same
>> thing from someone whose hard drive is formatted with the old standard HFS+.
>>> 

Re: [Clamav-devel] Why is error 13 fatal?

[Mark Allan]

Hi folks,

I've attached the output from 3 scans, all of which were started at root (/) 
with no other volumes mounted on the system.

I'm running the scans with parameters -riv (recursive, print infected only, 
verbose) as well as --debug.  The verbose flag prints out the name of each file 
being scanned, and I *believe* it prints this before attempting to start the 
scan of that file.

For each run, I grabbed the console output from the last "Scanning " 
to the end of the output.  Of particular note is Run 2, where the last line of 
output was the one saying which file was being scanned (prior to that point, 
the output was as you would expect) - no debug output at all to hint at where 
it went wrong.

As usual, all three scans stopped at different points.  I've tried rescanning 
those three files, and they all complete successfully.  Happy to send them on 
to you anyway if you think it would help. Just let me know where to send them - 
presumably they shouldn't be sent to the list?

Mark
Scanning /Users/REDACTED/Library/Caches/com.apple.iTunes/WebKitCache/Version 
11/Records/0263F8C913F192735CDDD8EE8B35A24936B42423/Resource/DD1190DCEF293D02AFBC495AC16E312F168F5459-blob
LibClamAV debug: in cli_magic_scandesc (reclevel: 0/16)

LibClamAV debug: Recognized ASCII text

LibClamAV debug: cache_check: 3fc5799f5fe8bad9232972eda77d7ce3 is negative

LibClamAV debug: Matched signature for file type HTML data at 82243

LibClamAV debug: Matched signature for file type HTML data

LibClamAV debug: Matched signature for file type HTML data

LibClamAV debug: Matched signature for file type HTML data

LibClamAV debug: Matched signature for file type HTML data

LibClamAV debug: matcher_run: performing regex matching on full map: 
2077664+78843(2156507) >= 2156507

LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex 
/\x2epostMessage\s*\x28\s*([^\s]+)\x2edata\x2econcat\s*\x28\1\x2edata\s*\x29/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex 
/\x2f\x2a\s+XPM\s+\x2a\x2f[^\x7b]*?\x7b\s*\x22\s*(\d+\s+){3}\d{4}/
LibClamAV debug: cli_pcre_scanbuf: checking (0>1)&(1>1)&(2>25); running regex 
/.Write\s*\x28\s*vbCrlf[^\n\x29]+\x28\s*[\x22\x27][a-zA-Z0-9+/]{5,}[a-zA-Z0-9+/=]{1,2}[\x22\x27]\s*\x29\s*\x29\r\n/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1&(2>150); running regex /^(var 
[a-z]{3,} = [\x22\x27].{1,3}[\x22\x27]\x3B\n)/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/ATF.{3}\xFF.{1}[\x80-\xFF].{4}[\x00-\x12][\x00-\x12][\x00-\x13]/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1&2; running regex 
/\x28\x00\x00\x00[\x00-\xff][\x00-\xff]\x90[\x04-\xff]([\x00-\xff]{4})\x01\x00\x08\x00/
LibClamAV debug: cli_pcre_scanbuf: checking 0&1; running regex 
/(function\s[o0O]{6}\(\s*([o0O]{6})?(\s*,\s*[o0O]{6})*\s*\).*?){3,}/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex 
/[\W_][a-z0-9]{4,16}\.js/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/SMG[\W_][0-9]{2,4}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/ATTACHMENT\-PP\.html/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/NEW\sOPEN\sTENDER\sREQUIREMENT\sFOR\sMIDDLE\sEAST\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/PTY\sLTD\-USD\s[\d]{2,5}\.[\d]{2}\-VALUE\.vbs/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/[a-zA-Z]{4,7}\s[a-zA-Z]{6,9}\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/[a-z]{4}\s[a-z]{4}\-[0-9]{3}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/[a-zA-Z]{5}\s[A-Z0-9]{8,12}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/SHIPPING\sDOCUMENT\sINV,\sPL,\sBL\s\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /P41014\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex 
/BL[\W_][\w]{0,16}\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /HUD\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/0\.72077800\s1489544882\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/Tax\sRefund\sForm\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/PROCESSO\s2\sVARA\.vbe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/DHL\sDelivery\sDocuments\.bat/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/49BHAGB\s398\#\sADVICE\sTT\s0477HF\sHSBC\sSLK\sBANK\.html/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/WF\.jar[\W_]JavaCrypt[\d]?\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0|1; running regex 
/[A-Z]{2}[A-Z0-9]{4,20}\.js/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/Contract\sWFALASMA\-05\-17\.exe/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex /P[\d]{5,10}\.zip/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/Shipment\sDocs_Customs\.jar/
LibClamAV debug: cli_pcre_scanbuf: checking 0; running regex 
/[A-Z]{6}\s[A-Z]{7}\s[A-Z]{7}\s[A-Z]{3}\s[A-Z]{9}\.pif/
LibClamAV debug: 

Re: [Clamav-devel] Problem compiling with libxml2 and Xcode 9

[Mark Allan]

Quick followup on this one in case anyone else needs it.

It turns out you need to use -isysroot if you want to specify an explicit SDK, 
and use -iwithsysroot to specify a header search path within the SDK.

Easiest way to do that is add the following to your CFLAGS and CXXFLAGS prior 
to running the configure script.

-isysroot $SDKRoot -iwithsysroot $SDKRoot

where $SDKRoot can be determined with the following:

xcrun --sdk macosx --show-sdk-path

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk

Mark

> On 11 Oct 2017, at 11:11 am, Mark Allan <markjal...@gmail.com> wrote:
> 
> Thanks. I've reported the issue and will see what comes of it...
> 
> Mark
> 
>> On 10 Oct 2017, at 6:05 pm, Steven Morgan <smor...@sourcefire.com> wrote:
>> 
>> Yes, I see it fail in the libxml2 test in looking for
>> /usr/lib/system/libsystem_darwin.dylib for x64.
>> 
>> Steve
>> 
>> On Tue, Oct 10, 2017 at 12:02 PM, Mark Allan <markjal...@gmail.com> wrote:
>> 
>>> Hi Steve,
>>> 
>>> Attached are the extracted lines from the config.log of the non-working
>>> version.  The one which works just gives the following output:
>>> 
>>>> configure:17809: checking for xmlTextReaderRead in -lxml2
>>>> configure:17834: gcc -o conftest -O2 -g -D_FILE_OFFSET_BITS=64
>>> -mmacosx-version-min=10.6  -arch x86_64 -w  -I/Applications/Xcode.app/
>>> Contents/Developer/Platforms/MacOSX.platform/Developer/
>>> SDKs/MacOSX10.12.sdk/usr/include/libxml2  -L/Applications/Xcode.app/
>>> Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib
>>> -lxml2 -lz -lpthread -licucore -lm conftest.c -lxml2
>>> -L/Applications/Xcode.app/Contents/Developer/Platforms/
>>> MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/usr/lib -lxml2 -lz
>>> -lpthread -licucore -lm  >&5
>>>> configure:17834: $? = 0
>>>> configure:17843: result: yes
>>> 
>>> 
>>> 
>>> From a quick glance, I suspect that means there's a problem with the 10.13
>>> SDK and I'll need to get in touch with Apple.  Can you confirm that I'm
>>> right?
>>> 
>>> Thanks
>>> Mark
>>> 
>>> 
>> ___
>> http://lurker.clamav.net/list/clamav-devel.html
>> Please submit your patches to our Bugzilla: http://bugs.clamav.net
>> 
>> http://www.clamav.net/contact.html#ml
> 

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] Why is error 13 fatal?

[Mark Allan]

Hi Micah,

Thanks for getting back to me.

Just so you know, I also received an email (off-list) from Tom McCourt about 
the same issue.

Unfortunately I don't know what files are causing the issue because it seems to 
stop at a different point in the scan every time. Sometimes (rarely) the scan 
will even run to completion without giving the error.

I'll run the scans again a few times this evening and pick out any files it 
stops on.

Lastly, as requested, below is my patch for switch statement. (odd. I just 
noticed the CL_ESTAT case above ESEEK, has a comment at the end. That's 
unintentional)

Thanks
Mark

diff -Naurw clamav-0.99.2_clean/libclamav/scanners.c 
clamav-0.99.2/libclamav/scanners.c
--- clamav-0.99.2_clean/libclamav/scanners.c2016-04-22 16:02:19.0 
+0100
+++ clamav-0.99.2/libclamav/scanners.c  2016-10-17 16:13:57.0 +0100
@@ -3214,8 +3340,8 @@
switch(res) {
/* List of scan halts, runtime errors only! */
case CL_EUNLINK:
-   case CL_ESTAT:
-   case CL_ESEEK:
+   case CL_ESTAT://
+// case CL_ESEEK:
case CL_EWRITE:
case CL_EDUP:
case CL_ETMPFILE:
@@ -3242,6 +3368,11 @@
cli_dbgmsg("Descriptor[%d]: Continuing after cli_scanraw 
reached %s\n",
fmap_fd(*ctx->fmap), cl_strerror(res));
break;
+   case CL_ESEEK:
+   res = CL_CLEAN;
+   ret = res;
+   cli_errmsg("Descriptor[%d]: Continuing after cli_scanraw 
SEEK error %s\n", fmap_fd(*ctx->fmap), cl_strerror(res));
+   break;
/* Other errors must not block further scans below
 * This specifically includes CL_EFORMAT & CL_EREAD & CL_EUNPACK
 * Malformed/truncated files could report as any of these three.


> On 30 Oct 2017, at 4:36 pm, Micah Snyder (micasnyd) <micas...@cisco.com> 
> wrote:
> 
> Hi Mark,
> 
> I'm curious if there are any particular files that it scans that causes a 
> seek to fail / causes the CL_ESEEK error to bubble up to that switch 
> statement in magic_scandesc().  I wouldn't be surprised if an invalid offset 
> in a file header caused a seek to an invalid offset.  I don't know if APFS 
> handles seeks to offsets outside of the actual file differently than other 
> file systems.  What is more typical is a read error if you seek outside of 
> the file and then read.  Anyhow, if you can identify any samples that cause 
> the issue I'd like to test with it. 
> 
> Can you send us your patch to tweak the switch statement for review?  I agree 
> that a seek error in one file shouldn't halt the entire scan.   
> 
> Cheers,
> Micah
> 
> Micah Snyder
> Software Engineer
> Talos Intelligence
> Cisco Systems, Inc.
> 
> -----Original Message-
> From: clamav-devel [mailto:clamav-devel-boun...@lists.clamav.net] On Behalf 
> Of Mark Allan
> Sent: Friday, October 27, 2017 10:44 AM
> To: ClamAV Development <clamav-devel@lists.clamav.net>
> Subject: [Clamav-devel] Why is error 13 fatal?
> 
> Hi there,
> 
> For a while now, ClamAV 0.99.2 has been terminating unexpectedly with error 
> 13 when running on the latest version of OS X (macOS 10.13) but only on 
> drives formatted with the new APFS, so I chalked it up to an APFS issue and 
> reported it to Apple.  Today, however, I received a report of the same thing 
> from someone whose hard drive is formatted with the old standard HFS+.
> 
> There's nothing of note in the scan output, even when run with --debug, and 
> it gives the error at a different point every time.  Sometimes it occurs 
> after a couple of minutes, sometimes it can be an hour into the scan.
> 
> I've had a look at the ClamAV source to see what's causing error 13 and it 
> seems to correspond to CL_ESEEK.  Looking in libclamav/scanners.c, I can see 
> a switch statement that causes the scan to abort when the result from 
> cli_scanraw(...) is CL_ESEEK.
> 
> Can anyone think why the error would be occurring, and is there a particular 
> reason why experiencing error 13 on one file should cause the rest of the 
> scan to be aborted?
> 
> Finally, is it safe to tweak that switch statement to log the error and 
> continue scanning rather than stopping?  It appears to work, but I'm not sure 
> what knock-on effect it might have.
> 
> Many thanks
> Mark
> 
> ___
> http://lurker.clamav.net/list/clamav-devel.html
> Please submit your patches to our Bugzilla: http://bugs.clamav.net
> 
> http://www.clamav.net/contact.html#ml
> ___
> http://lurker.clamav.net/lis

[Clamav-devel] Why is error 13 fatal?

[Mark Allan]

Hi there,

For a while now, ClamAV 0.99.2 has been terminating unexpectedly with error 13 
when running on the latest version of OS X (macOS 10.13) but only on drives 
formatted with the new APFS, so I chalked it up to an APFS issue and reported 
it to Apple.  Today, however, I received a report of the same thing from 
someone whose hard drive is formatted with the old standard HFS+.

There's nothing of note in the scan output, even when run with --debug, and it 
gives the error at a different point every time.  Sometimes it occurs after a 
couple of minutes, sometimes it can be an hour into the scan.

I've had a look at the ClamAV source to see what's causing error 13 and it 
seems to correspond to CL_ESEEK.  Looking in libclamav/scanners.c, I can see a 
switch statement that causes the scan to abort when the result from 
cli_scanraw(...) is CL_ESEEK.

Can anyone think why the error would be occurring, and is there a particular 
reason why experiencing error 13 on one file should cause the rest of the scan 
to be aborted?

Finally, is it safe to tweak that switch statement to log the error and 
continue scanning rather than stopping?  It appears to work, but I'm not sure 
what knock-on effect it might have.

Many thanks
Mark

___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

Re: [Clamav-devel] [clamav-users] Freshclam 0.100.0 returning 1 on up-to-date

[Mark Allan]

Looks like the problem actually stems from a new #define in
"freshclam/freshclamcodes.h".  Change the value of FC_UPTODATE from 1 to 0
and you'll get the old/correct functionality.  Patch below.

Cheers
Mark

diff -Naurw freshclamOrig/freshclamcodes.h freshclam/freshclamcodes.h
--- freshclamOrig/freshclamcodes.h 2018-04-11 14:50:44.0 +0100
+++ freshclam/freshclamcodes.h 2018-04-11 14:57:54.0 +0100
@@ -20,7 +20,7 @@
 #ifndef __FRESHCLAMCODES_H
 #define __FRESHCLAMCODES_H

-#define FC_UPTODATE1
+#define FC_UPTODATE0

 #define FCE_INIT  40
 #define FCE_CHECKS41

On 10 April 2018 at 13:36, Andreas Schulze  wrote:

> Am 10.04.2018 um 10:32 schrieb Pertti Karppinen:
> > Freshclam seems to be returning 1 on up-to-date situation, but man page
> > says it should return 0:
> > 0 : Database is up-to-date or successfully updated.
> >
> I think, I had the similar (same?) problem some times ago and fixed it
> with this patch:
>
> Description: freshclam should return 0 if only custom databases
>  are updated and all are up to date
> Author: A. Schulze
> URL: https://bugzilla.clamav.net/show_bug.cgi?id=11812
> ---
> This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
> Index: clamav-0.100.0~beta/freshclam/manager.c
> ===
> --- clamav-0.100.0~beta.orig/freshclam/manager.c
> +++ clamav-0.100.0~beta/freshclam/manager.c
> @@ -2612,6 +2612,7 @@ downloadmanager (const struct optstruct
>   updatecustomdb (opt->strarg, , opts, localip,
>   logerr)) == 0)
>  updated = 1;
> +if (custret == 1) { /* not updated but up to date */ custret
> = 0; }
>  opt = opt->nextarg;
>  }
>  }
>
>
> --
> A. Schulze
> DATEV eG
> ___
> clamav-users mailing list
> clamav-us...@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
>
___
http://lurker.clamav.net/list/clamav-devel.html
Please submit your patches to our Bugzilla: http://bugs.clamav.net

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

[Clamav-devel] Bug with .fp file being ignored

[Mark Allan]

Hi,

I think there's a bug with ClamAV not honouring the contents of a .fp file
within the database directory.

I've tested 0.101.2 as well as previous versions of ClamAV going back to
0.99.4 and the issue seems to have appeared as of 0.100.0 onwards.

To re-create the issue:

Find a zip file which you know reports an infection when scanned.
Use sigtool --md5 to generate an FP sig of the zip file and save it in a
.fp file in the databse directory.
Use clamscan to scan the file and see that it still reports the file as
being infected.


The output from clamscan --debug shows the .fp file is being loaded, but it
just doesn't seem to be being honoured for some reason.

I see the same thing when I build ClamAV on macOS as well as when using the
apt-get distribution on Ubuntu 18.04

Lastly, it only appears to be an issue with archive filetypes eg .zip, .dmg
etc. Simple files are excluded as expected - similarly, if you generate an
FP sig of a simple file and put that file within an archive, it correctly
gets excluded.

I'll clone the source from Git on Monday and have a dig through it myself
to see if I can fix the bug, but thought I'd mention it here in case
someone's already on it, or at least knows where I can start looking!

Cheers
Mark
___

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

Please submit your patches to our Bugzilla: http://bugzilla.clamav.net

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

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

Re: [Clamav-devel] Bug with .fp file being ignored

[Mark Allan]

OK, so tracking this one down took longer than I like to admit!

The issue seems to have crept in with commits 3e42216cc and 28afc94c3 back in 
April/May 2017.

Attached are patches for devel/HEAD as well as the stable 0.101.2 

Tests show that the issue is fixed and doesn't appear to introduce any false 
negatives.however, it does produce a duplicate output line - one listed the 
infection found, and the second line (honouring the FP file) saying "OK".  The 
"infected files" count is correct - see output below.

Does anyone know how to fix that duplicate output?

Cheers
Mark

virus-2009-04-13-id0007662101.zip: Osx.Worm.Leap-2 FOUND
virus-2009-04-13-id0007662101.zip: OK

--- SCAN SUMMARY ---
Known viruses: 6168730
Engine version: 0.101.2
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.02 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 33.865 sec (0 m 33 s)




fix_devel_head.patch
Description: Binary data


fix_101_2.patch
Description: Binary data


> On 12 Jul 2019, at 11:07 pm, Mark Allan  wrote:
> 
> Hi,
> 
> I think there's a bug with ClamAV not honouring the contents of a .fp file 
> within the database directory.
> 
> I've tested 0.101.2 as well as previous versions of ClamAV going back to 
> 0.99.4 and the issue seems to have appeared as of 0.100.0 onwards.
> 
> To re-create the issue:
> 
> Find a zip file which you know reports an infection when scanned.
> Use sigtool --md5 to generate an FP sig of the zip file and save it in a 
> .fp file in the databse directory.
> Use clamscan to scan the file and see that it still reports the file as being 
> infected.
> 
> 
> The output from clamscan --debug shows the .fp file is being loaded, but it 
> just doesn't seem to be being honoured for some reason.
> 
> I see the same thing when I build ClamAV on macOS as well as when using the 
> apt-get distribution on Ubuntu 18.04
> 
> Lastly, it only appears to be an issue with archive filetypes eg .zip, .dmg 
> etc. Simple files are excluded as expected - similarly, if you generate an FP 
> sig of a simple file and put that file within an archive, it correctly gets 
> excluded.
> 
> I'll clone the source from Git on Monday and have a dig through it myself to 
> see if I can fix the bug, but thought I'd mention it here in case someone's 
> already on it, or at least knows where I can start looking!
> 
> Cheers
> Mark

___

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

Please submit your patches to our Bugzilla: http://bugzilla.clamav.net

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

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

Re: [Clamav-devel] Bug with .fp file being ignored

[Mark Allan]

Hi Micah,

Yes I did, and I submitted a patch back in July but there was another related 
issue which I wasn't able to fix.  I've copied my email below with the patches.

Best regards
Mark
---

The issue seems to have crept in with commits 3e42216cc and 28afc94c3 back in 
April/May 2017.

Attached are patches for devel/HEAD as well as the stable 0.101.2 

Tests show that the issue is fixed and doesn't appear to introduce any false 
negatives.however, it does produce a duplicate output line - one listed the 
infection found, and the second line (honouring the FP file) saying "OK".  The 
"infected files" count is correct - see output below.

Does anyone know how to fix that duplicate output?

Cheers
Mark

virus-2009-04-13-id0007662101.zip: Osx.Worm.Leap-2 FOUND
virus-2009-04-13-id0007662101.zip: OK

--- SCAN SUMMARY ---
Known viruses: 6168730
Engine version: 0.101.2
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.02 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 33.865 sec (0 m 33 s)




fix_devel_head.patch
Description: Binary data


fix_101_2.patch
Description: Binary data


> On 20 Sep 2019, at 10:29 am, Micah Snyder (micasnyd)  
> wrote:
> 
> Hi Mark,
> 
> Did you have any luck identifying the source of the bug?  I admit I 
> bookmarked your email and failed to find time to look into it myself after 
> that.  
> 
> -Micah
> 
> On 7/12/19, 6:09 PM, "clamav-devel on behalf of Mark Allan" 
>  
> wrote:
> 
>Hi,
> 
>I think there's a bug with ClamAV not honouring the contents of a .fp file
>within the database directory.
> 
>I've tested 0.101.2 as well as previous versions of ClamAV going back to
>0.99.4 and the issue seems to have appeared as of 0.100.0 onwards.
> 
>To re-create the issue:
> 
>Find a zip file which you know reports an infection when scanned.
>Use sigtool --md5 to generate an FP sig of the zip file and save it in a
>.fp file in the databse directory.
>Use clamscan to scan the file and see that it still reports the file as
>being infected.
> 
> 
>The output from clamscan --debug shows the .fp file is being loaded, but it
>just doesn't seem to be being honoured for some reason.
> 
>I see the same thing when I build ClamAV on macOS as well as when using the
>apt-get distribution on Ubuntu 18.04
> 
>Lastly, it only appears to be an issue with archive filetypes eg .zip, .dmg
>etc. Simple files are excluded as expected - similarly, if you generate an
>FP sig of a simple file and put that file within an archive, it correctly
>gets excluded.
> 
>I'll clone the source from Git on Monday and have a dig through it myself
>to see if I can fix the bug, but thought I'd mention it here in case
>someone's already on it, or at least knows where I can start looking!
> 
>Cheers
>Mark
>___
> 
>clamav-devel mailing list
>clamav-devel@lists.clamav.net
>https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
>Please submit your patches to our Bugzilla: http://bugzilla.clamav.net
> 
>Help us build a comprehensive ClamAV guide:
>https://github.com/vrtadmin/clamav-faq
> 
>http://www.clamav.net/contact.html#ml
> 
> 
> ___
> 
> clamav-devel mailing list
> clamav-devel@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
> Please submit your patches to our Bugzilla: http://bugzilla.clamav.net
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml

___

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

Please submit your patches to our Bugzilla: http://bugzilla.clamav.net

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

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

[Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on macOS 10.15

[Mark Allan]

Hi folks,

I'm still testing 0.102.3 but I've hit a few issues where some known-good files 
are being detected as infected because they're generating the following error:
Can't allocate memory ERROR

Output from clamscan and clamdscan are as follows:

> $ /usr/local/bin/clamscan /Applications/Microsoft\ 
> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
> 
> --- SCAN SUMMARY ---
> Known viruses: 0
> Engine version: 0.102.3
> Scanned directories: 0
> Scanned files: 1
> Infected files: 1
> Data scanned: 0.00 MB
> Data read: 0.01 MB (ratio 0.00:1)
> Time: 0.009 sec (0 m 0 s)
> 
> Escalate:/Applications $ /usr/local/bin/clamdscan --multiscan 
> /Applications/Microsoft\ 
> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
> /Applications/Microsoft 
> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
>  Can't allocate memory ERROR
> 
> --- SCAN SUMMARY ---
> Infected files: 0
> Total errors: 1
> Time: 0.002 sec (0 m 0 s)
> Escalate:/Applications $ 


I removed main.cvd and bytecode.cvd from the database directory, unpacked 
daily.cvd and eventually tracked it down to daily.crb

Removing the following definition solves the problem, but for some reason this 
can't be added to an ign2 file...and this sig worked on older versions of 
clamav, so it feels like that's the wrong solution anyway!
Trusted.CA.Microsoft-7350512-0

Has anyone else come up against this problem before, and do you know what I can 
do about it?

Many thanks
Mark

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on macOS 10.15

[Mark Allan]

Quick follow-up to this one.

Upon further digging, if the --fdpass flag is passed to clamdscan, you get 
different output...albeit still very wrong!
/Applications/Microsoft 
Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
 (null) FOUND

Does anyone have any thoughts at all?

Thanks,
Mark

> On 29 May 2020, at 1:26 am, Mark Allan  wrote:
> 
> Hi folks,
> 
> I'm still testing 0.102.3 but I've hit a few issues where some known-good 
> files are being detected as infected because they're generating the following 
> error:
>   Can't allocate memory ERROR
> 
> Output from clamscan and clamdscan are as follows:
> 
>> $ /usr/local/bin/clamscan /Applications/Microsoft\ 
>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
>> 
>> --- SCAN SUMMARY ---
>> Known viruses: 0
>> Engine version: 0.102.3
>> Scanned directories: 0
>> Scanned files: 1
>> Infected files: 1
>> Data scanned: 0.00 MB
>> Data read: 0.01 MB (ratio 0.00:1)
>> Time: 0.009 sec (0 m 0 s)
>> 
>> Escalate:/Applications $ /usr/local/bin/clamdscan --multiscan 
>> /Applications/Microsoft\ 
>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
>> /Applications/Microsoft 
>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
>>  Can't allocate memory ERROR
>> 
>> --- SCAN SUMMARY ---
>> Infected files: 0
>> Total errors: 1
>> Time: 0.002 sec (0 m 0 s)
>> Escalate:/Applications $ 
> 
> 
> I removed main.cvd and bytecode.cvd from the database directory, unpacked 
> daily.cvd and eventually tracked it down to daily.crb
> 
> Removing the following definition solves the problem, but for some reason 
> this can't be added to an ign2 file...and this sig worked on older versions 
> of clamav, so it feels like that's the wrong solution anyway!
>   Trusted.CA.Microsoft-7350512-0
> 
> Has anyone else come up against this problem before, and do you know what I 
> can do about it?
> 
> Many thanks
> Mark
> 

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on macOS 10.15

[Mark Allan]

Hi Micah,

Thanks. I've uploaded it to clamav.net <http://clamav.net/> as an FP report.

Here are the various hashes to help you find it.

MD5 460cd4f06997a968b1a0ba91ba127984
SHA-1   e35ffaafb6a0548fece874360c56204df2bf1233
SHA-256 1d9dd7f51e21b0f384355de6a5a22d9017ecad0e5adc3c91c24a03b599c54f1d

Thanks
Mark


> On 2 Jun 2020, at 3:43 pm, Micah Snyder (micasnyd)  wrote:
> 
> Hi Mark,
> 
> This is a very strange one you’ve encountered.  Can you send the file my way 
> so I can reproduce the issue, and debug-step through the code?
> 
> -Micah
> 
> From: clamav-devel 
> Date: Friday, May 29, 2020 at 7:46 PM
> To: ClamAV Development 
> Subject: Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on 
> macOS 10.15
> Quick follow-up to this one.
> 
> Upon further digging, if the --fdpass flag is passed to clamdscan, you get 
> different output...albeit still very wrong!
>/Applications/Microsoft 
> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
>  (null) FOUND
> 
> Does anyone have any thoughts at all?
> 
> Thanks,
> Mark
> 
>> On 29 May 2020, at 1:26 am, Mark Allan  wrote:
>> 
>> Hi folks,
>> 
>> I'm still testing 0.102.3 but I've hit a few issues where some known-good 
>> files are being detected as infected because they're generating the 
>> following error:
>>   Can't allocate memory ERROR
>> 
>> Output from clamscan and clamdscan are as follows:
>> 
>>> $ /usr/local/bin/clamscan /Applications/Microsoft\ 
>>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
>>> 
>>> --- SCAN SUMMARY ---
>>> Known viruses: 0
>>> Engine version: 0.102.3
>>> Scanned directories: 0
>>> Scanned files: 1
>>> Infected files: 1
>>> Data scanned: 0.00 MB
>>> Data read: 0.01 MB (ratio 0.00:1)
>>> Time: 0.009 sec (0 m 0 s)
>>> 
>>> Escalate:/Applications $ /usr/local/bin/clamdscan --multiscan 
>>> /Applications/Microsoft\ 
>>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
>>> /Applications/Microsoft 
>>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
>>>  Can't allocate memory ERROR
>>> 
>>> --- SCAN SUMMARY ---
>>> Infected files: 0
>>> Total errors: 1
>>> Time: 0.002 sec (0 m 0 s)
>>> Escalate:/Applications $
>> 
>> 
>> I removed main.cvd and bytecode.cvd from the database directory, unpacked 
>> daily.cvd and eventually tracked it down to daily.crb
>> 
>> Removing the following definition solves the problem, but for some reason 
>> this can't be added to an ign2 file...and this sig worked on older versions 
>> of clamav, so it feels like that's the wrong solution anyway!
>>   Trusted.CA.Microsoft-7350512-0
>> 
>> Has anyone else come up against this problem before, and do you know what I 
>> can do about it?
>> 
>> Many thanks
>> Mark
>> 
> 
> ___
> 
> clamav-devel mailing list
> clamav-devel@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
> Please submit your patches to our Github: 
> https://github.com/Cisco-Talos/clamav-devel/pulls
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml
> ___
> 
> clamav-devel mailing list
> clamav-devel@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
> Please submit your patches to our Github: 
> https://github.com/Cisco-Talos/clamav-devel/pulls
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on macOS 10.15

[Mark Allan]

Thanks for trying it out, Micah.

I wonder if it's something to do with the way I'm compiling it then?

Here's my ./configure incantation:

CFLAGS='-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.10  -arch x86_64 
-w -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
 -iwithsysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml2' 
CXXFLAGS='-O2 -g -D_FILE_OFFSET_BITS=64 -mmacosx-version-min=10.10  -arch 
x86_64 -w -isysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
 -iwithsysroot 
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk
 -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/libxml2' 
./configure --disable-dependency-tracking  --enable-llvm=no --enable-clamdtop 
--with-user=_clamav --with-group=_clamav --enable-all-jit-targets 
--with-pcre=/usr/local/clamav --with-openssl=/usr/local/clamav 
--prefix=/usr/local/clamav

A few things I should probably explain with this:

1) The mmacosx-version-min=10.10 flag is so I can produce a package that 
supports macOS 10.10 to 10.15.
2) The version of PCRE is pcre2-10.35
3) OpenSSL isn't really compiled and distributed under /usr/local/clamav - it's 
just a bunch of symlinks to the openSSL libraries that ship a default install 
of macOS, which is ye olde libssl.0.9.8.dylib
4) If I don't pass in the header location for libxml2, the configure script 
still finds them, but the Make phase fails as it can't find "libxml/parser.h".

For what it's worth, the only step I had to change to make 0.102.3 compile was 
to add in step 4. Prior to 102.3 it compiled just fine without it...but I doubt 
that's the issue.

Not sure if that helps at all.

Thanks again
Mark

> On 2 Jun 2020, at 6:59 pm, Micah Snyder (micasnyd)  wrote:
> 
> I just tried reproducing the issue using 0.102.3, both with the file you 
> provided and with my own copy (it turns out I have that filepath on my mac 
> already).  Wasn’t able to reproduce the error with clamscan, clamdscan, or 
> clamdscan –fdpass.  Not sure how to help.
> 
> Anyone else have any ideas?
> 
> -Micah
> 
> From: clamav-devel  <mailto:clamav-devel-boun...@lists.clamav.net>>
> Date: Tuesday, June 2, 2020 at 11:04 AM
> To: ClamAV Development  <mailto:clamav-devel@lists.clamav.net>>
> Subject: Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on 
> macOS 10.15
> Hi Micah,
> 
> Thanks. I've uploaded it to clamav.net <http://clamav.net/> 
> <http://clamav.net/ <http://clamav.net/>> as an FP report.
> 
> Here are the various hashes to help you find it.
> 
> MD5 460cd4f06997a968b1a0ba91ba127984
> SHA-1   e35ffaafb6a0548fece874360c56204df2bf1233
> SHA-256 1d9dd7f51e21b0f384355de6a5a22d9017ecad0e5adc3c91c24a03b599c54f1d
> 
> Thanks
> Mark
> 
> 
>> On 2 Jun 2020, at 3:43 pm, Micah Snyder (micasnyd) > <mailto:micas...@cisco.com>> wrote:
>> 
>> Hi Mark,
>> 
>> This is a very strange one you’ve encountered.  Can you send the file my way 
>> so I can reproduce the issue, and debug-step through the code?
>> 
>> -Micah
>> 
>> From: clamav-devel > <mailto:clamav-devel-boun...@lists.clamav.net>>
>> Date: Friday, May 29, 2020 at 7:46 PM
>> To: ClamAV Development > <mailto:clamav-devel@lists.clamav.net>>
>> Subject: Re: [Clamav-devel] ClamAV 0.102.3 - Can't allocate memory ERROR on 
>> macOS 10.15
>> Quick follow-up to this one.
>> 
>> Upon further digging, if the --fdpass flag is passed to clamdscan, you get 
>> different output...albeit still very wrong!
>>   /Applications/Microsoft 
>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll:
>>  (null) FOUND
>> 
>> Does anyone have any thoughts at all?
>> 
>> Thanks,
>> Mark
>> 
>>> On 29 May 2020, at 1:26 am, Mark Allan >> <mailto:markjal...@gmail.com>> wrote:
>>> 
>>> Hi folks,
>>> 
>>> I'm still testing 0.102.3 but I've hit a few issues where some known-good 
>>> files are being detected as infected because they're generating the 
>>> following error:
>>>  Can't allocate memory ERROR
>>> 
>>> Output from clamscan and clamdscan are as follows:
>>> 
>>>> $ /usr/local/bin/clamscan /Applications/Microsoft\ 
>>>> Excel.app/Contents/SharedSupport/Microsoft.Mashup.Container.app/Contents/SharedSupport/System.ValueTuple.dll
>>>

[Clamav-devel] Issue with FP only on 0.103.1

[Mark Allan]

Hi all,

It looks like the additional image file type support in 0.103.1 has introduced 
an issue with a particular signature which has been in the database since 2018

Img.Exploit.CVE_2018_4904-6449838-0

It's flagging up thousands of known-good files. As far as I can tell, they're 
all TIFF files.

I've added that signature to an ign2 file for now, but I'm wondering if there's 
something else that's maybe amiss somewhere either with the signature or the 
0.103.1 update?

Best regards,
Mark

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] dlopen using relative path for libclamunrar

[Mark Allan]

Hi Micah,

Thanks so much. Prepending the install path PREFIX in the dlopen call works a 
dream!

Trying the absolute path first is necessary to avoid macOS (with hardened 
runtime) printing that warning message every time the command is run. If that 
call fails, it reverts back to the original code which also allows tests to 
succeed.

I can share a patch if you like, but it would be of limited use as I've just 
hard-coded the path seeing as my knowledge of Makefiles is limited and I don't 
know how to reference the PREFIX configure option from within others.c !

Many thanks again for your help.
Mark

> On 24 Feb 2021, at 2:25 am, Micah Snyder (micasnyd)  
> wrote:
> 
> The license stuff is tricky.  I'm not a lawyer, so my advice is maybe not too 
> helpful here.  We include the UnRAR license with ClamAV, but I suppose could 
> be more specific to say that UnRAR's restrictions on reverse engineering to 
> create a RAR archiver apply to ClamAV if UnRAR is linked with ClamAV.  That's 
> how I would want to go about it, anyways.  I guess maybe I need to ask a 
> lawyer. 
> 
> The function that loads libclamurnar_iface is load_module() and is invoked 
> here: 
> https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.104/libclamav/others.c#L314
> 
> As you can see, there are two variants. The first uses libtool's LTDL to load 
> it, the second (newer variant) doesn't.  I added the 2nd variant to simplify 
> the codebase when adding the CMake build system. Anyways... The original LTDL 
> variant adds "SEARCH_LIBDIR" to the search path, which is the install path 
> for the library.  We _could_ just prefix name with the SEARCH_LIBDIR to give 
> it an absolute path and that'd probably work if you install to a specific 
> location and never move it, but it will cause the unit tests to fail any 
> RAR-related tests.  A second call to try using absolute path for the build 
> directory for the library could be added in case the first failed and that'd 
> get the build to work, though that would hadcode the build directory into the 
> release materials which is poor form.
> 
> Pending anything more official about the whole static-linking thing with 
> UnRAR, I don't have a great answer.
> 
> -Micah
> 
>> -Original Message-
>> From: clamav-devel  On Behalf Of
>> Mark Allan
>> Sent: Tuesday, February 23, 2021 4:33 PM
>> To: ClamAV Development 
>> Subject: Re: [Clamav-devel] dlopen using relative path for libclamunrar
>> 
>> Hi Micah,
>> 
>> Many thanks for your reply. I'm always careful to abide by software licences,
>> so wouldn't want to build as 'static' if that would be against UnRAR's 
>> licence.
>> 
>> I'm really just looking for a way to make dlopen load libclamunrar_iface (and
>> all/any other libraries) by way of absolute paths instead of relative ones,
>> without building as static. Is that at all possible?
>> 
>> Thanks again,
>> Mark
>> 
>>> On 23 Feb 2021, at 11:57 pm, Micah Snyder (micasnyd)
>>  wrote:
>>> 
>>> Hi Mark,
>>> 
>>> libclamunrar_iface is loaded dynamically with dlopen and is not linked
>>> with libclamav. UnRAR's license is not entirely "free". It restricts
>>> against reversing UnRAR to create a RAR archiver.  This predates me,
>>> but my understanding is this: The intention is to separate libclamav's
>>> GPLv2 source so that ClamAV can be distributed by Debian on normal
>>> (free software) package servers. Debian distributes the libclamunrar
>>> library separately. In this way, ClamAV installed from Debian's
>>> `apt-get clamav` can function without RAR support but if RAR support
>>> is desired and the user is okay with using "non-free" software, they
>>> can enable the non-free packages and install libclamunrar. Eg:
>>> https://www.danami.com/clients/knowledgebase/90/How-can-I-enable-
>> .rar-
>>> support-for-ClamAV.html
>>> 
>>> Of course, if you're building ClamAV for macOS and you have no qualms
>> about the free/non-free open source licensing, then perhaps linking
>> libclamunrar_iface with libclamav is the way to go. This isn't simple in the
>> build system at present but as soon as I merge this work
>> (https://github.com/micahsnyder/clamav-devel/tree/CLAM-34-unit-test-
>> overhaul-windows-support), it will be as simple as doing a CMake build with
>> static enabled and shared disabled:
>> https://github.com/micahsnyder/clamav-devel/blob/CLAM-34-unit-test-
>> overhaul-windows-support/CMakeLists.txt#L140  I added this capability for
>> better code coverage in oss-fuzz, but I imagine it will be good for macOS

Re: [Clamav-devel] Issue with FP only on 0.103.1

[Mark Allan]

Looks like we have another one!
BC.Img.Exploit.CVE_2018_4891-6453673-2

This is generating loads of FPs as well.

Curiously (and sorry for listing two issues in one email) adding a bytecode 
signature name (with the .{} suffix) to an ign2 file appears to have no effect. 
Any thoughts why this might be?

Best regards,
Mark 

> On 16 Feb 2021, at 3:06 am, Micah Snyder (micasnyd)  
> wrote:
> 
> It looks like BC.Img.Exploit.CVE_2017_11255-6335669-1 suffered the same lack 
> of proper FP testing as the other TIFF signature, likely for the same 
> reasons.  After some time reviewing it, I agree that 
> BC.Img.Exploit.CVE_2017_11255-6335669-1 should be dropped.  This bytecode 
> signature has a relatively high probability to FP on TIFF files that don't 
> include a ColorMap in the IFD header(s), which is also fairly common.  
> Reworking the signature would is probably not worth the effort considering 
> the CVE is from 2017.
> 
> It should be dropped in the update tomorrow morning.
> 
> Thanks for reaching out Mark.
> 
> Regards,
> Micah
> 
>> -Original Message-
>> From: clamav-devel  On Behalf Of
>> Micah Snyder (micasnyd)
>> Sent: Monday, February 15, 2021 11:36 AM
>> To: ClamAV Development 
>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>> 
>> Oh, sorry I misread your email.  Needed more coffee.  You were asking about
>> a different signature: BC.Img.Exploit.CVE_2017_11255-6335669-1
>> Will investigate.
>> 
>> -Micah
>> 
>>> -Original Message-
>>> From: clamav-devel  On Behalf
>>> Of Micah Snyder (micasnyd)
>>> Sent: Monday, February 15, 2021 10:28 AM
>>> To: ClamAV Development 
>>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>>> 
>>> Hi Mark,
>>> 
>>> TL;DR:  The type detection mismatch is fixed in the current daily + 0.103.1.
>>> The issue was with the signature.  We didn't know about it because of
>>> the mismatch.  You should've found that the offending signature was
>>> dropped on Saturday morning.
>>> 
>>> Details:
>>> 
>>> 0.103.1 introduced CL_TYPE_TIFF and changed TIFF file type recognition
>>> from:
>>>  0:0:49492a00:TIFF Little Endian:CL_TYPE_ANY:CL_TYPE_GRAPHICS
>>>  0:0:4d4d:TIFF Big Endian:CL_TYPE_ANY:CL_TYPE_ GRAPHICS
>>> to:
>>>  0:0:49492a00:TIFF Little Endian:CL_TYPE_ANY:CL_TYPE_TIFF
>>>  0:0:4d4d:TIFF Big Endian:CL_TYPE_ANY:CL_TYPE_TIFF
>>> 
>>> When FTM signatures are loaded from daily.cvd, it overrides the
>>> built-in FTM signatures.  So it turns out that daily's FTM file had
>>> been missing the original CL_TYPE_GRAPHICS detection of TIFF files all
>>> this time, which would've been required for Target:5 signatures to
>>> alert on TIFF files.  As a result, the signature in question "worked"
>>> in testing (with a single LDB file, using built-in FTM), but never
>>> worked in worked during FP testing or in production (with a daily CVD file).
>>> 
>>> When we added this to daily.ftm to support 0.103.1:
>>>  0:0:49492a00:TIFF Little Endian:CL_TYPE_ANY:CL_TYPE_TIFF:122
>>>  0:0:4d4d:TIFF Big Endian:CL_TYPE_ANY:CL_TYPE_TIFF:122
>>> ... all of a sudden a signature which was written for TIFF files
>>> started alerting on TIFF files (as it should've) because the new
>>> CL_TYPE_TIFF also alerts on
>>> Target:5 (graphics) types.  We never added the CL_TYPE_GRAPHICS
>>> variant for 0.103.0 and prior, which is why it appeared to be an issue with
>> 0.103.1.
>>> Perhaps we should?  I'll ask MRT about it.
>>> 
>>> Anyways, this is basically a reminder that we need to make sure daily
>>> FTM and libclamav's FTM are in sync.
>>> 
>>> -Micah
>>> 
>>> 
>>>> -Original Message-
>>>> From: clamav-devel  On Behalf
>>>> Of Mark Allan
>>>> Sent: Saturday, February 13, 2021 3:35 PM
>>>> To: ClamAV Development 
>>>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>>>> 
>>>> Thanks. I've just found another one too
>>>> 
>>>>BC.Img.Exploit.CVE_2017_11255-6335669-1
>>>> 
>>>> It's triggering on a file that's been part of macOS for many years.
>>>> It's also a tiff file. I can submit this as well if necessary?
>>>> 
>>>> Out of interest, is the type detection mismatch something that can
>>>> be fixed in daily.cvd or can I patch libclamav/filetypes_int.h to
>>>> reve

Re: [Clamav-devel] Issue with FP only on 0.103.1

[Mark Allan]

Hi Andrew,

Thanks for letting me know it's been dropped now. I was creating the ign2 file 
almost identically, except for using double >> instead of single as I already 
have dozens of lines in there.

I see you have it without the .{} suffix. I tried both with it and without and 
it wasn't working, ie
echo "BC.Img.Exploit.CVE_2018_4891-6453673-2" >> ignored.ign2
echo "BC.Img.Exploit.CVE_2018_4891-6453673-2.{}" >> ignored.ign2

Are you saying the .{} is no longer required to ignore bytecode signatures?

Thanks again
Mark

> On 8 Mar 2021, at 5:44 pm, Andrew Williams  wrote:
> 
> Thanks for reporting this Mark.  The signature has been dropped and a new
> bytecode.cvd released.
> 
> I was able to have the bytecode signature be ignored by creating the .ign2
> file as follows and then moving it into the ClamAV signature directory:
> `echo "BC.Img.Exploit.CVE_2018_4891-6453673-2" > test.ign2`.  Can you
> elaborate on how you are creating the .ign2 file?
> 
> Thanks again,
> 
> -Andrew
> 
> On Thu, Mar 4, 2021 at 11:16 AM Mark Allan  wrote:
> 
>> Looks like we have another one!
>>BC.Img.Exploit.CVE_2018_4891-6453673-2
>> 
>> This is generating loads of FPs as well.
>> 
>> Curiously (and sorry for listing two issues in one email) adding a
>> bytecode signature name (with the .{} suffix) to an ign2 file appears to
>> have no effect. Any thoughts why this might be?
>> 
>> Best regards,
>> Mark
>> 
>>> On 16 Feb 2021, at 3:06 am, Micah Snyder (micasnyd) 
>> wrote:
>>> 
>>> It looks like BC.Img.Exploit.CVE_2017_11255-6335669-1 suffered the same
>> lack of proper FP testing as the other TIFF signature, likely for the same
>> reasons.  After some time reviewing it, I agree that
>> BC.Img.Exploit.CVE_2017_11255-6335669-1 should be dropped.  This bytecode
>> signature has a relatively high probability to FP on TIFF files that don't
>> include a ColorMap in the IFD header(s), which is also fairly common.
>> Reworking the signature would is probably not worth the effort considering
>> the CVE is from 2017.
>>> 
>>> It should be dropped in the update tomorrow morning.
>>> 
>>> Thanks for reaching out Mark.
>>> 
>>> Regards,
>>> Micah
>>> 
>>>> -Original Message-
>>>> From: clamav-devel  On Behalf Of
>>>> Micah Snyder (micasnyd)
>>>> Sent: Monday, February 15, 2021 11:36 AM
>>>> To: ClamAV Development 
>>>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>>>> 
>>>> Oh, sorry I misread your email.  Needed more coffee.  You were asking
>> about
>>>> a different signature: BC.Img.Exploit.CVE_2017_11255-6335669-1
>>>> Will investigate.
>>>> 
>>>> -Micah
>>>> 
>>>>> -Original Message-
>>>>> From: clamav-devel  On Behalf
>>>>> Of Micah Snyder (micasnyd)
>>>>> Sent: Monday, February 15, 2021 10:28 AM
>>>>> To: ClamAV Development 
>>>>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>>>>> 
>>>>> Hi Mark,
>>>>> 
>>>>> TL;DR:  The type detection mismatch is fixed in the current daily +
>> 0.103.1.
>>>>> The issue was with the signature.  We didn't know about it because of
>>>>> the mismatch.  You should've found that the offending signature was
>>>>> dropped on Saturday morning.
>>>>> 
>>>>> Details:
>>>>> 
>>>>> 0.103.1 introduced CL_TYPE_TIFF and changed TIFF file type recognition
>>>>> from:
>>>>> 0:0:49492a00:TIFF Little Endian:CL_TYPE_ANY:CL_TYPE_GRAPHICS
>>>>> 0:0:4d4d:TIFF Big Endian:CL_TYPE_ANY:CL_TYPE_ GRAPHICS
>>>>> to:
>>>>> 0:0:49492a00:TIFF Little Endian:CL_TYPE_ANY:CL_TYPE_TIFF
>>>>> 0:0:4d4d:TIFF Big Endian:CL_TYPE_ANY:CL_TYPE_TIFF
>>>>> 
>>>>> When FTM signatures are loaded from daily.cvd, it overrides the
>>>>> built-in FTM signatures.  So it turns out that daily's FTM file had
>>>>> been missing the original CL_TYPE_GRAPHICS detection of TIFF files all
>>>>> this time, which would've been required for Target:5 signatures to
>>>>> alert on TIFF files.  As a result, the signature in question "worked"
>>>>> in testing (with a single LDB file, using built-in FTM), but never
>>>>> worked in worked during FP testing 

Re: [Clamav-devel] dlopen using relative path for libclamunrar

[Mark Allan]

Hi Micah,

OK, I've had another look at it, removed the hard-coded paths and cleaned it up 
a bit. Patch attached.

Hope it's useful.

Mark 


abspath.patch
Description: Binary data


> On 24 Feb 2021, at 5:00 pm, Micah Snyder (micasnyd)  
> wrote:
> 
> Hi Mark,
> 
> You're welcome! 
> 
> Sure, please send a patch my way.  I'd prefer if no one had to apply patches 
> to use ClamAV, so getting those things working upstream is ideal. 
> 
> -Micah
> 
>> -Original Message-----
>> From: clamav-devel  On Behalf Of
>> Mark Allan
>> Sent: Wednesday, February 24, 2021 7:22 AM
>> To: ClamAV Development 
>> Subject: Re: [Clamav-devel] dlopen using relative path for libclamunrar
>> 
>> Hi Micah,
>> 
>> Thanks so much. Prepending the install path PREFIX in the dlopen call works a
>> dream!
>> 
>> Trying the absolute path first is necessary to avoid macOS (with hardened
>> runtime) printing that warning message every time the command is run. If
>> that call fails, it reverts back to the original code which also allows 
>> tests to
>> succeed.
>> 
>> I can share a patch if you like, but it would be of limited use as I've just 
>> hard-
>> coded the path seeing as my knowledge of Makefiles is limited and I don't
>> know how to reference the PREFIX configure option from within others.c !
>> 
>> Many thanks again for your help.
>> Mark
>> 
>>> On 24 Feb 2021, at 2:25 am, Micah Snyder (micasnyd)
>>  wrote:
>>> 
>>> The license stuff is tricky.  I'm not a lawyer, so my advice is maybe not 
>>> too
>> helpful here.  We include the UnRAR license with ClamAV, but I suppose
>> could be more specific to say that UnRAR's restrictions on reverse
>> engineering to create a RAR archiver apply to ClamAV if UnRAR is linked with
>> ClamAV.  That's how I would want to go about it, anyways.  I guess maybe I
>> need to ask a lawyer.
>>> 
>>> The function that loads libclamurnar_iface is load_module() and is
>>> invoked here:
>>> https://github.com/Cisco-Talos/clamav-devel/blob/dev/0.104/libclamav/o
>>> thers.c#L314
>>> 
>>> As you can see, there are two variants. The first uses libtool's LTDL to 
>>> load
>> it, the second (newer variant) doesn't.  I added the 2nd variant to simplify
>> the codebase when adding the CMake build system. Anyways... The original
>> LTDL variant adds "SEARCH_LIBDIR" to the search path, which is the install
>> path for the library.  We _could_ just prefix name with the SEARCH_LIBDIR to
>> give it an absolute path and that'd probably work if you install to a 
>> specific
>> location and never move it, but it will cause the unit tests to fail any RAR-
>> related tests.  A second call to try using absolute path for the build 
>> directory
>> for the library could be added in case the first failed and that'd get the 
>> build
>> to work, though that would hadcode the build directory into the release
>> materials which is poor form.
>>> 
>>> Pending anything more official about the whole static-linking thing with
>> UnRAR, I don't have a great answer.
>>> 
>>> -Micah
>>> 
>>>> -Original Message-
>>>> From: clamav-devel  On Behalf
>>>> Of Mark Allan
>>>> Sent: Tuesday, February 23, 2021 4:33 PM
>>>> To: ClamAV Development 
>>>> Subject: Re: [Clamav-devel] dlopen using relative path for
>>>> libclamunrar
>>>> 
>>>> Hi Micah,
>>>> 
>>>> Many thanks for your reply. I'm always careful to abide by software
>>>> licences, so wouldn't want to build as 'static' if that would be against
>> UnRAR's licence.
>>>> 
>>>> I'm really just looking for a way to make dlopen load
>>>> libclamunrar_iface (and all/any other libraries) by way of absolute
>>>> paths instead of relative ones, without building as static. Is that at all
>> possible?
>>>> 
>>>> Thanks again,
>>>> Mark
>>>> 
>>>>> On 23 Feb 2021, at 11:57 pm, Micah Snyder (micasnyd)
>>>>  wrote:
>>>>> 
>>>>> Hi Mark,
>>>>> 
>>>>> libclamunrar_iface is loaded dynamically with dlopen and is not
>>>>> linked with libclamav. UnRAR's license is not entirely "free". It
>>>>> restricts against reversing UnRAR to create a RAR archiver.  This
>>>>> predates me, but my understanding is this: The intention is to
>>

Re: [Clamav-devel] dlopen using relative path for libclamunrar

[Mark Allan]

Hi Micah,

Many thanks for your reply. I'm always careful to abide by software licences, 
so wouldn't want to build as 'static' if that would be against UnRAR's licence.

I'm really just looking for a way to make dlopen load libclamunrar_iface (and 
all/any other libraries) by way of absolute paths instead of relative ones, 
without building as static. Is that at all possible?

Thanks again,
Mark

> On 23 Feb 2021, at 11:57 pm, Micah Snyder (micasnyd)  
> wrote:
> 
> Hi Mark,
> 
> libclamunrar_iface is loaded dynamically with dlopen and is not linked with 
> libclamav. UnRAR's license is not entirely "free". It restricts against 
> reversing UnRAR to create a RAR archiver.  This predates me, but my 
> understanding is this: The intention is to separate libclamav's GPLv2 source 
> so that ClamAV can be distributed by Debian on normal (free software) package 
> servers. Debian distributes the libclamunrar library separately. In this way, 
> ClamAV installed from Debian's `apt-get clamav` can function without RAR 
> support but if RAR support is desired and the user is okay with using 
> "non-free" software, they can enable the non-free packages and install 
> libclamunrar. Eg: 
> https://www.danami.com/clients/knowledgebase/90/How-can-I-enable-.rar-support-for-ClamAV.html
> 
> Of course, if you're building ClamAV for macOS and you have no qualms about 
> the free/non-free open source licensing, then perhaps linking 
> libclamunrar_iface with libclamav is the way to go. This isn't simple in the 
> build system at present but as soon as I merge this work 
> (https://github.com/micahsnyder/clamav-devel/tree/CLAM-34-unit-test-overhaul-windows-support),
>  it will be as simple as doing a CMake build with static enabled and shared 
> disabled: 
> https://github.com/micahsnyder/clamav-devel/blob/CLAM-34-unit-test-overhaul-windows-support/CMakeLists.txt#L140
>   I added this capability for better code coverage in oss-fuzz, but I imagine 
> it will be good for macOS hardened systems as well.  
> 
> On that note, CMake's CPack tool may be used to build installers for Windows 
> AND build package installers for macOS as well.  Publishing Windows 
> installers is something I needed to do for feature parity with our old build 
> system, but it's on my to-do list to do the same for macOS, and to add it 
> into our internal Jenkins CI pipeline.  I suppose I should consider making at 
> least the macOS one static.
> 
> -Micah
> 
>> -Original Message-
>> From: clamav-devel  On Behalf Of
>> Mark Allan
>> Sent: Saturday, February 20, 2021 4:43 PM
>> To: ClamAV Development 
>> Subject: [Clamav-devel] dlopen using relative path for libclamunrar
>> 
>> Hi there,
>> 
>> Ever since enabling the macOS hardened runtime for ClamAV, I've been getting
>> the following error/warning message whenever I try to call any of the ClamAV
>> binaries:
>> 
>>> LibClamAV Warning: Cannot dlopen libclamunrar_iface:
>> dlopen(libclamunrar_iface.a, 2): no suitable image found.  Did find:
>>> file system relative paths not allowed in hardened programs - unrar
>> support unavailable
>> 
>> 
>> Is there any reason why the libclamunrar library would be being referenced 
>> via
>> relative path instead of absolute, and is there any way I can fix this?
>> 
>> The other libraries such as libclamav, libclammspack etc appear to load fine.
>> 
>> I'd appreciate any help you can give.
>> 
>> Thanks
>> Mark
>> ___
>> 
>> clamav-devel mailing list
>> clamav-devel@lists.clamav.net
>> https://lists.clamav.net/mailman/listinfo/clamav-devel
>> 
>> Please submit your patches to our Github: https://github.com/Cisco-
>> Talos/clamav-devel/pulls
>> 
>> Help us build a comprehensive ClamAV guide:
>> https://github.com/vrtadmin/clamav-faq
>> 
>> http://www.clamav.net/contact.html#ml
> ___
> 
> clamav-devel mailing list
> clamav-devel@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
> Please submit your patches to our Github: 
> https://github.com/Cisco-Talos/clamav-devel/pulls
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

[Clamav-devel] dlopen using relative path for libclamunrar

[Mark Allan]

Hi there,

Ever since enabling the macOS hardened runtime for ClamAV, I've been getting 
the following error/warning message whenever I try to call any of the ClamAV 
binaries:

> LibClamAV Warning: Cannot dlopen libclamunrar_iface: 
> dlopen(libclamunrar_iface.a, 2): no suitable image found.  Did find:
>   file system relative paths not allowed in hardened programs - unrar 
> support unavailable


Is there any reason why the libclamunrar library would be being referenced via 
relative path instead of absolute, and is there any way I can fix this?

The other libraries such as libclamav, libclammspack etc appear to load fine.

I'd appreciate any help you can give.

Thanks
Mark
___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] Issue with FP only on 0.103.1

[Mark Allan]

Hi Micah,

Yes of course! I've just uploaded a zip file (Archive.zip) to the FP page on 
clamav.net
MD5 (Archive.zip) = 45229d954a884a1e03aba15b9f42168a

Regards
Mark

> On 11 Feb 2021, at 7:12 pm, Micah Snyder (micasnyd)  
> wrote:
> 
> Hi Mark,
> 
> Do you think you could share a sample or two with me to test.  I'm really 
> curious what changed and would like to debug each version with a sample or 
> two.
> 
> -Micah
> 
>> -Original Message-
>> From: clamav-devel  On Behalf Of
>> Mark Allan
>> Sent: Monday, February 8, 2021 3:04 AM
>> To: ClamAV Development 
>> Subject: [Clamav-devel] Issue with FP only on 0.103.1
>> 
>> Hi all,
>> 
>> It looks like the additional image file type support in 0.103.1 has 
>> introduced
>> an issue with a particular signature which has been in the database since 
>> 2018
>> 
>>  Img.Exploit.CVE_2018_4904-6449838-0
>> 
>> It's flagging up thousands of known-good files. As far as I can tell, 
>> they're all
>> TIFF files.
>> 
>> I've added that signature to an ign2 file for now, but I'm wondering if 
>> there's
>> something else that's maybe amiss somewhere either with the signature or
>> the 0.103.1 update?
>> 
>> Best regards,
>> Mark
>> 
>> ___
>> 
>> clamav-devel mailing list
>> clamav-devel@lists.clamav.net
>> https://lists.clamav.net/mailman/listinfo/clamav-devel
>> 
>> Please submit your patches to our Github: https://github.com/Cisco-
>> Talos/clamav-devel/pulls
>> 
>> Help us build a comprehensive ClamAV guide:
>> https://github.com/vrtadmin/clamav-faq
>> 
>> http://www.clamav.net/contact.html#ml
> ___
> 
> clamav-devel mailing list
> clamav-devel@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-devel
> 
> Please submit your patches to our Github: 
> https://github.com/Cisco-Talos/clamav-devel/pulls
> 
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
> 
> http://www.clamav.net/contact.html#ml

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] Issue with FP only on 0.103.1

[Mark Allan]

Thanks. I've just found another one too

BC.Img.Exploit.CVE_2017_11255-6335669-1

It's triggering on a file that's been part of macOS for many years. It's also a 
tiff file. I can submit this as well if necessary?

Out of interest, is the type detection mismatch something that can be fixed in 
daily.cvd or can I patch libclamav/filetypes_int.h to revert it to what it was 
at 0.103.0?

Mark

> On 12 Feb 2021, at 5:23 am, Micah Snyder (micasnyd)  
> wrote:
> 
> It appears to me to be an issue with the signature which is only evident in 
> 0.103.1 now that we're matching TIFFs with Target:5 signatures, like this 
> one.  
> 
> There was apparently a mismatch for TIFF file type detection between the file 
> type magic signatures built-in to libclamav (libclamav/filetypes_int.h) and 
> the .ftm sigs shipped with daily.cvd (which override the internal ones when 
> loaded).
> 
> I'll ask to have the signature dropped and re-evaluated. 
> 
> -Micah
> 
>> -Original Message-
>> From: clamav-devel  On Behalf Of
>> Micah Snyder (micasnyd)
>> Sent: Thursday, February 11, 2021 8:27 PM
>> To: ClamAV Development 
>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>> 
>> Thank you Mark! We'll take a look.
>> 
>> -Micah
>> 
>>> -Original Message-
>>> From: clamav-devel  On Behalf
>>> Of Mark Allan
>>> Sent: Thursday, February 11, 2021 3:54 PM
>>> To: ClamAV Development 
>>> Subject: Re: [Clamav-devel] Issue with FP only on 0.103.1
>>> 
>>> Hi Micah,
>>> 
>>> Yes of course! I've just uploaded a zip file (Archive.zip) to the FP
>>> page on clamav.net
>>> MD5 (Archive.zip) = 45229d954a884a1e03aba15b9f42168a
>>> 
>>> Regards
>>> Mark
>>> 
>>>> On 11 Feb 2021, at 7:12 pm, Micah Snyder (micasnyd)
>>>  wrote:
>>>> 
>>>> Hi Mark,
>>>> 
>>>> Do you think you could share a sample or two with me to test.  I'm
>>>> really
>>> curious what changed and would like to debug each version with a
>>> sample or two.
>>>> 
>>>> -Micah
>>>> 
>>>>> -Original Message-
>>>>> From: clamav-devel  On
>>>>> Behalf Of Mark Allan
>>>>> Sent: Monday, February 8, 2021 3:04 AM
>>>>> To: ClamAV Development 
>>>>> Subject: [Clamav-devel] Issue with FP only on 0.103.1
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> It looks like the additional image file type support in 0.103.1 has
>>>>> introduced an issue with a particular signature which has been in
>>>>> the database since 2018
>>>>> 
>>>>>   Img.Exploit.CVE_2018_4904-6449838-0
>>>>> 
>>>>> It's flagging up thousands of known-good files. As far as I can
>>>>> tell, they're all TIFF files.
>>>>> 
>>>>> I've added that signature to an ign2 file for now, but I'm
>>>>> wondering if there's something else that's maybe amiss somewhere
>>>>> either with the signature or the 0.103.1 update?
>>>>> 
>>>>> Best regards,
>>>>> Mark
>>>>> 
>>>>> ___
>>>>> 
>>>>> clamav-devel mailing list
>>>>> clamav-devel@lists.clamav.net
>>>>> https://lists.clamav.net/mailman/listinfo/clamav-devel
>>>>> 
>>>>> Please submit your patches to our Github: https://github.com/Cisco-
>>>>> Talos/clamav-devel/pulls
>>>>> 
>>>>> Help us build a comprehensive ClamAV guide:
>>>>> https://github.com/vrtadmin/clamav-faq
>>>>> 
>>>>> http://www.clamav.net/contact.html#ml
>>>> ___
>>>> 
>>>> clamav-devel mailing list
>>>> clamav-devel@lists.clamav.net
>>>> https://lists.clamav.net/mailman/listinfo/clamav-devel
>>>> 
>>>> Please submit your patches to our Github:
>>>> https://github.com/Cisco-Talos/clamav-devel/pulls
>>>> 
>>>> Help us build a comprehensive ClamAV guide:
>>>> https://github.com/vrtadmin/clamav-faq
>>>> 
>>>> http://www.clamav.net/contact.html#ml
>>> 
>>> ___
>>> 
>>> clamav-devel mailing list
>&

Re: [Clamav-devel] Second ClamAV 1.0.0 release candidate AND updated packages for 0.105.1

[Mark Allan]

Hi all,

I'm trying to build the ClamAV 1.0.0 RC and saw this in the documentation "Some 
of the dependencies are optional if you elect to not build all of the command 
line applications, or elect to only build the libclamav library. Specifically:
libcurl: required for libfreshclam, freshclam, clamsubmit, clamonacc
ncurses: required for clamdtop"

I don't need any of those binaries but I can't see how to specify that in the 
CMake configuration call. I've had a look at the INSTALL.md file within the 
source directory but the only feature I seem to be able to disable is 
"clamonacc". The ENABLE_APP option seems to turn on/off all of the programs 
rather than letting me pick and choose.

All I really need is clamd, clamdscan, clamscan and sigtool. Is there a way to 
achieve that without building everything and deleting the bits I don't want?

Thanks
Mark

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] Second ClamAV 1.0.0 release candidate AND updated packages for 0.105.1

[Mark Allan]

I thought there was an issue with v1.0 rc2, as a comparison with a previous 
installation (0.104.1) on the same machine showed massively increased scan 
times. After about an hour of digging and laboriously comparing output from 
clamscan --debug, as well as the man pages and clamd.conf, I finally realised 
the max file size has increased.

Comments in the clamd.conf file says the default MaxFileSize is now 100MB (up 
from 25MB in 0.104.1), and it looks like there's been a corresponding increase 
in clamscan as well. Adding `--max-filesize=25M` on the command line brings 
scan times back to previous values.

There's no mention of the change to the maximum file size in the man pages for 
either clamd clamd.conf or clamscan.

Mark
___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] Second ClamAV 1.0.0 release candidate AND updated packages for 0.105.1

[Mark Allan]

> On 26 Nov 2022, at 12:58 pm, G.W. Haywood  
> wrote:
> 
> On Sat, 26 Nov 2022, Mark Allan via clamav-devel-requ...@lists.clamav.net 
> wrote:
> 
>> I thought there was an issue with v1.0 rc2, as a comparison with a
>> previous installation (0.104.1) on the same machine showed massively
>> increased scan times. After about an hour of digging and laboriously
>> comparing output from clamscan --debug, as well as the man pages and
>> clamd.conf, I finally realised the max file size has increased.
>> Comments in the clamd.conf file says the default MaxFileSize is now
>> 100MB (up from 25MB in 0.104.1), and it looks like there's been a
>> corresponding increase in clamscan as well. Adding
>> `--max-filesize=25M` on the command line brings scan times back to
>> previous values.
>> There's no mention of the change to the maximum file size in the man
>> pages for either clamd clamd.conf or clamscan.
> 
> This sort of thing should probably go to the user's list, not dev.

My email was also sent to the users' list, however, it's not the users who 
produce the code or the source tarball; it's the developers, hence sending my 
email here.

> The changes were announced in March 2022, both on the announcements
> list and in the ClamAV blog, for the release candidate for v0.105.0:
> 
> If you're serious about ClamaV you might want to subscribe to the
> announcements list:

I *am* serious about ClamAV, and I do subscribe to all the ClamAV mailing 
lists, but I'm also human and we humans are known on occasion to have fallible 
memories. Neither of those two statements alters the fact that the man pages 
are wrong. I was simply passing on some information to the people who produce 
the software and who might be interested in doing something about it.

If *you're* serious about ClamAV, you might want to reign in the unhelpful 
comments.

I'm aware you have occasionally made helpful contributions to the list, but 
you've also made your fair share of sarcastic, unnecessary and unhelpful 
comments. If you've nothing nice to say, please don't say anything.

Mark

___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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

Re: [Clamav-devel] Second ClamAV 1.0.0 release candidate AND updated packages for 0.105.1

[Mark Allan]

> On 19 Nov 2022, at 1:29 pm, G.W. Haywood  
> wrote:
> 
> On Sat, 19 Nov 2022, Mark Allan wrote:
> 
>> I'm trying to build the ClamAV 1.0.0 RC and saw this in the documentation
>> "Some of the dependencies are optional if you elect to not build all
>> of the command line applications, or elect to only build the
>> libclamav library. Specifically:
>> libcurl: required for libfreshclam, freshclam, clamsubmit, clamonacc
>> ncurses: required for clamdtop"
>> I don't need any of those binaries but I can't see how to specify
>> that in the CMake configuration call. I've had a look at the
>> INSTALL.md file within the source directory but the only feature I
>> seem to be able to disable is "clamonacc". The ENABLE_APP option
>> seems to turn on/off all of the programs rather than letting me pick
>> and choose.
>> All I really need is clamd, clamdscan, clamscan and sigtool. Is
>> there a way to achieve that without building everything and deleting
>> the bits I don't want?
> 
> DISCLAIMER: The CMake system is completely new to me so I don't know
> what the "correct" way to do things like this might be, but if you
> look at around line 1051 in CMakeLists.txt you'll see this:
> 
> 8<--
> 
> 8<--
> 
> My guess from that (because of the part about ENABLE_MILTER) is that
> if you simply edit this file to prevent creation of the subdirectories
> for the relevant binaries you'll at least prevent them from being
> built.  Whether the result will be what you want remains to be seen...
> 
> Ged.

Hi Ged,

Many thanks for this, it's extremely helpful and does *appear* to do the right 
thing. I'll obviously need to do a lot more testing, but you've set me on the 
right path!

Thanks again
Mark
___

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

Please submit your patches to our Github: 
https://github.com/Cisco-Talos/clamav-devel/pulls

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

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