Mailing List Archive

Em 14/03/2019 15:26, instaham--- via clamav-users escreveu:
> Hi everybody,
>
> Or is some kind of verification of the data happening in the
> background (such as apt in Debian is using GPG)?

    the databases are digitally signed, and any modification, such in a
man-in-the-middle attack, would break the signature and freshclam would
refuse to run the files.

    http is not *ALWAYS* insecure, it's just not encrypted by the
protocol itself.

--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it




_______________________________________________

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


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

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

Hello,

You can read this thread and make your own opinion :

https://lists.clamav.net/pipermail/clamav-users/2014-December/001129.html


Le 14/03/2019 à 19:26, instaham--- via clamav-users a écrit :
> Hi everybody,
>
> I assume that when I run "freshclam", the virus database is updated
> over an unencrypted and plain http connection.
>
> The default configuration doesn't seem to use https.
>
> Isn't this kind of insecure (Man-in-the-middle-attacks, etc.)?
>
> Are there any https mirrors available and, if yes, how can I configure
> ClamAV to use these instead?
>
> Or is some kind of verification of the data happening in the
> background (such as apt in Debian is using GPG)?
>
> Hope you can help me with this. Thanks
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml

--
Cordialement / Best regards,

Arnaud Jacques
Gérant de SecuriteInfo.com

Téléphone : +33-(0)3.44.39.76.46
E-mail : aj@securiteinfo.com
Site web : https://www.securiteinfo.com
Facebook : https://www.facebook.com/pages/SecuriteInfocom/132872523492286
Twitter : @SecuriteInfoCom

Securiteinfo.com
La Sécurité Informatique - La Sécurité des Informations.
266, rue de Villers
60123 Bonneuil en Valois


_______________________________________________

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


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

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

Leonardo Rodrigues wrote:
>     the databases are digitally signed, and any modification, such in
> a man-in-the-middle attack, would break the signature and freshclam
> would refuse to run the files.

Sounds good. Can you please explain how this works in detail?

Apt places GPG keys in the system and uses them to verify downloaded
data.

It doesn't seem that ClamAV placed any GPG keys in my system. So how is
the verification happening?

Thanks

_______________________________________________

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


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

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

Hello,

Le 15/03/2019 à 16:04, instaham--- via clamav-users a écrit :
> Leonardo Rodrigues wrote:
>>     the databases are digitally signed, and any modification, such in
>> a man-in-the-middle attack, would break the signature and freshclam
>> would refuse to run the files.
>
> Sounds good. Can you please explain how this works in detail?
>
> Apt places GPG keys in the system and uses them to verify downloaded
> data.
>
> It doesn't seem that ClamAV placed any GPG keys in my system. So how
> is the verification happening?

Read on
https://lists.clamav.net/pipermail/clamav-users/2018-October/007053.html :

"

The .cvd files have an internal cryptographic signature that's
checked by freshclam and clamd/clamscan. If freshclam and/or clamd
accepts the files, you can be assured they are official and
unmodified. This is built into clam; no external tools are called.

"

Btw, it is working for official signatures. 3rd party signatures provide
hash based checksum files.

--
Cordialement / Best regards,

Arnaud Jacques
Gérant de SecuriteInfo.com

Téléphone : +33-(0)3.44.39.76.46
E-mail : aj@securiteinfo.com
Site web : https://www.securiteinfo.com
Facebook : https://www.facebook.com/pages/SecuriteInfocom/132872523492286
Twitter : @SecuriteInfoCom

Securiteinfo.com
La Sécurité Informatique - La Sécurité des Informations.
266, rue de Villers
60123 Bonneuil en Valois

Op Vrijdag, 15-03-2019 om 16:04 schreef instaham--- via clamav-users:
> Leonardo Rodrigues wrote:
> >     the databases are digitally signed, and any modification, such in
> > a man-in-the-middle attack, would break the signature and freshclam
> > would refuse to run the files.
>
> Sounds good. Can you please explain how this works in detail?
>
> Apt places GPG keys in the system and uses them to verify downloaded
> data.
>
> It doesn't seem that ClamAV placed any GPG keys in my system. So how is
> the verification happening?
>

