5 ms·

That is... interesting that they do not even use HTTPS or any type of signature for that info. So a man in the middle could prevent updates from happening, and

by hannob 3y ago

That is... interesting that they do not even use HTTPS or any type of signature for that info. So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?

mrweasel 3y ago
Won't DNSSEC prevent MITM attacks in this case? From https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... - "DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX)"
- deleted 3y ago
  [deleted]
- toast0 3y ago
  clamav.net, like most domains, doesn't enable DNSSEC. Further, as designed, local resolvers don't validate DNSSEC, they just ask the recursive resolver to; a MITM between the local and the recursive can lie. So when wikipedia says DNSSEC can protect, that's the permissive can. Like things can happen. But don't rely on it.
  - fanf2 3y ago
    No, stub resolvers are supposed to, and often do validate DNSSEC signatures. DNSSEC is designed so that validation should happen whenever any DNS data is received over the network.
    - tptacek 3y ago
      That's the opposite of how DNSSEC works in practice.
  - egberts1 3y ago
    Wrong (EDIT: oops, I am wrong) current.cvd.clamav.net is (EDIT:) NOT currently DNSSEC-signed. Just that their dnsquery() via freshclam daemon is not using val_res_query() when pulling in the version number, so it is unverified DNS querying going on … over there.
    - toast0 3y ago
      But there's no chain from the root, or at least that's what I'm getting from this tool [1]. [1] https://dnssec-analyzer.verisignlabs.com/clamav.net https://dnssec-analyzer.verisignlabs.com/clamav.net
      - egberts1 3y ago
        NASTY! You’d be right. I too did not get the ‘ad’ notation in my own dig response record. This mean, any TXT record can easily be spoofed via a simple transparent MitM packet munging. https://dnssec-analyzer.verisignlabs.com/current.cvd.clamav.net https://dnssec-analyzer.verisignlabs.com/current.cvd.clamav....
    - tptacek 3y ago
      There's no DS record for clamav.net at all. They're not signed.
    - Eduard 3y ago
      > Wrong (EDIT: oops, I am wrong) current.cvd.clamav.net is (EDIT:) NOT currently DNSSEC-signed. When it's better to just delete and replace a comment.
  - mrweasel 3y ago
    Silly me for expecting an anti-virus company to care about security. The point remains: DNSSEC COULD make this safe to do.
    - tptacek 3y ago
      The best-resourced, most widely respected security teams on the Internet tend strongly not to enable DNSSEC or advocate for its adoption, mostly because it doesn't solve meaningful problems.
    - devrand 3y ago
      It would still be prone to DoS though. The request is unencrypted so a MITM could just not respond to those requests. This would effectively block clients from being able to update/get new definitions.
    - mike_d 3y ago
      DNSSEC failures result in denial of service. Turning it on in no way makes the experience safer for an end user.
  - omoikane 3y ago
    Related: https://news.ycombinator.com/item?id=36171696 https://news.ycombinator.com/item?id=36171696 - "Calling time on DNSSEC: The costs exceed the benefits"
egberts1 3y ago
well, that would be the fault of clamav if they did not do the proper DNSSEC verification and validation of their ‘current.cvd.clamav.net’ hostname. Digging into the code of freshclam, source of libfreshclam.c, dnsquery() function call, it is painfully evident that freshclam daemon does not do basic DNSSEC when performing res_query(). Instead, freshclam should be calling `val_res_query()`. They are currently using ‘res_query()’.
- orangepurple 3y ago
  Yep, it's another "security" solution that is dead on arrival
  - egberts1 3y ago
    seems like the remaining solutions are boiled down to just either a private PGP, IPSec, or mutual-TLS data connection by direct IPv4 or IPv6 address.
    - egberts1 3y ago
      Signal API is also another solution.
WorldMaker 3y ago
You don't even need an intentionally evil man in the middle: I can't imagine wanting to block something critical like AV updates on ordinary DNS TTLs, much less the long tail of DNS resolvers that have subtly broken caching strategies of one kind or another and sometimes get the TTLs wrong. An hour or two may be a huge difference in preventing a viral spread, but at least in my experience is it is tough to rely on DNS propagation below the hour line. Seems like an odd technical choice to me.
freedude 3y ago
"So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?" And yet it "works" and as the OP mentioned for a long time. Often we get so conditioned to a security response we forget that basic security often relies upon a "simple" and inexpensive solution. Using DNS in this way is a best effort scenario that offloads work to servers designed for this purpose and for an open source project so you use what you have. Oh, and there is a failover to https if the record is over three hours old. https://docs.clamav.net/faq/faq-troubleshoot.html https://docs.clamav.net/faq/faq-troubleshoot.html

