I am sure we could go back and forth on and off list about these issues
until we are blue in the face. There are many things below that are
incorrect, assumptions or otherwise. I'm not going to respond to every
bullet, but there are some that need to be corrected in order for
perception to be corrected.
On 2/17/16 4:30 PM, Groach wrote:
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:
<snip>
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).
We put out a free engine, free detection, and we have full time
developers dedicated to that free engine. Only the developers of the
engine itself have ClamAV as their fulltime job. The signature writers
are doing many more things, primarily, reverse engineering malware.
<snip>
(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)
I was unaware that we terminated Windows systems. Is this true? Were
systems rendered completely inoperable? Why are we just now hearing
about it? Seems like if it was such a huge issue that the developers of
ClamWin would have contacted me directly, like they normally do.
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.
We do, against TONS of files, but this is my point against we can't test
every file in the world.
* 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.
They don't give their product away.
* 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.
There are a ton of issues we've had to change since the original ClamAV
team left. Part of that has been completely re-writing the entire
backend of every. single. piece. of. ClamAV. From the infrastructure,
to the website, to the mailing system, to the downloads. All, at the
end, to provide a better experience. We appreciate your patience in the
meantime.
<snip>
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.
Again, /entire/ Windows systems? Seems like something we would have
heard about immediately.
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.
Incorrect. We do have QA staff, but for the engine. The signatures are
automatically tested against known clean, but that is what I am saying,
perhaps our "known clean" isn't big enough.
<snip>
We're always making improvements. We'll continue to get better.
--
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