I wonder why the http/https discussion is still relevant. Almost all sites use https now, http is getting slowly banned and a lot of companies just don't want to allow incoming http traffic towards a server. Certifcates cost nothing anymore (you have free ones), so that's no longer an issue too. And the cpu issue might've been relevant years ago, but it shouldn't be now (offloading https to a high-performant frontend server can help if you really have issues).
Just my 2 cents here ...

Franky


_______________________________________________

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


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

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

For what it's worth, one of the tasks we're working on for 0.102 is https support for freshclam.

It's more than just adding an "s" to the URL. The plan is to make libcurl a hard requirement for ClamAV, which will also mean including libcurl on Windows. Then we'll have to rewrite the freshclam code to use libcurl instead of doing the http 1.0 connections the hard way. This should give us http 1.1 and 2.0 support, as well has https support, and will make it possible to build clamsubmit for Windows.

No one is arguing with you because they don't want https support. However, as noted in previous conversations, we're comfortable with the security of plaintext/http connects because of how the databases are verified. We do agree though, that https would be desirable.

Micah


?On 3/15/19, 11:54 AM, "clamav-users on behalf of Franky Van Liedekerke via clamav-users" <clamav-users-bounces@lists.clamav.net on behalf of clamav-users@lists.clamav.net> wrote:

Op Vrijdag, 15-03-2019 om 16:04 schreef instaham--- via clamav-users:
> Leonardo Rodrigues wrote:
> > the databases are digitally signed, and any modification, such in
> > a man-in-the-middle attack, would break the signature and freshclam
> > would refuse to run the files.
>
> Sounds good. Can you please explain how this works in detail?
>
> Apt places GPG keys in the system and uses them to verify downloaded
> data.
>
> It doesn't seem that ClamAV placed any GPG keys in my system. So how is
> the verification happening?
>

I wonder why the http/https discussion is still relevant. Almost all sites use https now, http is getting slowly banned and a lot of companies just don't want to allow incoming http traffic towards a server. Certifcates cost nothing anymore (you have free ones), so that's no longer an issue too. And the cpu issue might've been relevant years ago, but it shouldn't be now (offloading https to a high-performant frontend server can help if you really have issues).
Just my 2 cents here ...

Franky


_______________________________________________

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


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

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



_______________________________________________

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


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

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

Hi there,

On Fri, 15 Mar 2019, Franky Van Liedekerkewrote:

> Certifcates cost nothing ...

CPU cycles don't.

--

73,
Ged.

_______________________________________________

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


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

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

Em 15/03/2019 14:39, G.W. Haywood via clamav-users escreveu:
> Hi there,
>
> On Fri, 15 Mar 2019, Franky Van Liedekerkewrote:
>
>> Certifcates cost nothing ...
>
> CPU cycles don't.
>

    developers time do cost their ... time, basically. How about
contributing with the code instead of blaming ? That would be useful.
Discussing about http x https, believing that http is always insecure,
is useless.




--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it




_______________________________________________

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


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

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

I had this question a while back, and this is what I was able to track down:

The files are not signed via any PKI trusted by your system, but rather by a specific RSA key that is trusted by the code itself. If you look in libclamav/dsig.c, there is an implementation of RSA inspired by http://www.erikyyy.de/yyyRSA/, and the public parameters of an RSA key are hard-coded in that file.

- Luke

On Mar 15, 2019, at 11:04 AM, instaham--- via clamav-users <clamav-users@lists.clamav.net<mailto:clamav-users@lists.clamav.net>> wrote:

Leonardo Rodrigues wrote:
the databases are digitally signed, and any modification, such in
a man-in-the-middle attack, would break the signature and freshclam
would refuse to run the files.

Sounds good. Can you please explain how this works in detail?

Apt places GPG keys in the system and uses them to verify downloaded data.

It doesn't seem that ClamAV placed any GPG keys in my system. So how is the verification happening?

Thanks

_______________________________________________

clamav-users mailing list
clamav-users@lists.clamav.net<mailto:clamav-users@lists.clamav.net>
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.clamav.net_mailman_listinfo_clamav-2Dusers&d=DwIGaQ&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=kBR20qCRpw_COsjokFR0DeDlBjL9wibcGzBBJtTubwc&m=Am934oxvGJUzY7zjAMr7LsAoh1QKFMW_pCV9H3D-XAY&s=32-aBf3kPc7KjmlElZ_x56PEUwoQoMgpezWIVZtdnHc&e=


