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