dns.label.decoding.txt

1999-08-17T00:00:00
ID PACKETSTORM:11886
Type packetstorm
Reporter scut
Modified 1999-08-17T00:00:00

Description

                                        
                                            `Date: Sun, 30 May 1999 17:16:22 +0200 (CEST)  
From: Sebastian <scut@nb.in-berlin.de>  
To: packetstorm@genocide2600.com  
Subject: weaknesses in dns label decoding, denial of service attack (code included) (fwd)  
Parts/Attachments:  
1 Shown 87 lines Text  
2 1.8 KB Application, "zlip.tar.gz"  
----------------------------------------  
  
keywords: some dns packet decoders (sniffers, ids systems (?), dns  
servers) may be vulnerable to malformed compressed domain names  
inside dns packets.   
  
  
hi,  
  
as I played with the DNS RFC (1035 especially) i came up with the idea to  
create malformed compressed dns domains inside the DNS packet to make it  
impossible for the DNS packet decoder to decompress it, which might lead  
to a denial of service attack.  
  
On my tests I found my BIND servers resisting all attacks (three different  
types), but all sniffers I used to view the DNS packets send to the  
server behaved in a very "special" way.  
  
  
First test (pointing-to-itself-compression (zlip-1.c))  
  
The DNS domain consists out of multiple labels, and message "compression"  
allows you to let a pointer point to a previous label inside the packet,  
to save bytes in the DNS packet. I just created a pointer that points to  
itself, meaning on a recursive domain decompression (like etherreal uses),  
this will produce effects like segfaulting or hanging.  
Etherreal alloc's memory until the system crashes, tcpdump stopped working  
before the packet is received, on SIGINT, it displays the malformed  
packet, but dropped all other packets:  
  
14:57:59.025013 128.75.9.2.48078 > victim.ns.org.domain: 30993 Type49159  
(Class 49168)?  
  
  
Second test (crossreferencing pointers (zlip-2.c))  
  
Similar to the first code, but now two pointer are used to reference each  
other, speeding up the effect on Etherreal.  
Results are the same as in the first test.  
  
  
Third test (very long label, decompressed multiple times (zlip-3.c))  
  
This time I used a long label (maximum of 63 characters), and referenced  
to it a dozend times, this will decode to a very long domain, therefore  
it may overflow some fixed-sized-buffers (because the rfc says "limited to  
500 characters" some programmers may prefer fixed buffers for dns  
decoders). This is the case in Etherreal, where such a request creates a  
segmentation fault (due to a buffer overrun).  
  
  
I just tested this with BIND as nameserver, which resisted all this tests,  
but I included the "exploit" code in this email to allow you to test your  
IDS, sniffers and nameservers against this.  
  
cu,  
scut  
  
  
--   
- scut@nb.in-berlin.de - http://nb.in-berlin.de/scut/ - sacbuctd@ircnet --  
-- you don't need a lot of people to be great, you need a few great to be --  
-- the best -----------------------------------------------------------------  
  
[ Part 2, "zlip.tar.gz" Application/X-GUNZIP 2.4KB. ]  
  
------------------------------------------------------------------------------------  
  
Date: Mon, 31 May 1999 17:49:53 -0400  
From: bobk <bobk@SINISTER.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
On Sun, 30 May 1999, Sebastian wrote:  
  
>  
> keywords: some dns packet decoders (sniffers, ids systems (?), dns  
> servers) may be vulnerable to malformed compressed domain names  
> inside dns packets.  
>  
> sorry aleph1, if this has already been known or posted =)  
>  
>  
> hi,  
>  
> as I played with the DNS RFC (1035 especially) i came up with the idea to  
> create malformed compressed dns domains inside the DNS packet to make it  
> impossible for the DNS packet decoder to decompress it, which might lead  
> to a denial of service attack.  
  
Another thing to remember is that it is possible to put ABSOLUTELY  
ANYTHING inside a DNS domain name. This includes whitespace, control  
characters, and even NULL.  
  
Imagine what could happen if some program did a strcmp() on the following  
name:  
  
rs.internic.net\0.xa.net  
  
where, of course, \0 is a null  
  
Interested readers may ponder what type of programs may be exploited with  
this type of attack.  
  
------------------------------------------------------------------------------------  
  
Date: Wed, 2 Jun 1999 20:45:09 +0200  
From: Dag-Erling Smorgrav <des@IFI.UIO.NO>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
bobk <bobk@SINISTER.COM> writes:  
> Imagine what could happen if some program did a strcmp() on the following  
> name:  
>  
> rs.internic.net\0.xa.net  
>  
> where, of course, \0 is a null  
>  
> Interested readers may ponder what type of programs may be exploited with  
> this type of attack.  
  
Any .rhosts consumer. Xhost. Amanda (.amandahosts). Lpd (lpd.allow).  
What did I win?  
  
DES  
--  
Dag-Erling Smorgrav - des@ifi.uio.no  
  
------------------------------------------------------------------------------------  
  
Date: Wed, 2 Jun 1999 23:00:27 +0200  
From: Pavel Kankovsky <peak@ARGO.TROJA.MFF.CUNI.CZ>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
On Mon, 31 May 1999, bobk wrote:  
  
> Another thing to remember is that it is possible to put ABSOLUTELY  
> ANYTHING inside a DNS domain name. This includes whitespace, control  
> characters, and even NULL.  
  
Use BIND's check-names option to refuse illegal answers.  
  
--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]  
"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"  
  
------------------------------------------------------------------------------------  
  
Date: Thu, 3 Jun 1999 06:20:41 -0600  
From: Brett Glass <brett@LARIAT.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
Many sysadmins disable BIND's "check-names" option because  
their less knowledgeable colleagues assign illegal names. In  
particular, many use underscores in system names, even though  
they're verboten.  
  
BIND *should* have a separate option that allows underscores  
in names to accommodate this frequent glitch, but it doesn't.  
So, the checking becomes all-or-nothing.  
  
--Brett  
  
At 11:00 PM 6/2/99 +0200, Pavel Kankovsky wrote:  
>On Mon, 31 May 1999, bobk wrote:  
>  
> > Another thing to remember is that it is possible to put ABSOLUTELY  
> > ANYTHING inside a DNS domain name. This includes whitespace, control  
> > characters, and even NULL.  
>  
>Use BIND's check-names option to refuse illegal answers.  
>  
>--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]  
>"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"  
  
------------------------------------------------------------------------------------  
  
Date: Thu, 3 Jun 1999 11:34:25 +1000  
From: marka@ISC.ORG  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
> bobk <bobk@SINISTER.COM> writes:  
> > Imagine what could happen if some program did a strcmp() on the following  
> > name:  
> >  
> > rs.internic.net\0.xa.net  
> >  
> > where, of course, \0 is a null  
> >  
> > Interested readers may ponder what type of programs may be exploited with  
> > this type of attack.  
>  
> Any .rhosts consumer. Xhost. Amanda (.amandahosts). Lpd (lpd.allow).  
> What did I win?  
>  
> DES  
> --  
> Dag-Erling Smorgrav - des@ifi.uio.no  
>  
If if you have a modern resolver library you won't have a  
problem as the presentation form is literally  
"rs.internic.net\000.xa.net".  
  
This may be used with old libraries to hide were you came  
from but access checks usually require a forward lookups as  
well .rhosts etc. should not be a problem even with old  
libraries.  
  
Mark  
--  
Mark Andrews, Internet Software Consortium  
1 Seymour St., Dundas Valley, NSW 2117, Australia  
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org  
  
------------------------------------------------------------------------------------  
  
Date: Thu, 3 Jun 1999 09:50:10 -0300  
From: Alexandre Oliva <oliva@DCC.UNICAMP.BR>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
On Jun 2, 1999, Dag-Erling Smorgrav <des@IFI.UIO.NO> wrote:  
  
> bobk <bobk@SINISTER.COM> writes:  
>> Imagine what could happen if some program did a strcmp() on the following  
>> name:  
  
>> rs.internic.net\0.xa.net  
  
>> where, of course, \0 is a null  
  
>> Interested readers may ponder what type of programs may be exploited with  
>> this type of attack.  
  
> Any .rhosts consumer. Xhost. Amanda (.amandahosts). Lpd (lpd.allow).  
  
> What did I win?  
  
:-)  
  
Not Amanda. After reverse mapping the incoming IP address to a  
hostname, it will lookup the IP addresses for the hostname and make  
sure the incoming IP address is one of the IP addresses listed for  
that name, so only DNS spoofing or a lame DNS cache would get Amanda  
in trouble.  
  
It is true that it will also check whether the canonical name obtained  
for the direct mapping is the same that it got in reverse mapping, and  
it uses strncasecmp here, which means it might miss a difference in  
case `\0' is part of the name, but I don't think this is a critical  
check; only the IP checking is.  
  