Help us build a comprehensive ClamAV guide:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_vrtadmin_clamav-2Dfaq&d=DwIGaQ&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=kBR20qCRpw_COsjokFR0DeDlBjL9wibcGzBBJtTubwc&m=Am934oxvGJUzY7zjAMr7LsAoh1QKFMW_pCV9H3D-XAY&s=iFxlVSJ2ckNdLBVhTcgERy1eec3jp4yRZnbzcDlxDrE&e=

https://urldefense.proofpoint.com/v2/url?u=http-3A__www.clamav.net_contact.html-23ml&d=DwIGaQ&c=9Hv6XPedRSA-5PSECC38X80c1h60_XWA4z1k_R1pROA&r=kBR20qCRpw_COsjokFR0DeDlBjL9wibcGzBBJtTubwc&m=Am934oxvGJUzY7zjAMr7LsAoh1QKFMW_pCV9H3D-XAY&s=ncrTAyYChjf7wK4-1nqUY9gKjgolYUlQpjB0FKybCqw&e=

I'm sorry if I lead you to believe that I don't know development costs time. I'm a developer myself and contributed to lots of open source projects in the past (openldap, mail, squid, nroe, zabbix, ooenmoko and others).
I just can't contribute to every project and currently I am happy with the promised https support in a future version (and with the http support now).

Franky

----- Oorspronkelijk bericht -----
Van: Leonardo Rodrigues <leolistas@solutti.com.br>
Aan: clamav-users@lists.clamav.net
Verzonden: Fri, 15 Mar 2019 19:56:14 +0100 (CET)
Onderwerp: Re: [clamav-users] Database updated over unencrypted connection?

Em 15/03/2019 14:39, G.W. Haywood via clamav-users escreveu:
> Hi there,
>
> On Fri, 15 Mar 2019, Franky Van Liedekerkewrote:
>
>> Certifcates cost nothing ...
>
> CPU cycles don't.
>

    developers time do cost their ... time, basically. How about
contributing with the code instead of blaming ? That would be useful.
Discussing about http x https, believing that http is always insecure,
is useless.




--


Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br

Minha armadilha de SPAM, NÃO mandem email
gertrudes@solutti.com.br
My SPAMTRAP, do not email it




_______________________________________________

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


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

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


_______________________________________________

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


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

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

On 2019-03-15 09:53, Franky Van Liedekerke via clamav-users wrote:
> I wonder why the http/https discussion is still relevant. Almost all sites use https now, http is getting slowly banned and a lot of companies just don't want to allow incoming http traffic towards a server. Certifcates cost nothing anymore (you have free ones), so that's no longer an issue too. And the cpu issue might've been relevant years ago, but it shouldn't be now (offloading https to a high-performant frontend server can help if you really have issues).
> Just my 2 cents here ...

One other consideration here is historical: ClamAV relied on donated
mirrors, some of which struggled to keep a bare minimum configuration
working. Deploying HTTPS and getting the mirror operators to keep up
with certificates, secure TLS configuration and other details would add
a lot more load to what I understand was already a challenge for the
ClamAV team.

The situation has changed somewhat today with Cloudflare's involvement
as there would only be one party involved in deploying certificates to
all nodes, and a party that can sign and maintain certificates
themselves completely automatically at that.

As noted elsewhere in the thread, freshclam work needs to be done before
freshclam itself could actually use this capability.

_______________________________________________

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


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

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

Arnaud Jacques wrote:
> The .cvd files have an internal cryptographic signature that's
> checked by freshclam and clamd/clamscan. If freshclam and/or clamd
> accepts the files, you can be assured they are official and
> unmodified. This is built into clam; no external tools are called.

Thanks, this is basically what I wanted to know. Good to hear that
there's a verification of the data happening.

Thanks to everybody who shared thoughts and knowledge on this topic.

_______________________________________________

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


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

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

Looking at the PiperMail thread about how ClamAV verifies CVD
signatures, I see two things that concern me.

