Re: Pending pdns updates
Hi Enrico,
On Mon, Jun 6, 2022 at 3:24 PM Enrico Zini <enrico@enricozini.org> wrote:
> last month as part of Freexian onboarding I tried to work on pdns:
> https://security-tracker.debian.org/tracker/source-package/pdns
>
> I backported patches for CVE-2020-17482 and CVE-2019-10203
> to https://salsa.debian.org/enrico/pdns/-/tree/stretch
>
> For CVE-2022-27227, available patches touch code that mostly didn't
> exist in 4.0.3, and zeha commented on IRC:
>
> > do you have actual users on 4.0.x which are -actually- affected by the
> > IXFR things? i think if one uses 4.0.x to run a domain on the public
> > internet, you'll have other problems
>
> It looks like a case for tagging as no-dsa: would you agree?
I wonder if the stretch version is even vulnerable in the first place?
It looks like it's not? Or am I missing something? I mean, I just took
a quick glance at the source (w/o patches applied) and the relevant
code is not there. But I understand that it's not enough to say that
it's not vulnerable. Perhaps having a reproducer might help to be
certain here?
> That leaves CVE-2020-17482 and CVE-2019-10203 pending. pdns has no test
> suite, and I'm unable to smoke test it manually, so it feels
> irresponsible for me to make a DLA without testing.
>
> I left a note of this in dla-needed.txt: is that enough, or would you
> like me to do something else not to leave this work unfinished?
If you're _fairly_ confident that nothing's going to break and that
the patches were straightforward, I'd say go ahead. Otherwise, POCs
are the best way to ensure what you backported is correct and that it
works, indeed. Getting hold of a POC is some work (if it's not
mentioned in the initial advisory) - ask the sec team, ask the
upstream sec team, coordinate with them, et al, et al. Or ask
Christian how he smokes test them or if we can help. Let me know if
any of what I said works, if it doesn't, we'll take another look at
this again.
Hope that helps?
- u
Reply to: