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