First, it says it uses "an implementation of RSA inspired by
http://www.erikyyy.de/yyyRSA/". How well has this implementation been
vetted? I'm not a crypto expert (by any means), but people like Bruce
Schneier stress that doing crypto right is difficult, and that there
are many possibilities for subtle errors that cause the encryption to
be weak. Witness the non-random seed that turned up in Debian a few
years ago, or the recent Elliptic Curve "scandal".

Second, if the decryption key is baked in to ClamAV, what protocol is
there to update it in case the encryption key is compromised? I presume
it would require a ClamAV software update, but such an update would be
critical, and the current out-of-date notice wouldn't cut it. In fact
the fake CVD might even lie about the need for a software update.

I'm not saying that HTTPS would answer these questions, but perhaps a
more robust security model would be desirable.


On Fri, 15 Mar 2019 16:47:02 +0100
Arnaud Jacques <webmaster@securiteinfo.com> wrote:

> Hello,
>
> Le 15/03/2019 à 16:04, instaham--- via clamav-users a écrit :
> > Leonardo Rodrigues wrote:
> >>     the databases are digitally signed, and any modification, such
> >> in a man-in-the-middle attack, would break the signature and
> >> freshclam would refuse to run the files.
> >
> > Sounds good. Can you please explain how this works in detail?
> >
> > Apt places GPG keys in the system and uses them to verify
> > downloaded data.
> >
> > It doesn't seem that ClamAV placed any GPG keys in my system. So
> > how is the verification happening?
>
> Read on
> https://lists.clamav.net/pipermail/clamav-users/2018-October/007053.html :
>
> "
>
> The .cvd files have an internal cryptographic signature that's
> checked by freshclam and clamd/clamscan. If freshclam and/or clamd
> accepts the files, you can be assured they are official and
> unmodified. This is built into clam; no external tools are called.
>
> "
>
> Btw, it is working for official signatures. 3rd party signatures
> provide hash based checksum files.
>

_______________________________________________

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


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

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

As Micah said, when we roll out the new version of freshclam that supports https, this will be a done deal. Technically, https on the cdn is available now. Freshclam just doesn’t know how to use it. We want people to freshclam. As the way it functions does so in a way that reduces load on the mirrors and allows us to plan and predict how updating will work. Not something we can do if people are using wget or curl to download the entire main, daily, safebrowsing, and bytecode cvd’s every second (looking at you, person in Japan).

It’s not a question of if we are going to do it. It’s not even a question of when. We know we are and we know when. There are only so many hours in the day, and we haven’t gotten to this one yet. This debate, while interesting is essentially pointless. We’re going to do it.

Sent from my ? iPhone

> On Mar 17, 2019, at 21:25, Paul Kosinski via clamav-users <clamav-users@lists.clamav.net> wrote:
>
> Looking at the PiperMail thread about how ClamAV verifies CVD
> signatures, I see two things that concern me.
>
> First, it says it uses "an implementation of RSA inspired by
> http://www.erikyyy.de/yyyRSA/". How well has this implementation been
> vetted? I'm not a crypto expert (by any means), but people like Bruce
> Schneier stress that doing crypto right is difficult, and that there
> are many possibilities for subtle errors that cause the encryption to
> be weak. Witness the non-random seed that turned up in Debian a few
> years ago, or the recent Elliptic Curve "scandal".
>
> Second, if the decryption key is baked in to ClamAV, what protocol is
> there to update it in case the encryption key is compromised? I presume
> it would require a ClamAV software update, but such an update would be
> critical, and the current out-of-date notice wouldn't cut it. In fact
> the fake CVD might even lie about the need for a software update.
>
> I'm not saying that HTTPS would answer these questions, but perhaps a
> more robust security model would be desirable.
>
>
> On Fri, 15 Mar 2019 16:47:02 +0100
> Arnaud Jacques <webmaster@securiteinfo.com> wrote:
>
>> Hello,
>>
>>> Le 15/03/2019 à 16:04, instaham--- via clamav-users a écrit :
>>> Leonardo Rodrigues wrote:
>>>> the databases are digitally signed, and any modification, such
>>>> in a man-in-the-middle attack, would break the signature and
>>>> freshclam would refuse to run the files.
>>>
>>> Sounds good. Can you please explain how this works in detail?
>>>
>>> Apt places GPG keys in the system and uses them to verify
>>> downloaded data.
>>>
>>> It doesn't seem that ClamAV placed any GPG keys in my system. So
>>> how is the verification happening?
>>
>> Read on
>> https://lists.clamav.net/pipermail/clamav-users/2018-October/007053.html :
>>
>> "
>>
>> The .cvd files have an internal cryptographic signature that's
>> checked by freshclam and clamd/clamscan. If freshclam and/or clamd
>> accepts the files, you can be assured they are official and
>> unmodified. This is built into clam; no external tools are called.
>>
>> "
>>
>> Btw, it is working for official signatures. 3rd party signatures
>> provide hash based checksum files.
>>
>
> _______________________________________________
>
> clamav-users mailing list
> clamav-users@lists.clamav.net
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/vrtadmin/clamav-faq
>
> http://www.clamav.net/contact.html#ml

