Last response LABELLED IN BRACKETS for reference in my reply below
On 17/02/2016 21:06, Joel Esler wrote:
Let's try this inline-reply thing again, apologies for last time.
On 2/17/16 12:15 PM, Groach wrote:
Hello Joel
I mentioned the Clamwin forum moderators to show that loyal people are
equally dismayed. I am well aware that you guys do not view the forum
and probably only view this mailing list but (to my own cost - as I am
about to find out with this post) this is not the easiest platform to
view and use and the world is more used to a BBS-type forum;
consequently people go to those for advice and often things can be seen
there more than what you would find in this mailing-list thingy.
(A) This mailing list thingy has been here since the beginning of ClamAV,
and is the best method of communication for us as the data is put into
our inbox. As opposed to us having to remember to go log into a website
every day. These mailing lists have over 10 years of history, and they
seem to be working quite well.
(A) They said that about the engine car before internal combustionb
engines were introduced. Even so, they decided to adopt other
technologies.
I am
also aware thatg it is multi-platform and that was the whole thing that
prompted my 'enquiry': the muti-platform consciousness seem to have
forgotten the impact that can be felt on Wiondows platform if you dont
take care.
(B) ClamWin takes the ClamAV engine and repackages it for Windows. As I am
sure you are all well aware. We can't monitor the forums/mailing lists
of every subproject of ClamAV. I understand your frustration, but it's
just not something I can feasibly do.
(B) Really, maximum of 5 minutes per DAY probably and only about 2 or 3
official forums (if that). Not even needing responses from your team,
just your team to 'look in' to see if there is anything they should know
and learn about there own product (and mishaps).
Quote: "So when FPs are found, they are remediated as fast as we can
get to them."
An interesting response after Ive pointed out 3 examples of FPs not
being remedied despite me sending them to you - one of them 17 months
old. Could you qualify the term "as fast as we get them..." ? I
REGULARLY upload FP's to CLamAV portal and it takes TOO long. Sure you
might have internal reasons as to why it takes longer but at the same
time people need to be given an expectation of what to expect in order
they can make a reasonable consideration as to risk (or inconvenience)
to their own systems.
(C) What you gave me were not FPs. We didn't alert on them. So, what I
think you mean is FN (False Negative), which is constructive and we can
generate detection for those files. We did have several recent issues
with FP reporting on the website, and those have been fixed. We
apologize for any inconvenience during the outage.
(C) Acknowledged, I got confused and hasty in giving my examples. Even
so, my original point was about slow response times to FP's and slow (in
some cases ZERO) response to malware submissions via your website.
(D) Quote: "Not to say that your concerns aren’t noted, but generating
ClamAV detection is takes longer."
And this is the point of my mentioning it taking too long
Understood.
(D) Acknowledged, understood but does it matter or change anything?
Quote: "ClamAV should trust the certificate of the file (if you have it
installed correctly) and ignore those files "
Yes, but you cant. Clearly ASSUMING such 'safety measures' doesnt work
which brought peoples machines to their knees last week. An
alternative, safer approach is needed.
(E) This problem (conviction of signed files) is exactly the reason we
created the feature of Certificate Trust. I understand and comprehend
what you are saying, I'm not ignoring you. But you have to understand
that we expect ClamAV to work a certain way. We ship it with a
recommended configuration, on by default, etc. What people do with it
once it leaves ClamAV.net, we can't, and won't control. If you'd like
to use a client that we make, Immunet is that suggestion. It has the
same cost as ClamAV -- Free.
(E) If 'your certain way' allows the termination of windows systems and
services due to shoddy signature processes, then maybe it should be
reconsidered. (And yes, if its killing systems as it did, its a SHODDY
process). It isnt Clamwin or any window ports of Clam that are the
problem, it is the CLAM SIGNATURES that they all use (which is designed
by you and the point of contention here)
And the comedy value:
Quote: " would love to have more contributions from the community in
order to increase coverage."
You are not going to increase coverage whilst you ignore the workings of
windows, its flaws, its popularity and the sensitivity it has to your
signatures. Only by accepting these elements, and modifying the focus
on to them such as....:
* better testing before release of signatures
(F) Sorry you feel it was comedy. What, specifically, do we need to test
against? I can see if we can't get those files added to the clean file
repository that we do False Positive testing against before the rules
are shipped.
(F) Before issuing a signature, TEST IT! Apply it to a dummy run of a
disk containing known windows and popular softwares.
* not assume all windows files are signed (genuine programs dont
necessarily come from Microsoft)
(G) [a] Nor do we have a copy of every file that you *may* download on the
Internet to test against. Again, I'm understanding what you are saying,
but there are realities in play that are difficult to overcome
completely. Like the ability to have every copy of every file that may
be an FP, ever.
(G) Never said you need to against the worlds software. Also, I dont
know about writing signatures or whats involved. I do know that other
AV solutions have not been so catastrophic and that indeed sometimes
they can be a bit rubbish. What do they know that you dont? With that
in mind, I ask the question: What is worse a system infected with a
malware file or a system that wont run in the first place because the
slap-dash signature makers removed all standard genuine DLL's? However
you look at it, there must be tighter controls to avoid this happening
again. And without acknowledging this, and acting accordingly, then
there is no chance of it never happening again.
* SPEEDIER response to FP's
(H) Understood. Your concern is noted, is being addressed, and due to a
recent large problem, we've had a backlog of things to catch up to. We
apologize for the error.
(H) But I hope you are not suggesting slow response is due to recent
changes/projects within your team/structure? Response to FPs has been
slow (and often needing repeat submission reports over and over) for at
least 4 years Ive been using Clam.
* change of Focus on developement: get the existing products currently
in use more stable (which includes ClamAV) rather than concetrate on
fancy websites and rewrites of products that dont currently have so many
problems.
(I) You are talking about completely separate problems, teams, and products.
Surely you don't believe that the web team writes ClamAV signatures do
you? There doesn't need to be a focus change on development. Existing
efforts need to be modified to account for your concerns. See [a]
(I) Glad to hear the acknowledgement.
.....will make it more popular instead of losing coverage.
Im not sure from what I have read that there really is a gasp of the
situation and consequently that anything will change, just
acknowledgements and explanations why it is to be so.
(J) I've heard your concerns. You may think I don't grasp what you are
saying, but I do.
(J) Again, glad to hear.
For sure nothing will change for disgruntled users that have lowered
their reliance or moved away from Clam flavours.
That is unfortunate.
Yep.
Suggestion: given that there is a Clamwin flavour, and forum, then
maybe someone would like to signup and occasionally pop in day to day to
see what people are saying or thinking. How about it?
I believe I addressed this above.
--
Joel Esler
Manager, Threat Intelligence Team & Open Source
Talos Group
http://www.talosintel.com
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
Look, I am not here to argue and counter-argue - Ive been around long
enough to know that when a 'project' has been formulated, a plan of
action and methodology decided and procedures implemented, it is VERY
difficult for anyone outside of the project to suggest changes that will
be taken on board. (Principal, sometimes company rules and often
stubbornness prevents it). Im sure the quality of the signatures will
not change (despite a catastrophic example of why they should last
week), I'm sure the speed of them wont change (despite examples given of
malware that needs immunising and is over 17 months old, and Im sure
that voices like mine merely serve to strengthen the teams insistance
that "we are doing the right thing" and simply cannot stand on the
outside and look in and see another picture. (Heres a picture for you:
No other anti-virus software last week disabled entire windows systems.
See (F) above. But thats ok, Clam are still doing things "right and the
only way they have decided to do it". Just as well CISCO do not apply
Clam's Quality Assurance to their company products otherwise the worlds
internet infrastructure would be crumbling.
My voice was made on behalf of those poor unfortunates out there that
suffered last week, and have been annoyed day-after-day, week in week
out, like me, with the sloppy signatures and their consequences. ITs
just how I am. (If I didnt say anything, then I cant expect my voice to
be heard (...acknowledging that being "heard" is not the same as being
"listened to"). And then I simply couldnt complain.
Now, the rest is for you guys to continue your work in whatever
direction you have chosen to do it.
Kind regards
_______________________________________________
Help us build a comprehensive ClamAV guide:
https://github.com/vrtadmin/clamav-faq
http://www.clamav.net/contact.html#ml
