Date: Sun, 30 May 1999 17:16:22 +0200 (CEST) From: Sebastian 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 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 To: BUGTRAQ@netspace.org Subject: Re: weaknesses in dns label decoding, denial of service attack (code included) bobk 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 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 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 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 To: BUGTRAQ@netspace.org Subject: Re: weaknesses in dns label decoding, denial of service attack (code included) On Jun 2, 1999, Dag-Erling Smorgrav wrote: > bobk 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 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?
    foobar.au_example.net
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 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 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 Sitaker 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 To: BUGTRAQ@netspace.org Subject: Re: weaknesses in dns label encoding Kragen Sitaker 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: |> ::= *["."] |> ::= [*[]] 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 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