My comments were mainly concerning CVD *validation*, not HTTPS.

Debian updates (for example) are delivered via plain HTTP, but they are
validated using standard GPG tools. Firefox (ESR) updates are handled
similarly (up to SHA512 hash, validated using GPG). I have more
confidence in standard GPG tools than ClamAV's current one-off scheme.

In any case, transporting ClamAV's CVD files over HTTPS secures the
transport, but doesn't necessarily validate the content: a rogue source
could perhaps deliver fake CVDs over HTTPS (perhaps via some form of
DNS hijacking, such as MITM DNS). GPG-equivalent signing would help
defend against this.

If only HTTPS is used, then at least ClamAV should check the server
certificate: e.g. against a built-in list. (Can libcurl do this?)

But ... some organizations MITM all external HTTPS these days. I think
that would cause server certificate checking to fail. (And again make
fake CVDs a possibility.)



On Mon, 18 Mar 2019 02:09:33 +0000
"Joel Esler (jesler)" <jesler@cisco.com> wrote:

> As Micah said, when we roll out the new version of freshclam that
> supports https, this will be a done deal. Technically, https on the
> cdn is available now. Freshclam just doesn’t know how to use it. We
> want people to freshclam. As the way it functions does so in a way
> that reduces load on the mirrors and allows us to plan and predict
> how updating will work. Not something we can do if people are using
> wget or curl to download the entire main, daily, safebrowsing, and
> bytecode cvd’s every second (looking at you, person in Japan).
>
> It’s not a question of if we are going to do it. It’s not even a
> question of when. We know we are and we know when. There are only
> so many hours in the day, and we haven’t gotten to this one yet.
> This debate, while interesting is essentially pointless. We’re going
> to do it.
>
> Sent from my ? iPhone
>
> > On Mar 17, 2019, at 21:25, Paul Kosinski via clamav-users
> > <clamav-users@lists.clamav.net> wrote:
> >
> > Looking at the PiperMail thread about how ClamAV verifies CVD
> > signatures, I see two things that concern me.
> >
> > First, it says it uses "an implementation of RSA inspired by
> > http://www.erikyyy.de/yyyRSA/". How well has this implementation
> > been vetted? I'm not a crypto expert (by any means), but people
> > like Bruce Schneier stress that doing crypto right is difficult,
> > and that there are many possibilities for subtle errors that cause
> > the encryption to be weak. Witness the non-random seed that turned
> > up in Debian a few years ago, or the recent Elliptic Curve
> > "scandal".
> >
> > Second, if the decryption key is baked in to ClamAV, what protocol
> > is there to update it in case the encryption key is compromised? I
> > presume it would require a ClamAV software update, but such an
> > update would be critical, and the current out-of-date notice
> > wouldn't cut it. In fact the fake CVD might even lie about the need
> > for a software update.
> >
> > I'm not saying that HTTPS would answer these questions, but perhaps
> > a more robust security model would be desirable.

_______________________________________________

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


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

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

I suspect we all read your concerns, but I have a problem understanding how that translates into defining a true vulnerability and the resultant level of severity.

