Fwd: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Klaus Darilion

What is an "extraordinarily large zone transfer"? We do have regularly AXFR and IXFRs around 2GB. Is this "extraordinarily large"?

regards
Klaus



-------- Weitergeleitete Nachricht --------
Betreff: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination
Datum: Wed, 4 Jul 2018 17:41:10 -0800
Von: Michael McNally [hidden email]
An: [hidden email]


Summary:

   In versions of BIND released prior to July 2018 (before BIND
   9.9.13, 9.10.8, 9.11.4, 9.12.2, and BIND 9.13.1) it is possible
   for extraordinarily large zone transfers to cause several related
   problems, with possible outcomes including corrupted journal
   files or server exit due to assertion failure.

Posting date:        03 July 2018
Program Impacted:    BIND
Versions affected:   9.0.x -> 9.8.8, 9.9.0 -> 9.9.12, 9.10.0 -> 9.10.7,
                     9.11.0 -> 9.11.3, 9.12.0 -> 9.12.1, and versions
                     9.13.0 -> 9.13.1 of the 9.13 development branch

Description:

   A problem in named can potentially lead to corrupted journal
   files when handling extraordinarily large zone transfers.

Impact:

   This problem potentially affects authoritative servers providing
   slave service for zones if the server accepts zone data via
   incremental zone transfer (IXFR) from a master source or if a
   large zone transfer (AXFR) is received and ixfr-from-differences
   is not set to "no" (the default setting is "yes", and possible
   values are "yes", "no", "slave", and "master").

   We warned of a similar class of problems in 2016 in this previous
   Operational Notification "A party that is allowed control over
   zone data can overwhelm a server by transferring huge quantities
   of data." (https://kb.isc.org/article/AA-01390)

Workarounds:

   Like any unvalidated input, zone transfers are a potential source
   of risk for servers under any circumstances.  BIND therefore
   supports a variety of mechanisms to control zone transfer
   permissions.  Permission to transfer can be restricted to trusted
   servers using IP-address-based ACLs or shared secrets (TSIG keys)
   or both.  Under most circumstances a slave server should not
   encounter this defect when receiving data from a trusted server,
   but it can be prevented entirely by forbidding incremental zone
   transfer as a zone data transfer mechanism.  It may be preferable
   to instead set a reasonable limit for the number of records which
   may be in a zone (using the max-records parameter) which should
   also prevent accidentally encountering this defect.

   Servers which must accept zone data from untrusted sources (for
   example, when seconding zones for other parties) are at slightly
   higher risk if a party decides to deliberately feed a dangerously
   large zone transfer.  Operators of servers which must accept
   untrusted zone data should consider limiting zone size using
   max-records, setting "ixfr-from-differences no;", or upgrading
   to a version of BIND which will reject dangerously large transfers.

Active exploits:

   No known active exploits.

Solution:

   It is our opinion that most customers do not need to worry about
   this issue unless they accept zone data via zone transfer from
   untrusted sources, but we have included changes in upcoming
   maintenance releases of BIND which will prevent the condition
   from being reached.

   Maintenance releases of BIND issued on or after 4 July 2018 will
   contain change #4984, which will cause BIND to reject an
   extraordinarily large IXFR if it is potentially large enough to
   corrupt the journal file. These release candidates are available
   now via https://www.isc.org/downloads and the change will be
   included in future versions of BIND

    BIND 9 version 9.9.13rc2
    BIND 9 version 9.10.8rc2
    BIND 9 version 9.11.4rc2
    BIND 9 version 9.12.2rc2


Do you still have questions?  Questions regarding this advisory
should go to [hidden email].  To report a new issue,
please encrypt your message using [hidden email]'s PGP
key which can be found here:

   https://www.isc.org/downloads/software-support-policy/openpgp-key/.

If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01627
is the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind is expressed
   in this notice and none should be implied. ISC expressly excludes
   and disclaims any warranties regarding this notice or materials
   referred to in this notice, including, without limitation, any
   implied warranty of merchantability, fitness for a particular
   purpose, absence of hidden defects, or of non-infringement. Your
   use or reliance on this notice or materials referred to in this
   notice is at your own risk. ISC may change this notice at any
   time.  A stand-alone copy or paraphrase of the text of this
   document that omits the document URL is an uncontrolled copy.
   Uncontrolled copies may lack important information, be out of
   date, or contain factual errors.

(c) 2001-2018 Internet Systems Consortium
_______________________________________________
bind-announce mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-announce

_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Matthew Pounsett


On 9 July 2018 at 16:22, Klaus Darilion <[hidden email]> wrote:

What is an "extraordinarily large zone transfer"? We do have regularly AXFR and IXFRs around 2GB. Is this "extraordinarily large"?


I've also been curious about this.  Are we talking millions of records, tens or hundreds of millions, or billions?


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Michał Kępień
> > What is an "extraordinarily large zone transfer"? We do have regularly
> > AXFR and IXFRs around 2GB. Is this "extraordinarily large"?
> >
>
> I've also been curious about this.  Are we talking millions of records,
> tens or hundreds of millions, or billions?

Hopefully this will shed some light on the matter:

    https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805

--
Best regards,
Michał Kępień
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Matthew Pounsett


On 13 July 2018 at 06:04, Michał Kępień <[hidden email]> wrote:
Hopefully this will shed some light on the matter:

    https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805

That is helpful, thanks.  That comment says the issue requires a journal entry of over 4G, however the original bug report indicates it was triggered by a 1.6GiB IXFR.   But then I suppose there's not a 1:1 relationship between the size of the zone transfer and the size of the journal entry.

Thanks for the info!


_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

Bind-Users forum mailing list


Am 14.07.2018 um 00:38 schrieb Matthew Pounsett:

> On 13 July 2018 at 06:04, Michał Kępień <[hidden email]> wrote:
>
>> Hopefully this will shed some light on the matter:
>>
>>     https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805
>>
>> That is helpful, thanks.  That comment says the issue requires a journal
> entry of over 4G, however the original bug report indicates it was
> triggered by a 1.6GiB IXFR.   But then I suppose there's not a 1:1
> relationship between the size of the zone transfer and the size of the
> journal entry.

The journal increases over time until it reaches "max-journal-size"
which will trigger a journal clean-up. I supsect if the journal is eg.
3G and you have an 1.6 IXFR it may crash your bind.

regards
Klaus
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list

bind-users mailing list
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users