Bugzilla – Bug 64986
VUL-0: CVE-2005-0038: potential new DNS problem with recursive queries
Last modified: 2021-11-04 16:01:27 UTC
*** THIS IS NOT PUBLIC. PLEASE KEEP INSIDE SUSE *** Ed, Thank you for your interest, the requested tool is attached; this is a single Perl script. The details of the flaw is below: The text portions of DNS messages are specified by first giving the character count, followed by the characters themselves. For example to specify 'test.test.com', the message would look like '0x04test0x04test0x03com0x00' using 16-bit numbers. From RFC1035, Section 4.1.4 "Message Compression" specifies a way to create smaller messages so that they can easily fit into a DNS UDP packet. So if the top two bits of the label length byte are 1, the remaining 14 bits specify an offset from the beginning of the text on where the remaining characters can be found. This way, redundant information can be removed and hence making the message smaller. For example, consider a response that would contain 'one.test.com', 'two.test.com' and 'three.test.com'. The naïve approach would then be: 0x03one0x04test0x03com0x00 0x03two0x04test0x03com0x00 0x05three0x04test0x03com0x00 But using compression, this would become: 0x03one0x04test0x03com0x00 0x03two0x0c6 0x05three0x0c6 The '0x0c6' part instructs DNS to obtain 'test.com' from the first string. Given this type of reply, the most obvious method to decode the message is by using recursion. However consider a message containing: 0x04test0xc0 With this message, once the end of the string is reached, the DNS process is instructed to return to where it started; if recursion is used to decode the message, then eventually the stack will fall over and the DNS service will terminate. Please share your findings with us, this will be greatly appreciated. Regards, Christine --------------------- Christine Vulnerability Analyst NISCC (http://www.niscc.gov.uk) Tel: +44 (0)870 1144557 This information is supplied in confidence by the NISCC and may not be disclosed other than to the agreed readership, without prior reference to the NISCC. Within the UK, this material may be exempt from disclosure under the relevant Freedom of Information Acts. This material may be subject to exemption under the Environmental Information Regulations. It may also be subject to exemption as set out in Section 28 of the Data Protection Act. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This email message has been swept for computer viruses.
<!-- SBZ_reproduce --> see attachment
Created attachment 27762 [details] checkrecurse.pl perl test program
against SLES 9: 14:32:19.342095 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], length: 50) grape.suse.de.ddi-udp-1 > grape.suse.de.domain: [bad udp cksum c50e!] 17+[| domain] 0000 0000 0000 0000 0000 0000 0800 4500 0032 0000 4000 4011 24d6 0a0a 00e9 0a0a 00e9 22b8 0035 001e 1615 0011 0100 0001 0000 0000 0000 0474 6573 74c0 0c01 0001 14:32:19.342841 IP (tos 0x0, ttl 64, id 8, offset 0, flags [DF], length: 40) grape.suse.de.domain > grape.suse.de.ddi-udp-1: [bad udp cksum 2fd6!] 17 FormErr- [0q] 0/0/0 (12) 0000 0000 0000 0000 0000 0000 0800 4500 0028 0008 4000 4011 24d8 0a0a 00e9 0a0a 00e9 0035 22b8 0014 160b 0011 8101 0000 0000 0000 0000 so it seems sles9 is not affected.
tested with bind8 on sles8-ppc... no proble,ms there too. so i guess bind is not affected.
<!-- SBZ_reopen -->Reopened by thomas@suse.de at Thu Feb 3 18:04:27 2005, took initial reporter meissner@suse.de to cc
We got 2 new test scripts. Can you try them please?
Created attachment 28192 [details] checkrecurse-2.pl
Created attachment 28193 [details] checkrecurse-3.pl
I tested both scripts on bind 9.3.0 which will be on SL9.3 and on SLES9 SP1 (i586). None of the scripts let any of the binds crash.
thanks.
[-- BEGIN PGP SIGNED MESSAGE --] Dear Colleagues, Many thanks to everyone for your assistance with the handling of this issue; there have been some new developments and hence the release date will now be delayed. I was contacted by the originator and he informed me that he would like us to include DNS clients into the issue as well. The vulnerability under the above tracking number can also be applied to DNS clients, but because the originator came across the flaw whilst developing a DNS server our initial focus was only on the server-side. After much thought he has decided that we should also cover DNS clients. Because of this new development, the release date will now be delayed as we do not want to release information that can be used against DNS clients before the vendors have had a chance to develop patches for any vulnerable products. The originator will develop a test tool for testing against DNS clients; but whilst we are waiting for this new tool, please feel free to conduct your own testing against your DNS clients. However please ensure that you share your findings with us, as this will aid us greatly in deciding on a new release date. Many apologies to those vendors who do not produce DNS clients and hence are ready for this issue to be released; your patience is greatly appreciated. Also please be reminded that this issue still needs to be kept confidential. Regards, Christine ---------------------
ok, here we go. Hi, we received informations about a new test case. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Colleagues, I have just been notified by the originator that there is another test that can be applied to DNS servers and clients: the suggestion is to make a slight modification to the script so that it points off the end of the query, instead of just to the beginning or to itself. Also please be reminded that this issue will be released on the 24 May at 1pm BST; an draft advisory will be sent out in May for your peruse. Thank you for your continued assistance with the handling of this vulnerability. Regards, Christine - --------------------- Christine Vulnerability Analyst NISCC Vulnerability Team URL: http://www.niscc.gov.uk Tel: +44 (0)870 1144557 This information is supplied in confidence by the NISCC and may not be disclosed other than to the agreed readership, without prior reference to the NISCC. Within the UK, this material may be exempt from disclosure under the relevant Freedom of Information Acts. This material may be subject to exemption under the Environmental Information Regulations. It may also be subject to exemption as set out in Section 28 of the Data Protection Act. If you have received this email in error please return it to the address it came from telling them it is not for you and then delete it from your system. This email message has been swept for computer viruses. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQCVAwUBQnI+6MY9obE5q+3HAQIPsgP6AnnVYe5wScr2hoBxNCq2QgwBVGnW8+V1 6AhnoRr39YtwQhqsaNWw3aQyQRJau+o+6qVbIArI/KmvEK5CvM1PiwyXmyu2Gb0Q DNtl5wmMLHHzD3CuwoS6cUFTLBoOciFi+awTDr9Bg8sDfskFlkeJpBtJ76VBO1H5 hVhAT2dgpPg= =Rwua -----END PGP SIGNATURE-----
I'm a little bit puzzled about this bug at all. I mean, if someone should know which versions of bind are affected, it should be the ISC and they would be very interested in this. If there are any bind versions affected, they will release a security update. I mean, what sense does it make that we test that strange script again and again against our different versions of bind? I don't know who that Vulnerability Analyst from the NISCC Vulnerability Team is but why doesn't he communicate with ISC? They would handle that information confidential for sure.
I don't know about the political reasons (ISC sometimes behaves strange regarding open-source folks, and NISCC is a UK gov institue) and I am not sure if they do not negotiate a release date or something. But you are right, let's wait how ISC react on this. Let's keep the new info for the sake of completeness and wait what happens.
CAN-2005-0036 CAN-2005-0037 CAN-2005-0038
okay, for all that I see, our bind versions are not affected?
I read the CAN-* stuff and for me it looks like we have nothing to do -> closed
CVE-2005-0038: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)