New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multiple stack-based buffer overflow #185
Comments
|
I have requested a CVE identifier for this issue, will send a follow-up when I hear back from MITRE. |
|
The issue in the set_ipv4() function got assigned CVE-2019-13951. The issue in the set_ipv6() function got assigned CVE-2019-13952. |
|
Thanks for running this and reporting! Will look into a proper patch for these shortly. Note of course zonefiles are administrator-controlled input, but it is a bug! |
Github bug report at gdnsd#185 Found by Frederic Cambus using afl-fuzz
|
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). |
Github bug report at #185 Found by Frederic Cambus using afl-fuzz
Github bug report at #185 Found by Frederic Cambus using afl-fuzz (For this cherry-pick back to 1.x, only the ipv6 variant matters; the ragel parser enforces the 15-char limit for ipv4).
Github bug report at #185 Found by Frederic Cambus using afl-fuzz (For this cherry-pick back to 2.x, only the ipv6 variant matters; the ragel parser enforces the 15-char limit for ipv4).
Github bug report at #185 Found by Frederic Cambus using afl-fuzz (For this cherry-pick back to 2.x, only the ipv6 variant matters; the ragel parser enforces the 15-char limit for ipv4).
Github bug report at #185 Found by Frederic Cambus using afl-fuzz (For this cherry-pick back to 2.x, only the ipv6 variant matters; the ragel parser enforces the 15-char limit for ipv4).
Github bug report at #185 Found by Frederic Cambus using afl-fuzz
Github bug report at #185 Found by Frederic Cambus using afl-fuzz
Github bug report at #185 Found by Frederic Cambus using afl-fuzz
|
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:
|
Github bug report at #185 Found by Frederic Cambus using afl-fuzz (For this cherry-pick back to 2.x, only the ipv6 variant matters; the ragel parser enforces the 15-char limit for ipv4).
Hi,
I found two occurences of stack-based buffer overflow when fuzzing gdnsd
with American Fuzzy Lop.
and can be triggered with the following input:
The issue can be be reproduced by creating a 'zones' directory, putting
the above input in a file within the 'zones' directory, and running:
Because no bounds checking is being done in the set_ipv4() function, 'len'
ends up being larger than 16:
It seems your parser is attempting to parse malformed IPv4 addresses until
there is no input left, as I have been able to get 'len' to reach very
large values when generating malformed IPv4 address strings spawning several
gigabytes, which gdnsd will happily attempt to parse.
and can be triggered with the following input:
Because no bounds checking is being done in the set_ipv6() function, 'len'
ends up being larger than INET6_ADDRSTRLEN + 1:
As previously, the parser will happily parse malformed IPv6 address strings
spawning several gigabytes.
The text was updated successfully, but these errors were encountered: