This fixes some vulnerabilities in the resolver that make spoofing DNS
queries somewhat trivial due to the code failing to randomize xid, as
well as match the reply xid with the query, and the origin of the packet:
- xid of the query was fixed at zero
- xid from the reply was never checked
- source address of the reply was never checked
This means anyone can flood the host with a fake reply with xid 0,
guessing the source port is trivial as it's less than 16bits (2^16 -
1024), which would cause odin to resolve a hostname to whatever an
attacker wanted.
While here also plug in two memory leaks.
Since this is CVE material, I've contacted @kelimion before hand which
instructed to put it in a PR.
There are also more bugs as the code conflates answer section,
authority section and aditional section into one, while in reality
only the anwer section should be taken into consideration.
This allows `*` to be used in C fashion, without specifying an argument
index to use. Like C, this results in the argument *preceding* the value
for the format specifier itself.
- A compression pointer is when the two higher bits are set, the code was
considering only 0xC0 as a pointer, where in reality anything from 0xC0-0xFF is
a pointer, probably went unnoticed since you need big packets to have long pointers.
- Make sure we can access the lower byte of the pointer by checking len, the
code was careful to not access past the first byte, but ignored the second.
- As per RFC9267 make sure a pointer only points backwards, this one is not so
bad, as the code had a iteration_max that ended up guarding against infinite jumps.
Lightly tested, some eyes are welcome, but these are remote DOSable.
This affects `runtime.Arena` and `virtual.Arena`, but not currently
`mem.Arena`. These changes allow the last allocation that has been
made to be resized to a larger size by just extending their
allocation in-place, when there's sufficient room in the memory block to
do so.
Shrinking in place and re-using the rest of the allocation can be
supported using almost the same logic, but would require the memory to
be zeroed. Since this would add a additional cost that isn't currently
present, shrinking has not been changed.