Fixes for older releases about dnspython HOT 5 CLOSED

We added a parameter to dns.query.udp() as part of the fix, so this code will test:

import dns.message
import dns.query

q = dns.message.make_query("www.dnspython.org", "A")
try:
    r = dns.query.udp(q, "1.1.1.1", ignore_errors=True)
    print("has the CVE fix")
except TypeError:
    # ignore_errors is not a valid parameter
    print("does not have the CVE fix")

here's an example of it with various versions:

% git checkout v2.5.0
HEAD is now at 91e5027 2.5.0 versioning
% python ~/cve-fix-check.py     
does not have the CVE fix
% git checkout v2.6.1           
Previous HEAD position was 91e5027 2.5.0 versioning
HEAD is now at 0a742b9 update CI
% python ~/cve-fix-check.py
has the CVE fix
% git checkout main
Previous HEAD position was 0a742b9 update CI
Switched to branch 'main'
Your branch is up to date with 'origin/main'.
% python ~/cve-fix-check.py
has the CVE fix

from dnspython.

All versions of dnspython < 2.6.0 are affected by the issue. I don't think this problem really warrants aggressive backporting though, as a DoS against a stub resolver is not generally very appealing. Basically you'd have to know when some python application you cared about was about to do some critical query, like looking up the hostname of a database or something, guess the right one-time use port, and then spoof a bad message from that port before the real resolver answered, thus causing the python program to not connect to the database (unless there was another resolver in /etc/resolv.conf, or the application tried again, or ...).

At any rate, it didn't meet the severity level where I'd consider it worth aggressive backporting, which is why I didn't write those backports.

So, my vote would be "no need", but if someone at Debian feels otherwise, the fix is basically the same for all of them as far as adding ignore_errors to udp() and receive_udp(). It's a little different in that there is no "nameserver" abstraction in older versions, and the resolver just directly calls udp(), so you'd have to have it pass the ignore_errors and ignore_unexpected flags just like the final 2.6.0 code does in the nameserver object.

from dnspython.

Thanks. We have a category for yes it's an issue, but it's not worth the trouble. I'll recommend that to our security team.

from dnspython.

I'm in the same situation as @kitterma so thank you for the details. Given all the conditions that have to be met for a successful attack, I guess that there is not an easy way how to reproduce it. I mean having a code that verifies that a specific version of DNS lib contains the fix. Is there a way to do that?

from dnspython.

Thank you very much!

from dnspython.