> >I guess around 25-50% of the malware is old, well-known one. So it is
> not
> >that silly to have an outdated AV running to lower the received one.
> >
> >But anyway, we are speaking of stuff which worked. It wasn't perfect,
> but it
> >worked. And in this days the ClamAV staff decided to break it, without
> a
> >rationale close to the point.
> >
> >Isn't this weird? Is clamav a trustable project? This is what a
> sysadmin may
> >end thinking next time he/she installs a new system.
> 
> If ClamAV went the other direction and just left people hanging with a
> false sense of security, all the while happily returning a "yup, not
> infected" to every file with modernish malware in it, there would be
> just as much "can I trust 'em?"

Dave, look. These are few files scanned with 0.96:

        79504-Jesus.1.exe: 79504-Jesus.1.exe.UNOFFICIAL FOUND
        Contract.1.exe: Contract.1.exe.UNOFFICIAL FOUND
        Contract.2.exe: Contract.2.exe.UNOFFICIAL FOUND
        instructions.1.exe: instructions.1.exe.UNOFFICIAL FOUND
        Instructions.1.exe: Instructions.1.exe.UNOFFICIAL FOUND
        Instructions.2.exe: Instructions.2.exe.UNOFFICIAL FOUND
        Instructions.3.exe: Instructions.3.exe.UNOFFICIAL FOUND
        Instructions.4.exe: Instructions.5.exe.UNOFFICIAL FOUND
        Instructions.5.exe: Instructions.5.exe.UNOFFICIAL FOUND
        Instructions.6.exe: Instructions.6.exe.UNOFFICIAL FOUND
        officexp-KB910721-FullFile-ENU.1.exe:
officexp-KB910721-FullFile-ENU.1.exe.UNOFFICIAL FOUND
        password.1.exe: password.1.exe.UNOFFICIAL FOUND
        settings.1.exe: settings.1.exe.UNOFFICIAL FOUND
        settings.2.exe: settings.2.exe.UNOFFICIAL FOUND
        settings.3.exe: settings.3.exe.UNOFFICIAL FOUND
        settings.5.exe: settings.5.exe.UNOFFICIAL FOUND
        settings.6.exe: settings.6.exe.UNOFFICIAL FOUND
        settings.7.exe: settings.7.exe.UNOFFICIAL FOUND
        settings.exe: settings.exe.UNOFFICIAL FOUND
        setup.1.exe: setup.1.exe.UNOFFICIAL FOUND
        setup.2.exe: setup.2.exe.UNOFFICIAL FOUND
        UPS_invoice_2794.1.exe: UPS_invoice_2794.1.exe.UNOFFICIAL FOUND

I reported to ClamAV each of them. The oldest one is from February, 3. They
are still not detected unless via an .hdb.

This is F-Prot, intead:

[Found security risk] <W32/FakeAV.UE (exact)>   Contract.1.exe
[Found trojan] <W32/Trojan3.BRX (exact)>        Contract.2.exe
[Found trojan] <W32/Trojan3.BSC (exact)>        instructions.1.exe
[Found trojan] <W32/Trojan2.MGAA (exact)>       Instructions.1.exe
[Found trojan] <W32/Trojan2.MFZZ (exact)>       Instructions.2.exe
[Found trojan] <W32/Trojan3.BSD (exact)>        Instructions.3.exe
[Found trojan] <W32/Trojan2.MGAC (exact)>       Instructions.4.exe
[Found trojan] <W32/Trojan2.MGAC (exact)>       Instructions.5.exe
[Found trojan] <W32/Trojan3.BSG (exact)>        Instructions.6.exe
[Found virus] <W32/Bredolab.3!Generic>  officexp-KB910721-FullFile-ENU.1.exe
[Found virus] <W32/Bredolab.3!Generic>  settings.1.exe
[Found trojan] <W32/Trojan2.MFUH (exact)>       settings.2.exe
[Found trojan] <W32/Trojan3.BQZ (exact)>        settings.3.exe
[Found downloader] <W32/Bredolab.DT (exact)>    settings.5.exe
[Found trojan] <W32/Trojan3.BRE (exact)>        settings.6.exe
[Found security risk] <W32/FakeAV.TZ (exact)>   settings.7.exe
[Found downloader] <W32/Bredolab.DR (exact)>    settings.exe
[Found trojan] <W32/Trojan3.BSR (exact)>        setup.1.exe
[Found trojan] <W32/Trojan2.MFZW (exact)>       UPS_invoice_2794.1.exe

It detect all but the most recent ones. So, who should I trust the most with
respect to this?

Instead, I preferred ClamAV. And I'm still helping the way I can: I'm
reporting malware, and now I'm debating on the 0.96 case. And I'm really sad
when I discover that a move could put in danger the reputability of the
whole project.

Because I'm a bit old. And I like freedom. And I prefer to have to bother
with mailing lists and bulletin reports and have the control of systems,
instead of put my work in the hand of people who could change the rules at
will.

An open-source project is not supposed to change rules at will. The license
itself of open source software is often oriented toward this view, such that
it guarantees people to keep using software they already got, even when the
project becomes a completely commercial one.

A remote kill is very dangerous to a commercially-oriented product, but may
be a real disaster to an open-source one. Because the open-source idea is
all based on freedom.

The ClamAV team can't act the way it did and not risk to be censured by the
open-source community.

If people blames you and feels betrayed by you, it is not a "sysadm
matter"...

Giampaolo


> 
> As far as whether or not you can trust ClamAV, if this was sprung upon
> server operators without notice, that might be a consideration.  It
> wasn't.
> 
> The difference is that this screaming gets attention and gets the
> attention of incompetently managed server operators so that things get
> fixed.

_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml

Reply via email to