5 ms·

It's always amusing when someone discovers DNS TXT records. ClamAV has been using them to announce the latest versions for more years than I care to remember.

It's always amusing when someone discovers DNS TXT records. ClamAV has been using them to announce the latest versions for more years than I care to remember. $ dig +short -t txt current.cvd.clamav.net "0.103.8:62:26972:1689593340:1:90:49192:334" For anyone interested, Freshclam interprets this as: Latest ClamAV version: 0.103.8 Latest Main DB version: 62 Latest Daily DB version: 26972 UNIX Timestamp 1689593340 ...and then some other version numbers and things I don't remember, one is probably a bytecode DB version 334, f-level 90 maybe. Anyway, nothing new, works as designed. You can do all kinds of neat tricks with it. DNS has a lot going on that most people don't (ab)use.

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.
- 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

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.
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