3 ms·

A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bib

by dc396 1y ago

A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...)

m3047 1y ago
If the report is correct, then I think something else is being inferred / implied. If dnsmasq was only caching the ANSWER section, then the only thing which could be poisoned would be the qname. If cache poisoning for arbitrary domain names is being observed, then it would seem that information from the ADDITIONAL or AUTHORITY is being cached as well.
- JdeBP 1y ago
  The report and others are calling this "cache poisoning". That's a misnomer. It is not cache poisoning in the long-standing sense of the phrase. It is very simply equally long-standing simple DNS/UDP brute force response forgery. * https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/local-poc.py https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/... They're also relying upon the random source port being allocated from a subset of the available port range, 32768 to 61000 in their default setting. The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde. Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world. However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.
  - karel-3d 1y ago
    is this "avunit" someone from the reporting team? it seems created few hours ago, and it's using 8.8.8.8 which does not timeout as they claim; and the crux of the attack there is just that local UDP is faster than remote UDP edit: the only github account of the reporter is github.com/idealeer . this avunit is something random
    - JdeBP 1y ago
      Hint: Look at the mailing list post and the repository's "About" blurb. There are probably only 2 people in the world who want their own new coined name for this old hat stuff to stick. (-: They put their demonstration code up and sent out their mailing list post just over 130 minutes apart.
      - karel-3d 1y ago
        I think someone misunderstood the mailing list post and made a PoC. Because google's 8.8.8.8 does NOT timeout...

by dc396 1y ago

A nit: we've known about the flaw since 1993 (see https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-05.pdf https://www.cerias.purdue.edu/assets/pdf/bibtex_archive/94-0...)

m3047 1y ago

If the report is correct, then I think something else is being inferred / implied. If dnsmasq was only caching the ANSWER section, then the only thing which could be poisoned would be the qname. If cache poisoning for arbitrary domain names is being observed, then it would seem that information from the ADDITIONAL or AUTHORITY is being cached as well.

JdeBP 1y ago
The report and others are calling this "cache poisoning". That's a misnomer. It is not cache poisoning in the long-standing sense of the phrase. It is very simply equally long-standing simple DNS/UDP brute force response forgery. * https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/local-poc.py https://github.com/Avunit/Dnsmasq-Cache-Poisoning/blob/main/... They're also relying upon the random source port being allocated from a subset of the available port range, 32768 to 61000 in their default setting. The claim in the code is that it is Google Public DNS that is failing to respond to queries where the domain name has had an extra label prepended, and that label is 1 character long and the character is a tilde. Google Public DNS has no such non-response problems with ~.www.example.com in my part of the world. However, note that they are injecting the forged responses from the very same machine that sent the initial query to dnsmasq, with no delay whatsoever. Whereas it takes Google Public DNS a second or so to look up ~.www.example.com here. So really there's no methodologically sound evidence that Google Public DNS even has the fault with these punctuation characters as claimed.
- karel-3d 1y ago
  is this "avunit" someone from the reporting team? it seems created few hours ago, and it's using 8.8.8.8 which does not timeout as they claim; and the crux of the attack there is just that local UDP is faster than remote UDP edit: the only github account of the reporter is github.com/idealeer . this avunit is something random
  - JdeBP 1y ago
    Hint: Look at the mailing list post and the repository's "About" blurb. There are probably only 2 people in the world who want their own new coined name for this old hat stuff to stick. (-: They put their demonstration code up and sent out their mailing list post just over 130 minutes apart.
    - karel-3d 1y ago
      I think someone misunderstood the mailing list post and made a PoC. Because google's 8.8.8.8 does NOT timeout...