auth-secondarycommunicator.cc's doAxfr trusts first SOA over last

[MegaManSec]

Trusts first SOA over last (L625-L643) (medium) (Confidence: 8.5) (Severity: 9.1)

doAxfr() accepts the first SOA seen in the incoming AXFR stream, sets zs.soa_serial from it, and then skips any further SOA records. If the remote AXFR sender (the primary) provides inconsistent SOA serials (first SOA != last SOA), the function will ignore the terminating SOA and keep the first SOA's serial. An attacker who can pretend to be or control the primary can exploit this within a single AXFR transfer to make the secondary compute/store an incorrect zone serial (for example accepting a lower/stale serial), which may lead to incorrect zone data being installed or incorrect transfer/notify behavior downstream.

This bug was found using ZeroPath.

[Habbie]

(Confidence: 8.5) (Severity: 9.1)

can you say something about what these numbers mean, on what scale?

[MegaManSec]

They're out of 10, but realistically speaking, I think they mean nothing. I have no idea how they're calculated, and since ZeroPath doesn't yet "officially" support finding bugs (or at least, separating them into a "bugs" category), the meaning is even lower, I think.

[hlindqvist]

doAxfr() accepts the first SOA seen in the incoming AXFR stream, sets zs.soa_serial from it, and then skips any further SOA records. If the remote AXFR sender (the primary) provides inconsistent SOA serials (first SOA != last SOA), the function will ignore the terminating SOA and keep the first SOA's serial. An attacker who can pretend to be or control the primary can exploit this within a single AXFR transfer to make the secondary compute/store an incorrect zone serial (for example accepting a lower/stale serial), which may lead to incorrect zone data being installed or incorrect transfer/notify behavior downstream.

I suppose arguably it should abort if the transfer-ending SOA doesn't match, as that is not what the spec says should be there.

The spec specifically says:

In such a series, the first message MUST begin with the
SOA resource record of the zone, and the last message MUST conclude
with the same SOA resource record.

But that whole construction with leading+trailing SOA is just a means of confirming the end of the AXFR sequence, not a security mechanism per se, and not a situation where different SOA data means something or that one SOA is more relevant/precious/... than the other. It's just a repetition of the same record at the end.

What use would it be to an attacker to "exploit this within a single AXFR transfer"? What do they gain from going down this very specific path?

If an attacker is in a position to send an "incorrect" SOA in one part of the AXFR, surely they are in a position to repeat the same "incorrect" SOA consistently as well? And if their attack would be consistent (might be easier?), their "incorrect" SOA would be accepted also with more strict behavior in place.
For that matter, they would also be in a position to change any of the other, typically more functionally significant, non-repeating records.

Unauthenticated AXFR as a whole is a security concern, but this SOA behavior doesn't seem to really change what an attacker can do?