Fixes for older releases

[kitterma]

In Debian we are currently supporting releases with dnspython 2.3.0 and 2.0.0. Our LTS group (which is sort of separate) is still supporting a release with 1.16.0. After a quick look, it seems likely to me that this issue applies, at least to some degree, to these older releases.

In your judgement is this a serious enough issue that we should try to backport the 2.6.0 change (thanks, just uploaded it to Debian Unstable) to these earlier versions?

Scott K

[rthalley]

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.

[kitterma]

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.

[frenzymadness]

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?

[rthalley]

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

[frenzymadness]

Thank you very much!