In 2002, when I rewrote the compression code for MaraDNS for the first time, I made a mistake in allocating an array of integers, allocating it in bytes instead of sizeof(int) units. The resulted in a buffer being too small, allowing it to be overwritten.
The impact of this programming error is that MaraDNS can be crashed by sending MaraDNS a single "packet of death". Since the data placed in the overwritten array can not be remotely controlled (it is a list of increasing integers), there is no way to increase privileges exploiting this bug. The attached patch resolves this issue by allocating in sizeof(int) units instead of byte-sized units for an integer array. In addition, it uses a smaller array because a DNS name can only have, at most, 128 labels. I would like to thank Mr. Witold Baryluk for pointing out this issue, taking the time to backtrace the bug, and for bringing it to my attention by posting to the MaraDNS mailing list. However, I need to let him know that making this public by filing a public Debian bug without first trying to contact me is not the appropriate way to handle a security problem with MaraDNS. The appropriate way to do so is via private email. My email address is here: http://samiam.org/mailme.php (mara...@gmail.com was an account created so I could make entries in an older MaraDNS blog, and is not presently actively looked at) As it turns out, I only occasionally look at the Debian bug database and people with issues with MaraDNS would be better off joining the MaraDNS mailing list instead of filing a Debian bug (unless the issue is Debian-specific). In response to this bug, I have released MaraDNS 1.4.06 and 1.3.07.11. These releases are available here: http://maradns.org/download.html Since sourceforge.net has recently suffered a security breach, their file uploading feature is currently undergoing maintenance and new files currently can not be uploaded there. I have not made a new release of MaraDNS 2.0 yet. Yarin has contributed a number of patches, and I would like to integrate his patches before making a new MaraDNS 2.0 release; MaraDNS 2.0 users can use the supplied patch. As an aside, I have become a better programmer since making this mistake back in 2002. Deadwood, which is a complete rewrite of MaraDNS' recursive code, does not have this issue in its compression/decompression code. Instead of using different data types in structures, Deadwood, by and large, uses special overflow-resistant strings to store most data. Also, I would like to take the time to make a public service announcement for djbdns users: DjbDNS 1.05 does have known security issues, and needs to be patched. More details are here: http://samiam.org/blog/20110103.html (I am making this announcement because I have seen people, as recently as last year, claiming djbdns-1.05 is perfectly secure on public forums) - Sam --- maradns-1.4.05/dns/Compress.c 2010-07-31 01:17:08.000000000 -0600 +++ maradns-1.4.06/dns/Compress.c 2011-01-28 18:28:46.000000000 -0700 @@ -22,7 +22,7 @@ #include "functions_dns.h" /* Maximum allowed number of dlabel points */ -#define MAX_DLABEL_POINTS 512 +#define MAX_DLABEL_POINTS 160 /* Maximum allowed length of compressed string; this is 4096 for TCP * packets */ @@ -87,7 +87,8 @@ js_dealloc(new); return 0; } - if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,1)) == 0) { + if((new->dlabel_points = js_alloc(MAX_DLABEL_POINTS + 3,sizeof(int))) + == 0) { js_destroy(new->compressed); js_dealloc(new); return 0;
maradns-1.4.05-CVE-2011-0520.patch
Description: Binary data