No longer accept short messages #1656
Conversation
|
ohh, this is nice, and removes a whole bunch of (generated) code. IIRC this was added because of actual things going awry when parsing binary from the wire - but I dont thing we have a test for this :-( To put it another way if you can show me a binary unpack test that would hit this |
|
I'm not quite sure what you mean. Removing the I have already provided (as of the second commit in this PR) an example test with an MX record where the rrdata section has been truncated to just 2 bytes, which covers just the preference uint16 and has no space for the following MX name field. Previously, this would have hit the Is there some reason why splicing arbitrary RRs at field bounds like that should be considered valid? Splicing at points besides those bounds was already invalid. |
|
https://codeberg.org/miekg/dns used @tmthrgd I'm not going to merge such an invasive PR here |
At the moment, the code for unpacking RRs (mostly in the autogenerated code) is peppered with chunks of
off == len(msg)checks which return with a nil error.As far as I understand, this is a workaround for parsing messages with an rdlength of zero. This mostly works due to the
noRdatacheck inUnpackRRWithHeader.Removing these checks reveals that
TestNoRdataUnpackdoes not actually produce zero-rdlength messages for a good number of rrtypes, so thenoRdataearly return does not trigger. Theseoff == len(msg)clauses peppered everywhere cause parsing to instead succeed at the boundaries of arbitrary elements of a resource record, with the zero values assigned to the rest of the messages.This means that malformed RRs which are too short, but happen to end at the right byte boundary, will be considered valid, with any remaining fields being kept as the zero value.
In fact, even a nil buffer would be parsed as a "valid" RR by
dns.UnpackRR(nil, 0), producing this RR:This PR removes all of these checks while keeping functionality for real zero-rdlength RRs.
The malformed messages described above will no longer be considered valid.
TestNoRdataUnpackhas been updated to manually adjust the RRs to produce actual zero-rdlength messages.