Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports
tags 844121 + wontfix notfound 844121 2.0.13-1.2 thanks Hi all In meanwhile the CVEs were properly rejected by MITRE. I'm closing this bugreport now. Regards, Salvatore
Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports
Thank you for verifying this is not a bug. I would rather have a false
bug report than have a real security issue out there that I’m not
aware of.
I should explain why the MaraDNS code is so messy and hard to follow:
Back in 2001, there was precisely one and only one open-source DNS
server: BIND. This was an issue, so there was a call to arms to have
another open source DNS server out there:
http://old.lwn.net/2001/0208/
That in mind, I quickly wrote up a DNS server; within two months I had
a usable authoritative server, and within a year I had a usable
recursive server. This rapid development came at a cost: The code
worked, was remarkably secure considering how quickly I wrote it, but
it was a mess to maintain. I had planned for years to rewrite MaraDNS,
and five years after the initial recursive server, I started a project
to rewrite the recursive code. My plan was to have a recursive server
within a year; while I had a usable caching server with cleaner code
within six months, it took me three years to make it a fully recursive
server.
My original plan was to rewrite the recursive component, than rewrite
the authoritative component. That never happened, for a number of
reasons, including the fact that DjbDNS became open-source after I
started MaraDNS 2.0’s recursive server, and NSD/Unbound came on to the
scene. With the excellent Knot DNS and Knot Resolver now also carrying
the torch for open source DNS servers, and with my life having a lot
less free time than I did a decade and a half ago when I started
MaraDNS, MaraDNS is in deep freeze maintenance mode.
I still take responsibility for security issues in the code I wrote a
long time ago, since there’s a contingent of users who feel MaraDNS is
more lightweight on “low end boxes” such as virtual machines with only
128 megs of memory (and are willing to give up DNSsec support to have
something that lightweight). But, beyond that, I don’t have time to
even fix things like resolution issues caused because the way DNS
servers handle out-of-bailiwick glue in CNAME records has changed
since 2001. Forget about adding DNSsec to MaraDNS.
Anyway, I do welcome security reports to MaraDNS and do take them very
seriously. There may not be a “packet of death” bug in the MaraDNS
codebase — João Antunes did a pretty through audit of the
authoritative codebase back in 2007 and probably would have found a
“packet of death” back then if there was one.
— Sam
On Mon, Dec 5, 2016 at 5:27 AM, Ondřej Surý wrote:
> Sam and others,
>
> I most deeply apologize, you are right in your assessment.
>
> I somehow missed the extra four additional sanity checks at the
> beginning of the getudp() function that seems to catch the error
> conditions on those input buffers.
>
> Cheers,
> --
> Ondřej Surý
> Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
> Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
> fast DNS(SEC) resolver
> Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
> pečení chleba všeho druhu
>
> On Sat, Dec 3, 2016, at 16:47, Sam Trenholme wrote:
>> CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug
>> reports.
>>
>> Here’s the deal: The reporter had to patch MaraDNS before he was able
>> to crash her.
>>
>> The patch, however, treats MaraDNS’ special buffer-overflow-resistant
>> “js_string” as if it were an ordinary string — but it’s not. Here’s
>> the offending code patched in to MaraDNS from the reporter’s “bug
>> report”:
>>
>> sock_num = read(0, incoming, 512);
>>
>> As per the man page for read:
>>
>> ssize_t read(int fd, void *buf, size_t count);
>>
>> DESCRIPTION
>>read() attempts to read up to count bytes from file descriptor fd
>>into
>>the buffer starting at buf.
>>
>> However, incoming is not a raw string buffer: It’s a special js_string
>> object which MaraDNS uses to be buffer overflow resistant, as can be
>> seen here in server/MaraDNS.c:
>>
>> int main(int argc, char **argv) {
>>
>> js_string *mararc_loc = 0, *errors = 0,
>> *bind_address = 0, *ipv6_bind_address = 0,
>> *csv2_synthip_address = 0,
>> *ipv4_bind_address = 0, *incoming = 0,
>> *uncomp = 0, *verbstr = 0;
>>
>> The js_string structure (I guess I would call it an object here in
>> 2016) is defined in libs/JsStr.h:
>>
>> typedef struct {
>> unsigned char *string; /* Actual physical string */
>> unsigned int unit_size; /* The size of a single character in the
>> string */
>> unsigned int unit_count; /* The length of the string, in units */
>> unsigned int max_count; /* The maximum allowable size of the string,
>>also in units */
>> int encoding; /* The type of language/encoding the string is in */
>> int is_good;/* This is checked to make sure the data structure is
>>sane */
>> } js_string;
>>
>> Point being, if we patch MaraDNS t
Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports [VR-554]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Greetings,
The CERT/CC is tracking this as VR-554, please retain VR-554 in the subject of
future replies related to this issue.
Considering the issue and CVE IDs are already being publicly discussed, we are
unlikely to take further action at this time. Any and all CVE disputes should
be directed to MITRE (c...@mitre.org or their CVE form).
Regards,
Joel Land
Vulnerability Analysis Team
==
CERT Coordination Center
www.cert.org / c...@cert.org
==
Sam Trenholme writes:
>CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.
>
>Hereâs the deal: The reporter had to patch MaraDNS before he was able
>to crash her.
>
>The patch, however, treats MaraDNSâ special buffer-overflow-resistant
>âjs_stringâ as if it were an ordinary string â but itâs not. Hereâs
>the offending code patched in to MaraDNS from the reporterâs âbug
>reportâ:
>
>sock_num = read(0, incoming, 512);
>
>As per the man page for read:
>
>ssize_t read(int fd, void *buf, size_t count);
>
>DESCRIPTION
> read() attempts to read up to count bytes from file descriptor fd into
> the buffer starting at buf.
>
>However, incoming is not a raw string buffer: Itâs a special js_string
>object which MaraDNS uses to be buffer overflow resistant, as can be
>seen here in server/MaraDNS.c:
>
>int main(int argc, char **argv) {
>
>js_string *mararc_loc = 0, *errors = 0,
> *bind_address = 0, *ipv6_bind_address = 0,
> *csv2_synthip_address = 0,
> *ipv4_bind_address = 0, *incoming = 0,
> *uncomp = 0, *verbstr = 0;
>
>The js_string structure (I guess I would call it an object here in
>2016) is defined in libs/JsStr.h:
>
>typedef struct {
>unsigned char *string; /* Actual physical string */
>unsigned int unit_size; /* The size of a single character in the string */
>unsigned int unit_count; /* The length of the string, in units */
>unsigned int max_count; /* The maximum allowable size of the string,
> also in units */
>int encoding; /* The type of language/encoding the string is in */
>int is_good;/* This is checked to make sure the data structure is
> sane */
>} js_string;
>
>Point being, if we patch MaraDNS to treat this structure as a raw
>buffer instead of a structure, we will be able to crash MaraDNS â but
>that doesnât mean we have found a UDP packet of death which will crash
>unpatched MaraDNS 2.0.13.
>
>I appreciate that people are performing security research with
>MaraDNS, and the fact that researchers need to resort to patching
>MaraDNS before crashing her indicates that, a decade and a half later
>MaraDNS is still a usable DNS server with a strong security record.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJYRakeAAoJEOaVDwyMMQJnHSMP/jSEFU9QxktXE+iZR0eaIgBE
/KBiSXAr6MoyIqBhlbaGtg/8aAdrxAP9U6XGvH7ntU/yuy04vOhVbl5rYVsOarg8
1mQWZ48L79ek+P5DBprnbTpoJYoscNIv6FBEH1JM3uXdK80FGajMPf7MOyJsZpPu
/Xcv0cEqrRdJClggQhEoKyz4h8EiT12yl4CvWfVRzX8TFtKGjLh0QIbeLo3OknJZ
dRYylBEf4Z+iD2C3EM8QpjuQfMYGT2YDfc6rjgNuuOl2SBliGMoH6FKXiCNAsn5Q
tfCNFNYP+6On8wfP9hRqPLfQWgxd12bWCWeFEKd0LSsxEvaFpdlwQmLshzxiRDxU
3QYw7azzzFTA6RoBgMOblravwkXY4Gi+vTQqsBqkgCdqNI1i3z6VGGn3xQAfeDFi
lAze+1S7EiEMK96uWygTjCtonoBZdZyuP3J0hQloozxV4+2njSN+H/HosEyirhwe
DVkS2excLG22+K8+PSPkKQZnPMVZQwHH6SkXyGI1uPq9PTLM1cpyqFCT1iI4tRep
3VeMkMwts0NEyRAuvXRhYnKQid71NsWBnNN4OgMtCOxU+JIWHjZzpDOamD99fvZg
/OBdCMvfQcW0YLcMRVV1hznhzfSL9+nL90FpLeeSJ6eszCM5EiAQ+mOGG3/p2t7h
f/0gUgTFaN/A9J+yvUpN
=q4mi
-END PGP SIGNATURE-
Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports
Sam and others,
I most deeply apologize, you are right in your assessment.
I somehow missed the extra four additional sanity checks at the
beginning of the getudp() function that seems to catch the error
conditions on those input buffers.
Cheers,
--
Ondřej Surý
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server
Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware,
fast DNS(SEC) resolver
Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro
pečení chleba všeho druhu
On Sat, Dec 3, 2016, at 16:47, Sam Trenholme wrote:
> CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug
> reports.
>
> Here’s the deal: The reporter had to patch MaraDNS before he was able
> to crash her.
>
> The patch, however, treats MaraDNS’ special buffer-overflow-resistant
> “js_string” as if it were an ordinary string — but it’s not. Here’s
> the offending code patched in to MaraDNS from the reporter’s “bug
> report”:
>
> sock_num = read(0, incoming, 512);
>
> As per the man page for read:
>
> ssize_t read(int fd, void *buf, size_t count);
>
> DESCRIPTION
>read() attempts to read up to count bytes from file descriptor fd
>into
>the buffer starting at buf.
>
> However, incoming is not a raw string buffer: It’s a special js_string
> object which MaraDNS uses to be buffer overflow resistant, as can be
> seen here in server/MaraDNS.c:
>
> int main(int argc, char **argv) {
>
> js_string *mararc_loc = 0, *errors = 0,
> *bind_address = 0, *ipv6_bind_address = 0,
> *csv2_synthip_address = 0,
> *ipv4_bind_address = 0, *incoming = 0,
> *uncomp = 0, *verbstr = 0;
>
> The js_string structure (I guess I would call it an object here in
> 2016) is defined in libs/JsStr.h:
>
> typedef struct {
> unsigned char *string; /* Actual physical string */
> unsigned int unit_size; /* The size of a single character in the
> string */
> unsigned int unit_count; /* The length of the string, in units */
> unsigned int max_count; /* The maximum allowable size of the string,
>also in units */
> int encoding; /* The type of language/encoding the string is in */
> int is_good;/* This is checked to make sure the data structure is
>sane */
> } js_string;
>
> Point being, if we patch MaraDNS to treat this structure as a raw
> buffer instead of a structure, we will be able to crash MaraDNS — but
> that doesn’t mean we have found a UDP packet of death which will crash
> unpatched MaraDNS 2.0.13.
>
> I appreciate that people are performing security research with
> MaraDNS, and the fact that researchers need to resort to patching
> MaraDNS before crashing her indicates that, a decade and a half later
> MaraDNS is still a usable DNS server with a strong security record.
Bug#844121: CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports
CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302 are *NOT* valid bug reports.
Here’s the deal: The reporter had to patch MaraDNS before he was able
to crash her.
The patch, however, treats MaraDNS’ special buffer-overflow-resistant
“js_string” as if it were an ordinary string — but it’s not. Here’s
the offending code patched in to MaraDNS from the reporter’s “bug
report”:
sock_num = read(0, incoming, 512);
As per the man page for read:
ssize_t read(int fd, void *buf, size_t count);
DESCRIPTION
read() attempts to read up to count bytes from file descriptor fd into
the buffer starting at buf.
However, incoming is not a raw string buffer: It’s a special js_string
object which MaraDNS uses to be buffer overflow resistant, as can be
seen here in server/MaraDNS.c:
int main(int argc, char **argv) {
js_string *mararc_loc = 0, *errors = 0,
*bind_address = 0, *ipv6_bind_address = 0,
*csv2_synthip_address = 0,
*ipv4_bind_address = 0, *incoming = 0,
*uncomp = 0, *verbstr = 0;
The js_string structure (I guess I would call it an object here in
2016) is defined in libs/JsStr.h:
typedef struct {
unsigned char *string; /* Actual physical string */
unsigned int unit_size; /* The size of a single character in the string */
unsigned int unit_count; /* The length of the string, in units */
unsigned int max_count; /* The maximum allowable size of the string,
also in units */
int encoding; /* The type of language/encoding the string is in */
int is_good;/* This is checked to make sure the data structure is
sane */
} js_string;
Point being, if we patch MaraDNS to treat this structure as a raw
buffer instead of a structure, we will be able to crash MaraDNS — but
that doesn’t mean we have found a UDP packet of death which will crash
unpatched MaraDNS 2.0.13.
I appreciate that people are performing security research with
MaraDNS, and the fact that researchers need to resort to patching
MaraDNS before crashing her indicates that, a decade and a half later
MaraDNS is still a usable DNS server with a strong security record.
