Re: [Clamav-devel] Code style with commit ffa31264a657618a0e40c51c01e4bfc32e244d13
Yup. I saw the follow-up commit. Thanks!
--
Shawn Webb
Cofounder and Security Engineer of HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
On Mon, Jul 31, 2017 at 09:45:52PM +, Joel Esler (jesler) wrote:
> Shawn,
>
> Thanks for writing in, looks like we???ve already re-formatted this code for
> 99.3, which should be released soon.
>
>
>
> --
> Joel Esler | Talos: Manager | jes...@cisco.com <mailto:jes...@cisco.com>
>
>
>
>
>
>
> > On Jul 20, 2017, at 2:36 PM, Shawn Webb <latt...@gmail.com> wrote:
> >
> > Hey ClamAV Developers,
> >
> > The part of the diff that reads:
> >
> > if ( !(len = sys->read(fh, [0], 256) > 0)) {
> >
> > is a little awkward. I'm wondering if it would be better to be split
> > out. Something like this:
> >
> > len = sys->read(fh, buf, sizeof(buf));
> > if (len <= 0) {
> > ...
> > }
> >
> > That would make the code a bit more readable for future developers. It
> > would also prevent issues in case the size of buf were to ever change in
> > the future.
> >
> > Thanks,
> >
> > --
> > Shawn Webb
> > Cofounder and Security Engineer of HardenedBSD
> >
> > GPG Key ID: 0x6A84658F52456EEE
> > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
> >
> > ___
> > 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
signature.asc
Description: PGP signature
___
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] Code style with commit ffa31264a657618a0e40c51c01e4bfc32e244d13
Hey ClamAV Developers,
The part of the diff that reads:
if ( !(len = sys->read(fh, [0], 256) > 0)) {
is a little awkward. I'm wondering if it would be better to be split
out. Something like this:
len = sys->read(fh, buf, sizeof(buf));
if (len <= 0) {
...
}
That would make the code a bit more readable for future developers. It
would also prevent issues in case the size of buf were to ever change in
the future.
Thanks,
--
Shawn Webb
Cofounder and Security Engineer of HardenedBSD
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE
signature.asc
Description: PGP signature
___
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 scanning
Hey Andrew, The reason why ClamAV failed to detect Zeus when you changed the first byte is because of file magic. When you changed the first byte, you changed the type of file ClamAV recognizes it as. In fact, if it's a PE file, then changing that first byte will cause Windows to not even execute the file. It could be that the 32nd byte carried no significance and therefore ClamAV was still able to detect the file as Zeus. So, when you change random data, you're changing the behavior of the applications that utilize that data, which is completely expected. Thanks, Shawn On Fri, Nov 7, 2014 at 12:11 PM, Andrew Camilleri andrew.camill...@gmail.com wrote: Hi Brandon, Many thanks for your reply. I totally agree with you on EICAR, but this should not happen with Zeus. EICAR was only included as a test case i.e. to make sure that static signatures are being checked... Andrew On 7 November 2014 17:06, Brandon Perry bperry.volat...@gmail.com wrote: EICAR should only ever be detected as is. It is specially made for testing AV, and AV has no use for detecting variations of it. On Fri, Nov 7, 2014 at 11:02 AM, Andrew Camilleri andrew.camill...@gmail.com wrote: Hi! I am totally new to ClamAV, so please excuse my ignorance. I am looking at how AV scanning is done in general, but also specifically in ClamAV. I came across this https://www.mail-archive.com/clamav-devel@lists.clamav.net/msg03096.html post, so I got that bit covered and won't repeat questions. I am working on a WAF and we will use ClamAV for scanning traffic. I am investigating the tolerance in correct classification with respect to changes in malware binaries. To conduct my experiments I picked up the EICAR virus and an actual virus, Zeus, from here https://github.com/Visgean/Zeus. I noticed that if I change a single character in EICAR, ClamAV will fail to detect it; I assume that this is due to a static signature (correct me if I am wrong) associated with this test virus; this seems like a perfectly good result to me. Next thing was to scan Zeus (after a simple git clone) and it picks up a few trojans from the ready built binaries. I then changed the first byte of client32.bin (one of the files that was marked as a trojan) and scanned it. The result was the ClamAV did not recognize the trojan from this simple change. I then changed another byte, the 32nd one to be precise, and scanned it. The result was that ClamAV correctly classifies the binary as a Trojan. I was a little surprised that a change in the first byte would hide the trojan from scanning, especially since the first two bytes are completely useless http://en.wikipedia.org/wiki/Mark_Zbikowski in terms of running a windows binary. My only explanation is that with the change, the file fails some integrity check that ClamAV does, to make sure that the binary is runnable; I am assuming that there isnt a static signature here, otherwise it would not have been picked up with any change. I also did this test with zsb.exe in the repo and I got the same results. Finally I performed the same tests against McAffee and all these changes had no effect i.e. the trojans where always correctly classified. In the case of deltas to EICAR however, McAfee did not recognize the virus. Could you please help me to understand the meaning of these results? Also, is it possible to view the signature of a virus in the signature database? I looked at the doc, but I couldn't find how to do this; but I may have missed it and in that case sorry to ask this! Andrew ___ 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://volatile-minds.blogspot.com -- blog http://www.volatileminds.net -- website ___ 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] [PATCH 1/1] Only bring in execinfo.h if it's available
On Mon, Nov 3, 2014 at 1:55 PM, Bernd Kuhls bernd.ku...@t-online.de wrote: Fixes uclibc build as uclibc does not include backtrace functionality. Compile error was found by an autobuild server, part of the buildroot project: http://autobuild.buildroot.net/results/2a6/2a68aa790b1e8d6fd4dc41f2ab724dfc03b3806d//build-end.log Signed-off-by: Bernd Kuhls bernd.ku...@t-online.de --- clamav-config.h.in |3 +++ configure|2 +- libclamav/mbox.c |2 ++ m4/reorganization/headers.m4 |2 +- 4 files changed, 7 insertions(+), 2 deletions(-) diff --git a/clamav-config.h.in b/clamav-config.h.in index bc13504..1db5d2e 100644 --- a/clamav-config.h.in +++ b/clamav-config.h.in @@ -182,6 +182,9 @@ /* Define to 1 if the system has the type `error_t'. */ #undef HAVE_ERROR_T +/* Define to 1 if you have the execinfo.h header file. */ +#undef HAVE_EXECINFO_H + /* have working file descriptor passing support */ #undef HAVE_FD_PASSING diff --git a/configure b/configure index b8cd3a9..0f7158e 100755 --- a/configure +++ b/configure @@ -14437,7 +14437,7 @@ esac -for ac_header in stdint.h unistd.h sys/int_types.h dlfcn.h inttypes.h sys/inttypes.h sys/times.h memory.h ndir.h stdlib.h strings.h string.h sys/mman.h sys/param.h sys/stat.h sys/types.h malloc.h poll.h limits.h sys/filio.h sys/uio.h termios.h stdbool.h pwd.h grp.h sys/queue.h sys/cdefs.h +for ac_header in stdint.h unistd.h sys/int_types.h dlfcn.h inttypes.h sys/inttypes.h sys/times.h memory.h ndir.h stdlib.h strings.h string.h sys/mman.h sys/param.h sys/stat.h sys/types.h malloc.h poll.h limits.h sys/filio.h sys/uio.h termios.h stdbool.h pwd.h grp.h sys/queue.h sys/cdefs.h execinfo.h do : as_ac_Header=`$as_echo ac_cv_header_$ac_header | $as_tr_sh` ac_fn_c_check_header_mongrel $LINENO $ac_header $as_ac_Header $ac_includes_default diff --git a/libclamav/mbox.c b/libclamav/mbox.c index b0233ae..5d4e5cb 100644 --- a/libclamav/mbox.c +++ b/libclamav/mbox.c @@ -84,7 +84,9 @@ #endif #ifdef HAVE_BACKTRACE +#ifdef HAVE_EXECINFO_H #include execinfo.h +#endif #include syslog.h static voidsigsegv(int sig); diff --git a/m4/reorganization/headers.m4 b/m4/reorganization/headers.m4 index 9b71f33..23016bc 100644 --- a/m4/reorganization/headers.m4 +++ b/m4/reorganization/headers.m4 @@ -1,4 +1,4 @@ -AC_CHECK_HEADERS([stdint.h unistd.h sys/int_types.h dlfcn.h inttypes.h sys/inttypes.h sys/times.h memory.h ndir.h stdlib.h strings.h string.h sys/mman.h sys/param.h sys/stat.h sys/types.h malloc.h poll.h limits.h sys/filio.h sys/uio.h termios.h stdbool.h pwd.h grp.h sys/queue.h sys/cdefs.h]) +AC_CHECK_HEADERS([stdint.h unistd.h sys/int_types.h dlfcn.h inttypes.h sys/inttypes.h sys/times.h memory.h ndir.h stdlib.h strings.h string.h sys/mman.h sys/param.h sys/stat.h sys/types.h malloc.h poll.h limits.h sys/filio.h sys/uio.h termios.h stdbool.h pwd.h grp.h sys/queue.h sys/cdefs.h execinfo.h]) AC_CHECK_HEADER([syslog.h],AC_DEFINE([USE_SYSLOG],1,[use syslog]),) have_pthreads=no Thanks for this patch. Can you please file a bug in our bug tracker at https://bugzilla.clamav.net/? Also, instead of modifying configure (which is generated using GNU autotools), can you modify configure.ac instead? That way your changes will stick whenever we run autoreconf. The way your patch stands right now is that your changes to the configure script would get wiped away whenever anyone runs autoreconf. Thanks, Shawn ___ 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] [PATCH 1/1] Only bring in execinfo.h if it's available
On Mon, Nov 3, 2014 at 2:09 PM, Bernd Kuhls bernd.ku...@t-online.de wrote: Hi, Shawn Webb sw...@sourcefire.com wrote in news:CAO2uJaf5EB5O7=5P_ 6tap6bs_lob87t_-xpffzguxjy4te0...@mail.gmail.com: Thanks for this patch. Can you please file a bug in our bug tracker at https://bugzilla.clamav.net/? https://bugzilla.clamav.net/show_bug.cgi?id=11170 Could you please make this bug report public so the buildroot maintainers can check it while reviewing my patch? Also, instead of modifying configure (which is generated using GNU autotools), can you modify configure.ac instead? I oriented myself at this commit https://github.com/vrtadmin/clamav- devel/commit/0f9ce68529b9ebf4011cb9a19ac1210eb3f7d317 where I was surprised to see a generated ./configure being part of the git repo. That way your changes will stick whenever we run autoreconf. The way your patch stands right now is that your changes to the configure script would get wiped away whenever anyone runs autoreconf. This won´t happen because I patched m4/reorganization/headers.m4 ;) Gotcha. Sorry, I had missed that part of the patch. Thanks! ___ 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] 0.98.5-rc1 milter feedback
On Thu, Oct 16, 2014 at 10:29 PM, Michael G. Janicki m.g.j.jani...@gmail.com wrote: On 10/16/2014 07:00 PM, Shawn Webb wrote: Anytime. I'll investigate further tomorrow. Do you have any steps for reproduction? Hmm reproduction is that it just happens. But, here's how I'm running things. clamav-0.98.5-rc1 running as daemon. Postfix 2.11.2 running as daemon and clamav using clamav-milter to communicate with Postfix via Unix socket. (clamav-milter.conf below). clamav-milter is not SUID. It manages to work with Postfix by being a member of the group which can accessthe necessary Postfix files. I've had it working this way for about a year now so I don't think there's anything too strange about the setup. No major changes in the configuration of either ClamAV or Postfix have been made recently. At one point messages were correctly marked with X-Virus-Scanned and X-Virus-Status as dictated by the AddHeader Replace directive in clamav-milter.conf. At some point during the beta development cycle, the headers just stopped being placed into messages. Sorry I can't be more specific as to when it began, but I know it was apparent in 20140905. Thanks again, Shawn. -- Mike Hey Mike, Some stuff came up on Friday, so I wasn't able to take a look at your issue. I'm going to look at it today. Can you post your clamd.conf, too, please? Thanks, Shawn ___ 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] 0.98.5-rc1 milter feedback
On Mon, Oct 20, 2014 at 11:08 AM, Shawn Webb sw...@sourcefire.com wrote: On Thu, Oct 16, 2014 at 10:29 PM, Michael G. Janicki m.g.j.jani...@gmail.com wrote: On 10/16/2014 07:00 PM, Shawn Webb wrote: Anytime. I'll investigate further tomorrow. Do you have any steps for reproduction? Hmm reproduction is that it just happens. But, here's how I'm running things. clamav-0.98.5-rc1 running as daemon. Postfix 2.11.2 running as daemon and clamav using clamav-milter to communicate with Postfix via Unix socket. (clamav-milter.conf below). clamav-milter is not SUID. It manages to work with Postfix by being a member of the group which can accessthe necessary Postfix files. I've had it working this way for about a year now so I don't think there's anything too strange about the setup. No major changes in the configuration of either ClamAV or Postfix have been made recently. At one point messages were correctly marked with X-Virus-Scanned and X-Virus-Status as dictated by the AddHeader Replace directive in clamav-milter.conf. At some point during the beta development cycle, the headers just stopped being placed into messages. Sorry I can't be more specific as to when it began, but I know it was apparent in 20140905. Thanks again, Shawn. -- Mike Hey Mike, Some stuff came up on Friday, so I wasn't able to take a look at your issue. I'm going to look at it today. Can you post your clamd.conf, too, please? Thanks, Shawn Don't worry about the clamd.conf. I reproduced your issue and I found out commit 3e0b86d05c5a68664b2202c23316a0b75d5bd6ec caused this bug. I reverted that commit. We'll be pushing out an 0.98.5-rc2 in the near future. Thanks, Shawn ___ 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] ClamAV(R): ClamAV 0.98.5 beta has been posted!
On Fri, Jul 18, 2014 at 4:51 PM, Mark Allan markjal...@gmail.com wrote: 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 Hey Mark, I've recently fixed the majority of non-llvm compiler warnings in the master branch of ClamAV's code. These fixes will go out in a future release. Thanks, Shawn ___ 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(R): Compiling OpenSSL For Windows
I haven't tried with LibreSSL. Their first (and second) official release was over the weekend. Your mileage may vary. On Sun, Jul 13, 2014 at 1:48 PM, Steve Basford steveb_cla...@sanesecurity.com wrote: Just a thought.. Will ClamAV use LibreSSL too, as it's supposed to be drop in On 9 July 2014 20:14:01 GMT+01:00, Joel Esler (jesler) jes...@cisco.com wrote: Compiling OpenSSL For Windows In order to support more advanced features planned in future releases, ClamAV has switched to using OpenSSL for hashing. The ClamAV Visual Studio project included with ClamAV's source code requires the OpenSSL distributables to be placed in a specific directory. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ___ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/support/ml ___ 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
On what up-to-date OSs can I find gcc 4.0 in active use? I'll briefly try to recreate the problem in my spare time for you. On Mon, Mar 24, 2014 at 6:22 PM, Dale Walsh d...@daleenterprise.com wrote: When it builds completely under GCC 4.0, I would be more than happy to offer detailed debugging information and dumps that would be beneficial to the project but as it stands, a bug report at bugzilla.clamav.net isn't anything I would consider wasting my time on but you are more than welcome to file the report yourself. It makes no sense for me to file a report as I may use the source files but nothing else, I repackage it so I can build it and rather than listen to stupidity about my method of building being the root of the problem, informing you like other have should be sufficient to warrant an in-depth investigation into the matter. -- Dale On Mar 24, 2014, at 17:32 PM, Steven Morgan wrote: Yes, a dmg issue and an xar issue were mentioned. If the issue(s) remain, please open a bug at bugzilla.clamav.net or send some files or --debug output. On Sun, Mar 23, 2014 at 5:17 PM, Joel Esler (jesler) jes...@cisco.com wrote: Then I am sure the developers would be glad to help figure out the problem and fix it. -- Joel Esler Sent from my iPhone On Mar 22, 2014, at 13:32, Dale Walsh d...@daleenterprise.com wrote: 0.98.1 DMG does not work. -- Dale On Mar 21, 2014, at 09:16 AM, Joel Esler (jesler) 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.com mailto: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
Re: [Clamav-devel] Introducing OpenSSL as a dependency to ClamAV
On Mon, Mar 3, 2014 at 6:32 PM, Brandon Perry bperry.volat...@gmail.comwrote: Hi, The blog post doesn't mention what would now be SSL-ified. Would the dependency be added to enable support for SSL enabled streams using the clams protocol? For now, we plan on using only the hashing functionality in OpenSSL instead of our own hand-rolled hashing code (for MD5, SHA1, and SHA256). The protocol for clamd will remain untouched. Further work we have planned for freshclam will depend on additional functionality in the OpenSSL library. ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
Re: [Clamav-devel] ClamAV 0.98.1 release and .sig file
On Wed, Jan 15, 2014 at 9:56 AM, David F. Skoll d...@roaringpenguin.comwrote: Hi, developers, FYI: I had to rename clamav-0.98.1.tar.sig from the download page at http://sourceforge.net/projects/clamav/files/clamav/0.98.1/ to clamav-0.98.1.tar.gz.sig to get gpg --verify to work. Regards, David. Hey David, A typo was made when copying the file over. The filename of the .sig file is now correct on SourceForge's site. Thanks, Shawn ___ http://lurker.clamav.net/list/clamav-devel.html Please submit your patches to our Bugzilla: http://bugs.clamav.net
