Created attachment 15641 [details]
an initial patch, mitigate this at the IDL level
A user with write access to a dnsZone object (eg a DNS administrator) can crash the DNS Management server because dnsProperty records can be parsed that when re-pushed point to invalid memory.
The id element in dnsp_DnsProperty was not the switch_is() value for data, instead it was entangled with a check on r->wDataLength, presumably to allow a 0 wDataLenght to take priority.
We do not know if dnsPropertyRecords with a 0 wDataLenght exist in the wild, but the IDL was originally created to provide for this.
However the application layer code does not look at wDataLength and the value() statement (calling an ndr_size_() function) uses id alone as the switch.
This means that when re-pushing a dnsProperty record that either a null pointer will be followed or uninitialised memory will be pushed back into the dnsPropertyRecord.
Found by Douglas Bagnall using Hongfuzz and the new fuzz_ndr_X fuzzer.
Created attachment 15657 [details]
patch for master
I've done a more complete triage of this today to try and assess how this could or could not be exploited.
My assessment is that this cannot be exploited per the rationale in the commit message. In short, we are saved by zeroed buffers.
However we should apply this to be stricter in the future and avoid missteps handling this, as we do should be able to expect fully initialised output from the NDR parser.
I'll remove the embargo once I get a peer review of this assessment.
The patch needs a test added before it goes to master.
Created attachment 15658 [details]
patch for master: mitigate this at the IDL level
This was CVE-2019-14908 but has been downgraded and un-embargoed after further triage.
I think the range check is unnecessary as it will fail with in normal parsing, i
Created attachment 15671 [details]
Proposed test case
Fixes in merge request 995
fixed in fee5c6a4247aeac71318186bbff7708d25de5912
Sorry, re-opened wrong bug. Bug 14310 is the regression from this bug.