Bug#844121: Remote crash in MaraDNS 2.0.13
This email concerns CVE-2016-9300, CVE-2016-9301, and CVE-2016-9302. I have written a utility to send the packets that supposedly remotely crash MaraDNS to MaraDNS via UDP. The packets do not crash MaraDNS when sent over the network; I can only crash MaraDNS with the offending packets by using the reporter’s patch to update MaraDNS to get DNS packets via standard input, and only in my 64-bit Cygwin development environment. I am closing this issue; I will open this again if someone can come up with an actual "send this UDP packet and MaraDNS crashes" recipe. Please let me know which OS and which processor architecture the crash happens on, but if the OS is anything besides CentOS6 or the architecture anything besides x86 (32-bit) or amd_64/x86-64 (64-bit), I will not be able to address the concern without a patch being provided. Further discussion of this matter can be done by either replying to this email, or by adding a note to https://github.com/samboy/MaraDNS/issues/33 Again, I will reopen this issue as a critical security issue if and only if someone can reproduce this concern via an actual UDP packet sent to MaraDNS. Please provide the source code of the program generating the packet of death, or use the program I wrote to attempt to reproduce this issue at https://github.com/samboy/MaraDNS/blob/1dba9f49e9b6f788cf602695478edcb094a0cc06/sqa/sendpacket.c (sqa/sendpacket.c if you clone the Github tree as of 2016-12-03). Ondrej: If you were to provide a patch, or even a usable stack trace -- or even just let me know on which distribution and architecture you're seeing the issue (sorry, but I couldn't get a usable core file or stack trace in Cygwin-64, and no crash at all in CentOS6-32bit) -- I will open up a GitHub bug about the issue. I agree there is probably a bug in MaraDNS -- but I will not treat this as an "all hands on deck" packet-of-death level security bug until we can send an actual packet of death over UDP to kill MaraDNS. On Sat, Dec 3, 2016 at 6:04 AM, Sam Trenholme wrote: > Github bug: https://github.com/samboy/MaraDNS/issues/33 > > Please go here to get the latest updates from upstream about this issue. > > On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme wrote: > >> Hello there, >> >> I have just become aware of this bug. Right now, I can reproduce the >> crash in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit >> CentOS6 development environment where I would actually be able to get a >> full stack trace (which was not provided in the original bug report). Until >> I can get a setup to reproduce the crashes in a manner which lets me have >> full stack traces, I will not be able to make the appropriate patches to >> fix the bug. >> >> There is no money on the table, and I have stopped actively developing >> MaraDNS every since becoming a single parent with a full-time job. Welcome >> to the world of open source economics: Since I’m not getting paid for my >> time writing open-source software, I have very little time to devote to >> MaraDNS. >> >> I will open up a GitHub bug so that users know I am aware of the bug. I >> do not have a time frame for fixing the issue at this time. Hopefully by >> the end of the year. >> >> -- Sam >> >> On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello >> wrote: >> >>> Source: maradns >>> Severity: grave >>> Version: 2.0.13-1.2 >>> Tags: security upstream >>> >>> Hi, >>> >>> The following vulnerability was published for MaraDNS: >>> http://seclists.org/oss-sec/2016/q4/411 >>> >>> No CVE is was assigned yet, but the request was made in that thread. >>> If you fix the vulnerability please also make sure to include the >>> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if >>> it is >>> assigned soon. >>> >>> Please adjust the affected versions in the BTS as needed. >>> >>> Regards,luciano >>> >>> >> >
Bug#844121: Remote crash in MaraDNS 2.0.13
Github bug: https://github.com/samboy/MaraDNS/issues/33 Please go here to get the latest updates from upstream about this issue. On Sat, Dec 3, 2016 at 5:52 AM, Sam Trenholme wrote: > Hello there, > > I have just become aware of this bug. Right now, I can reproduce the crash > in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6 > development environment where I would actually be able to get a full stack > trace (which was not provided in the original bug report). Until I can get > a setup to reproduce the crashes in a manner which lets me have full stack > traces, I will not be able to make the appropriate patches to fix the bug. > > There is no money on the table, and I have stopped actively developing > MaraDNS every since becoming a single parent with a full-time job. Welcome > to the world of open source economics: Since I’m not getting paid for my > time writing open-source software, I have very little time to devote to > MaraDNS. > > I will open up a GitHub bug so that users know I am aware of the bug. I do > not have a time frame for fixing the issue at this time. Hopefully by the > end of the year. > > -- Sam > > On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello > wrote: > >> Source: maradns >> Severity: grave >> Version: 2.0.13-1.2 >> Tags: security upstream >> >> Hi, >> >> The following vulnerability was published for MaraDNS: >> http://seclists.org/oss-sec/2016/q4/411 >> >> No CVE is was assigned yet, but the request was made in that thread. >> If you fix the vulnerability please also make sure to include the >> CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if >> it is >> assigned soon. >> >> Please adjust the affected versions in the BTS as needed. >> >> Regards,luciano >> >> >
Bug#844121: Remote crash in MaraDNS 2.0.13
Hello there, I have just become aware of this bug. Right now, I can reproduce the crash in Cygwin 64-bit, but am unable to reproduce the crash in my 32-bit CentOS6 development environment where I would actually be able to get a full stack trace (which was not provided in the original bug report). Until I can get a setup to reproduce the crashes in a manner which lets me have full stack traces, I will not be able to make the appropriate patches to fix the bug. There is no money on the table, and I have stopped actively developing MaraDNS every since becoming a single parent with a full-time job. Welcome to the world of open source economics: Since I’m not getting paid for my time writing open-source software, I have very little time to devote to MaraDNS. I will open up a GitHub bug so that users know I am aware of the bug. I do not have a time frame for fixing the issue at this time. Hopefully by the end of the year. -- Sam On Sat, Nov 12, 2016 at 10:18 AM, Luciano Bello wrote: > Source: maradns > Severity: grave > Version: 2.0.13-1.2 > Tags: security upstream > > Hi, > > The following vulnerability was published for MaraDNS: > http://seclists.org/oss-sec/2016/q4/411 > > No CVE is was assigned yet, but the request was made in that thread. > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if it > is > assigned soon. > > Please adjust the affected versions in the BTS as needed. > > Regards,luciano > >
Bug#844121: Remote crash in MaraDNS 2.0.13
Control: retitle -1 maradns: CVE-2016-9300 CVE-2016-9301 CVE-2016-9302 Hi, Three CVEs have been assigned in meanwhile for the found issues. Cf. http://www.openwall.com/lists/oss-security/2016/11/14/8 Regards, Salvatore
Processed: Re: Bug#844121: Remote crash in MaraDNS 2.0.13
Processing control commands: > retitle -1 maradns: CVE-2016-9300 CVE-2016-9301 CVE-2016-9302 Bug #844121 [src:maradns] Remote crash in MaraDNS 2.0.13 Changed Bug title to 'maradns: CVE-2016-9300 CVE-2016-9301 CVE-2016-9302' from 'Remote crash in MaraDNS 2.0.13'. -- 844121: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844121 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#844121: Remote crash in MaraDNS 2.0.13
Source: maradns Severity: grave Version: 2.0.13-1.2 Tags: security upstream Hi, The following vulnerability was published for MaraDNS: http://seclists.org/oss-sec/2016/q4/411 No CVE is was assigned yet, but the request was made in that thread. If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry, if it is assigned soon. Please adjust the affected versions in the BTS as needed. Regards,luciano
