Bug 64986 (CVE-2005-0038)

Summary:	VUL-0: CVE-2005-0038: potential new DNS problem with recursive queries
Product:	[Novell Products] SUSE Security Incidents	Reporter:	Thomas Biege <thomas>
Component:	Incidents	Assignee:	Uwe Gansert <ug>
Status:	RESOLVED INVALID	QA Contact:	Security Team bot <security-team>
Severity:	Normal
Priority:	P3 - Medium	CC:	meissner, security-team
Version:	unspecified
Target Milestone:	---
Hardware:	All
OS:	Linux
Whiteboard:	CVE-2005-0038: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---
Attachments:	checkrecurse.pl checkrecurse-2.pl checkrecurse-3.pl

Description Marcus Meissner 2005-01-19 21:27:40 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.

Comment 1 Marcus Meissner 2005-01-19 21:27:41 UTC

<!-- SBZ_reproduce  -->
see attachment

Comment 2 Marcus Meissner 2005-01-19 21:28:17 UTC

Created attachment 27762 [details]
checkrecurse.pl

perl test program

Comment 3 Marcus Meissner 2005-01-19 21:34:32 UTC

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.

Comment 4 Marcus Meissner 2005-01-19 21:53:09 UTC

tested with bind8 on sles8-ppc... no proble,ms there too. 
 
so i guess bind is not affected.

Comment 5 Thomas Biege 2005-02-04 01:04:27 UTC

<!-- SBZ_reopen -->Reopened by thomas@suse.de at Thu Feb  3 18:04:27 2005, took initial reporter meissner@suse.de to cc

Comment 6 Thomas Biege 2005-02-04 01:04:27 UTC

We got 2 new test scripts.

Can you try them please?

Comment 7 Thomas Biege 2005-02-04 01:04:51 UTC

Created attachment 28192 [details]
checkrecurse-2.pl

Comment 8 Thomas Biege 2005-02-04 01:05:08 UTC

Created attachment 28193 [details]
checkrecurse-3.pl

Comment 9 Uwe Gansert 2005-02-04 21:30:35 UTC

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.

Comment 10 Thomas Biege 2005-02-09 06:15:58 UTC

thanks.

Comment 11 Thomas Biege 2005-02-14 16:17:00 UTC

[-- 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 
 
---------------------

Comment 12 Thomas Biege 2005-05-25 09:44:57 UTC

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-----

Comment 13 Uwe Gansert 2005-05-25 10:12:54 UTC

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.

Comment 14 Thomas Biege 2005-05-25 10:22:27 UTC

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.

Comment 15 Ludwig Nussel 2005-06-01 14:30:45 UTC

CAN-2005-0036 
CAN-2005-0037 
CAN-2005-0038

Comment 16 Uwe Gansert 2005-06-01 14:42:25 UTC

okay, for all that I see, our bind versions are not affected?

Comment 17 Uwe Gansert 2005-06-02 08:13:05 UTC

I read the CAN-* stuff and for me it looks like we have nothing to do -> closed

Comment 18 Thomas Biege 2009-10-13 20:58:52 UTC

CVE-2005-0038: CVSS v2 Base Score: 5.0 (AV:N/AC:L/Au:N/C:N/I:N/A:P)