by hannob 3y ago

mrweasel 3y ago

Won't DNSSEC prevent MITM attacks in this case? From https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... - "DNSSEC can protect any data published in the DNS, including text records (TXT) and mail exchange records (MX)"

deleted 3y ago
[deleted]
toast0 3y ago
clamav.net, like most domains, doesn't enable DNSSEC. Further, as designed, local resolvers don't validate DNSSEC, they just ask the recursive resolver to; a MITM between the local and the recursive can lie. So when wikipedia says DNSSEC can protect, that's the permissive can. Like things can happen. But don't rely on it.
- fanf2 3y ago
  No, stub resolvers are supposed to, and often do validate DNSSEC signatures. DNSSEC is designed so that validation should happen whenever any DNS data is received over the network.
  - tptacek 3y ago
    That's the opposite of how DNSSEC works in practice.
- egberts1 3y ago
  Wrong (EDIT: oops, I am wrong) current.cvd.clamav.net is (EDIT:) NOT currently DNSSEC-signed. Just that their dnsquery() via freshclam daemon is not using val_res_query() when pulling in the version number, so it is unverified DNS querying going on … over there.
  - toast0 3y ago
    But there's no chain from the root, or at least that's what I'm getting from this tool [1]. [1] https://dnssec-analyzer.verisignlabs.com/clamav.net https://dnssec-analyzer.verisignlabs.com/clamav.net
    - egberts1 3y ago
      NASTY! You’d be right. I too did not get the ‘ad’ notation in my own dig response record. This mean, any TXT record can easily be spoofed via a simple transparent MitM packet munging. https://dnssec-analyzer.verisignlabs.com/current.cvd.clamav.net https://dnssec-analyzer.verisignlabs.com/current.cvd.clamav....
  - tptacek 3y ago
    There's no DS record for clamav.net at all. They're not signed.
  - Eduard 3y ago
    > Wrong (EDIT: oops, I am wrong) current.cvd.clamav.net is (EDIT:) NOT currently DNSSEC-signed. When it's better to just delete and replace a comment.
- mrweasel 3y ago
  Silly me for expecting an anti-virus company to care about security. The point remains: DNSSEC COULD make this safe to do.
  - tptacek 3y ago
    The best-resourced, most widely respected security teams on the Internet tend strongly not to enable DNSSEC or advocate for its adoption, mostly because it doesn't solve meaningful problems.
  - devrand 3y ago
    It would still be prone to DoS though. The request is unencrypted so a MITM could just not respond to those requests. This would effectively block clients from being able to update/get new definitions.
  - mike_d 3y ago
    DNSSEC failures result in denial of service. Turning it on in no way makes the experience safer for an end user.
- omoikane 3y ago
  Related: https://news.ycombinator.com/item?id=36171696 https://news.ycombinator.com/item?id=36171696 - "Calling time on DNSSEC: The costs exceed the benefits"

egberts1 3y ago

well, that would be the fault of clamav if they did not do the proper DNSSEC verification and validation of their ‘current.cvd.clamav.net’ hostname. Digging into the code of freshclam, source of libfreshclam.c, dnsquery() function call, it is painfully evident that freshclam daemon does not do basic DNSSEC when performing res_query(). Instead, freshclam should be calling `val_res_query()`. They are currently using ‘res_query()’.

orangepurple 3y ago
Yep, it's another "security" solution that is dead on arrival
- egberts1 3y ago
  seems like the remaining solutions are boiled down to just either a private PGP, IPSec, or mutual-TLS data connection by direct IPv4 or IPv6 address.
  - egberts1 3y ago
    Signal API is also another solution.

WorldMaker 3y ago

You don't even need an intentionally evil man in the middle: I can't imagine wanting to block something critical like AV updates on ordinary DNS TTLs, much less the long tail of DNS resolvers that have subtly broken caching strategies of one kind or another and sometimes get the TTLs wrong. An hour or two may be a huge difference in preventing a viral spread, but at least in my experience is it is tough to rely on DNS propagation below the hour line. Seems like an odd technical choice to me.

freedude 3y ago

"So a man in the middle could prevent updates from happening, and freshclam wouldn't even throw a warning?" And yet it "works" and as the OP mentioned for a long time. Often we get so conditioned to a security response we forget that basic security often relies upon a "simple" and inexpensive solution. Using DNS in this way is a best effort scenario that offloads work to servers designed for this purpose and for an open source project so you use what you have. Oh, and there is a failover to https if the record is over three hours old. https://docs.clamav.net/faq/faq-troubleshoot.html https://docs.clamav.net/faq/faq-troubleshoot.html