--  
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il  
{oliva,Alexandre.Oliva}@dcc.unicamp.br aoliva@{acm.org,computer.org}  
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}  
*** E-mail about software projects will be forwarded to mailing lists  
  
------------------------------------------------------------------------------------  
  
Date: Thu, 3 Jun 1999 11:51:04 -0400  
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
> Many sysadmins disable BIND's "check-names" option because their less  
> knowledgeable colleagues assign illegal names. In particular, many  
> use underscores in system names, even though they're verboten.  
  
> BIND *should* have a separate option that allows underscores in names  
> to accommodate this frequent glitch, but it doesn't.  
  
Why? How is it a favor to anyone to allow some illegal names but not  
others? (Of course, I don't entirely understand why check-names is  
optional at all; I can't see how it's a favor to anyone to ever accept  
illegal names....)  
  
der Mouse  
  
mouse@rodents.montreal.qc.ca  
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 4 Jun 1999 09:13:15 +1000  
From: marka@ISC.ORG  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
> Many sysadmins disable BIND's "check-names" option because  
> their less knowledgeable colleagues assign illegal names. In  
> particular, many use underscores in system names, even though  
> they're verboten.  
>  
> BIND *should* have a separate option that allows underscores  
> in names to accommodate this frequent glitch, but it doesn't.  
> So, the checking becomes all-or-nothing.  
>  
> --Brett  
  
No.  
  
There is a specification about what is legal in a hostname  
/ mailname (RHS of @). If an application is expecting a  
hostname, it should only be given hostnames. The library  
(or server) should filter out non conforment names.  
  
You do not know what the application is using as a field  
seperator and "_" is a perfectly valid character to use  
to seperate a list of hostnames.  
  
Yes I am playing devils advocate here but you have to do  
that at time to knock down silly ideas. You either enforce  
the specification you you don't bother at all.  
  
Check-names is on by default for good reason. To force people  
to become aware of what they are doing and where they are breaking  
a standard.  
  
Underscore is also a silly character to have. How many hostnames  
are in the following html fragment when you read it on a ascii  
terminal?  
  
<UL>foobar.au_example.net</UL>  
  
Mark  
  
P.S. There are interperative languages where "_" is an  
assignment operator and where a hostname could be used  
as a variable name.  
  
P.P.S. I made this arguement long before I worked for ISC  
and it is still my view.  
  
>  
> At 11:00 PM 6/2/99 +0200, Pavel Kankovsky wrote:  
> >On Mon, 31 May 1999, bobk wrote:  
> >  
> > > Another thing to remember is that it is possible to put ABSOLUTELY  
> > > ANYTHING inside a DNS domain name. This includes whitespace, control  
> > > characters, and even NULL.  
> >  
> >Use BIND's check-names option to refuse illegal answers.  
> >  
> >--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]  
> >"NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent... Hi Echelon!"  
>  
--  
Mark Andrews, Internet Software Consortium  
1 Seymour St., Dundas Valley, NSW 2117, Australia  
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 4 Jun 1999 11:35:31 -0600  
From: Brett Glass <brett@LARIAT.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label decoding, denial of service attack (code included)  
  
At 11:51 AM 6/3/99 -0400, der Mouse wrote:  
  
> How is it a favor to anyone to allow some illegal names but not  
>others?  
  
It's a first step toward eliminating the root cause of the problem:  
needlessly inconsistent standards.  
  
It's counterintuitive, and inconsistent, that some characters (the  
underscore in particular) are allowed in user names (that is, to the  
left of the "@") but not in host names (to the right of the "@").  
There's no reason for this inconsistency; it's perfectly reasonable  
to use the same character set for both.  
  
In short, the people who specify host names with underscores aren't  
"idiots" (as a few people have called them in private e-mails) --  
they just have perfectly reasonable expectations.  
  
I think that the correct answer is to make the standards consistent  
with one another. I'd also like to see an option that lets you specify,  
to BIND, the character set it will accept for host names. This would  
allow system administrators to let names with underscores pass  
without throwing the baby (that is, other checks on the name) out  
with the bath water. This option would be useful until the standards  
are changed and new software versions become widespread.  
  
--Brett Glass  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 4 Jun 1999 14:04:49 -0400  
From: Kragen Sitaker <kragen@POBOX.COM>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label encoding  
  
der Mouse wrote:  
> Why? How is it a favor to anyone to allow some illegal names but not  
> others? (Of course, I don't entirely understand why check-names is  
> optional at all; I can't see how it's a favor to anyone to ever accept  
> illegal names....)  
  
First, according to RFC 1035's recommended grammar, the following DNS  
names are invalid:  
  
3.206.238.207.in-addr.arpa  
www.inria.fr  
io.com  
  
. . . the first because it contains labels beginning with digits, and  
the others because they contain two-letter labels.  
  
Second, although it is by no means clear, it appears that  
RFC 1035 merely *recommends* the use of domain names that conform to the  
grammar, saying, "The following syntax will result in fewer problems  
with many applications that use domain names"; it does not require it.  
  
This grammar is followed by a statement saying, "The labels must follow  
the rules for ARPANET host names," followed by some explication of what  
that means. It is unclear whether this means that labels must follow  
these rules in order to conform to the recommended grammar or that  
labels must follow these rules to conform to the requirements of the  
RFC.  
  
All of this is in a section labeled, "2.3.1. Preferred name syntax".  
  
Further down, in section 5.1 where the format of the database files is  
defined, it is stated, "Quoting conventions allow arbitrary characters  
to be stored in domain names." The quoting conventions described have  
no purpose other than to allow the violation of the recommendations of  
section 2.3.1.  
  
Are there other RFCs that describe allowed syntax for domain names?  
The following RFCs are listed as updating RFC1035:  
1101  
1183  
1348  
1876  
1982  
1995  
1996  
2065  
2181  
2136  
2137  
2308  
  
I have only read a few of these.  
  
--  
<kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>  
TurboLinux is outselling NT in Japan's retail software market 10 to 1,  
so I hear.  
-- http://www.performancecomputing.com/opinions/unixriot/981218.shtml  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 4 Jun 1999 22:33:47 +0200  
From: Walter Misar <misar@RBG.INFORMATIK.TU-DARMSTADT.DE>  
To: BUGTRAQ@netspace.org  
Subject: Re: weaknesses in dns label encoding  
  
Kragen Sitaker <kragen@POBOX.COM> wrote:  
> Are there other RFCs that describe allowed syntax for domain names?  
  
Yes, probably most important 1123 (host requirements):  
  
|> The syntax of a legal Internet host name was specified in RFC-952  
|> [DNS:4]. One aspect of host name syntax is hereby changed: the  
|> restriction on the first character is relaxed to allow either a  
|> letter or a digit. Host software MUST support this more liberal  
|> syntax.  
  
Rfc 952 specifies:  
  
|> <hname> ::= <name>*["."<name>]  
|> <name> ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]  
  
All digit names are allowed, underscore is not, two letter names are ok.  
  
Walter  
  
------------------------------------------------------------------------------------  
  
Date: Fri, 4 Jun 1999 13:53:05 -0700  
From: Aleph One <aleph1@UNDERGROUND.ORG>  
To: BUGTRAQ@netspace.org  
Subject: Administrivia  
  
I am killing the domain name thread. This is not the right forum to  
be discussing whether being flexible in accepting non-standard  
compliant names is the right thing to do.  
  
As a side note, I am looking for someone with BUGTRAQ archives in mbox  
or similar format. Formats that strip header information or mess to much  
with the message, such as Hypermail, won't help. I'd appreciate it if  
you drop me a message if you have such archive.  
  
--  
Aleph One / aleph1@underground.org  
http://underground.org/  
KeyID 1024/948FD6B5  
Fingerprint EE C9 E8 AA CB AF 09 61 8C 39 EA 47 A8 6A B8 01  
  
`