Assuming someone goes to all the trouble of figuring out what the hard coded public key embedded in ClamAV is, signs a fake .cvd or .cdiff, successfully, and breaches a network to conduct an MITM attack during an update, the only consequences I can imagine are that it crashes a clam scanning process or injects signatures designed to disable the OS. I suppose a targeted Nation State attack against a critical facility might make all that worth the effort, but not against normal users.

I realize that things can change at a moments notice, but the current method appears to have stood the test of time. You have speculated that that method is vulnerable based on a generality “that doing crypto right is difficult” without being able to judge for us whether GPG is any better. That's not really enough, IMHO, for a formal bug or vulnerability report.

I suspect that the Talos community team has access to the appropriate Cisco resources able to properly vet the current methodology and if changes are necessary to properly prioritize needed changes.

I'm not trying to dissuade you from bringing it up here and I’m sure the team appreciates hearing your views as well. My reading of the situation is that they already understand your concerns, but needed to also respond to those pushing for https. The latter issue has already been worked and on their timeline. It remains to be seen whether yours requires attention or not.

Sent from my iPad

-Al-

On Mar 20, 2019, at 17:49, Paul Kosinski via clamav-users <clamav-users@lists.clamav.net> wrote:
> My comments were mainly concerning CVD *validation*, not HTTPS.
>
> Debian updates (for example) are delivered via plain HTTP, but they are
> validated using standard GPG tools. Firefox (ESR) updates are handled
> similarly (up to SHA512 hash, validated using GPG). I have more
> confidence in standard GPG tools than ClamAV's current one-off scheme.
>
> In any case, transporting ClamAV's CVD files over HTTPS secures the
> transport, but doesn't necessarily validate the content: a rogue source
> could perhaps deliver fake CVDs over HTTPS (perhaps via some form of
> DNS hijacking, such as MITM DNS). GPG-equivalent signing would help
> defend against this.
>
> If only HTTPS is used, then at least ClamAV should check the server
> certificate: e.g. against a built-in list. (Can libcurl do this?)
>
> But ... some organizations MITM all external HTTPS these days. I think
> that would cause server certificate checking to fail. (And again make
> fake CVDs a possibility.)
>
> On Mon, 18 Mar 2019 02:09:33 +0000
> "Joel Esler (jesler)" wrote:
>> As Micah said, when we roll out the new version of freshclam that
>> supports https, this will be a done deal. Technically, https on the
>> cdn is available now. Freshclam just doesn’t know how to use it. We
>> want people to freshclam. As the way it functions does so in a way
>> that reduces load on the mirrors and allows us to plan and predict
>> how updating will work. Not something we can do if people are using
>> wget or curl to download the entire main, daily, safebrowsing, and
>> bytecode cvd’s every second (looking at you, person in Japan).
>>
>> It’s not a question of if we are going to do it. It’s not even a
>> question of when. We know we are and we know when. There are only
>> so many hours in the day, and we haven’t gotten to this one yet.
>> This debate, while interesting is essentially pointless. We’re going
>> to do it.
>>
>> Sent from my ? iPhone
>>
>> On Mar 17, 2019, at 21:25, Paul Kosinski via clamav-users
>> <clamav-users@lists.clamav.net> wrote:
>>> Looking at the PiperMail thread about how ClamAV verifies CVD
>>> signatures, I see two things that concern me.
>>>
>>> First, it says it uses "an implementation of RSA inspired by
>>> http://www.erikyyy.de/yyyRSA/". How well has this implementation
>>> been vetted? I'm not a crypto expert (by any means), but people
>>> like Bruce Schneier stress that doing crypto right is difficult,
>>> and that there are many possibilities for subtle errors that cause
>>> the encryption to be weak. Witness the non-random seed that turned
>>> up in Debian a few years ago, or the recent Elliptic Curve
>>> "scandal".
>>>
>>> Second, if the decryption key is baked in to ClamAV, what protocol
>>> is there to update it in case the encryption key is compromised? I
>>> presume it would require a ClamAV software update, but such an
>>> update would be critical, and the current out-of-date notice
>>> wouldn't cut it. In fact the fake CVD might even lie about the need
>>> for a software update.
>>>
>>> I'm not saying that HTTPS would answer these questions, but perhaps
>>> a more robust security model would be desirable.


_______________________________________________

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


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

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