Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Multiple stack-based buffer overflow #185
I found two occurences of stack-based buffer overflow when fuzzing gdnsd
The issue can be be reproduced by creating a 'zones' directory, putting
Because no bounds checking is being done in the set_ipv4() function, 'len'
It seems your parser is attempting to parse malformed IPv4 addresses until
Because no bounds checking is being done in the set_ipv6() function, 'len'
As previously, the parser will happily parse malformed IPv6 address strings
Dug a bit into the history of this as well:
For the IPv4 case, the Ragel portion of the parser used to enforce the length limit here in 2.x and earlier, but the Ragel part was relaxed in 15715fc , which is included in all 3.x releases.
For the IPv6 case, I think this has always been broken, at least as far back as the Ragel-based parser goes in general (past the start of git history).
Meta-info updates on the assigned CVE metadata, etc (I'm not always sure of the right channel for these, but recording it here seems prudent regardless):
https://nvd.nist.gov/vuln/detail/CVE-2019-13951 - This is the
In both cases, the vector for this is writing illegitimate data to local zonefiles on the disk of the DNS server, which are intended to be administrator-controlled with appropriate permissions, obviously. The NVD impact analysis metrics claim the attack vector is "Network", which is patently false and inflates the scoring. The actual attack vector is merely "Local" (and even then, you could make some distinction that it's not exploitable by random local users, only those who already have permission from the operating system to change everything about the authoritative zone file data the server serves and/or control the daemon, which are far easier and more-explicit pathways to more harm).
Updates on updating for users, packagers, distros, etc:
Official new upstream releases containing the fixes for this issue:
The 3.0 and 3.1 minor versions were relatively short-lived, recent, and easy to upgrade from, and all versions before 2.4 are considered ancient history (please upgrade!), so no actual tagged and uploaded releases are being made for those. However, for those maintaining packages of these releases for older distributions or local use, the patches have been backported to the upstream branches here at github, which you can use as sources if you wish to vendor/user -patch older releases.
The upstream branches containing the relevant fixes for these other releases are: