home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / hacking / internet / bind96.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  6.2 KB  |  163 lines
  1.  
  2.  
  3.                         ######    ##   ##    ######
  4.                         ##        ###  ##      ##
  5.                         ######    ## # ##      ##
  6.                             ##    ##  ###      ##
  7.                         ###### .  ##   ## .  ###### .
  8.  
  9.                             Secure Networks Inc.
  10.  
  11.                              Security Advisory
  12.                              November 18, 1996
  13.  
  14.                     Vulnerability in Unchecked DNS Data.
  15.  
  16. In research for our upcoming network auditing tool, we have uncovered a
  17. serious problem present in implementations of BIND which trust invalid data
  18. sent to them.  This vulnerability specifically applies to hostname to address
  19. resolution and can result in local and remote users obtaining root privileges.
  20.  
  21. It is recommended that security conscious users upgrade to the latest version
  22. of the BIND resolver immediately.  Information on obtaining the latest
  23. official release is provided at the end of this message.
  24.  
  25. Technical Details
  26. ~~~~~~~~~~~~~~~~~
  27.  
  28. When a standard hostname lookup is performed on internet connected systems,
  29. the resulting address should be 4 bytes (Forgetting about IPv6 for now).
  30. Assuming that the address will always be 4 bytes, many privileged and
  31. unprivileged programs (including network daemons) trust the address length
  32. field which is returned from gethostbyname() in the hostent structure.  By
  33. trusting the length field returned by DNS to be 4 bytes, it then copies the
  34. address into a 4 byte address variable.  The vulnerability exists due to the
  35. fact that we can specify the size of IP address data within the DNS packet
  36. ourselves.  By specifying a size larger than 4 bytes, an overflow occurs, as
  37. the program attempts to copy the data into the 4 byte structure it has
  38. allocated to store the address.
  39.  
  40. One example of this vulnerability occurs in rcmd.c, the standard BSD library
  41. routine which is used by rsh and rlogin to remotely connect to systems.  Note
  42. that the code itself is not faulty, however the resolver implementation is.
  43. Example code follows:
  44.  
  45.    hp = gethostbyname(*ahost);
  46.    if (hp == NULL) {
  47.       herror(*ahost);
  48.       return (-1);
  49.    }
  50.    *ahost = hp->h_name;
  51.  
  52.    .
  53.    .
  54.    .
  55.  
  56.    bzero(&sin, sizeof sin);
  57.    sin.sin_len = sizeof(struct sockaddr_in);
  58.    sin.sin_family = hp->h_addrtype;
  59.    sin.sin_port = rport;
  60.    bcopy(hp->h_addr_list[0], &sin.sin_addr, hp->h_length);
  61.  
  62. In this example, we copy hp->h_length ammount of data into the address 
  63. variable of a sockaddr_in structure, which is 4 bytes.  The hp->h_length
  64. variable is taken directly from the DNS reply packet.  If we now look at how
  65. rcmd() declares it's variables, and after looking through rlogin with a
  66. debugger, we can determine that this is a dangerous situation.
  67.  
  68.    int rcmd(ahost, rport, locuser, remuser, cmd, fd2p)
  69.         char **ahost;
  70.         u_short rport;
  71.         const char *locuser, *remuser, *cmd;
  72.         int *fd2p;
  73.    {
  74.         struct hostent *hp;
  75.         struct sockaddr_in sin, from;
  76.         fd_set reads;
  77.  
  78. On further testing, and implementation of exploitation code, we can verify
  79. that this is indeed possible via the rlogin service. In order to exploit the 
  80. problem, we first start a program to send a fake DNS replies. 
  81.  
  82. [root@ariel] [Dec 31 1969 11:59:59pm] [~]% ./dnsfake
  83. oakmont.secnet.com(4732)->idoru.secnet.com(53) : lookup: random-domain.com (1:1)
  84. sent packet fake reply: 270 bytes
  85. idoru.secnet.com(53)->oakmont.secnet.com(4732) : reply: random-domain.com (1:1)
  86.  
  87. We then cause rcmd() within rlogin to do a host lookup and response with
  88. our false data.
  89.  
  90. [oliver@oakmont] [Dec 31 1969 11:58:59pm] [~]% whoami
  91. oliver
  92. [oliver@oakmont] [Jan 01 1970 00:00:01am] [~]% rlogin random-domain.com
  93. random-domain.com: Connection refused
  94. # whoami
  95. root
  96. #
  97.  
  98. Impact
  99. ~~~~~~
  100.  
  101. By checking common BSD sources, we can see that over 20 local programs are
  102. vulnerable to this attack, and possibly 2 remote daemons.  The possibility
  103. of exploiting local programs may seem insignificant, however if one considers
  104. an attacker somewhere on the internet intercepting DNS lookups, and inserting
  105. their own replies, it isn't.  There is a real threat of passive attacks
  106. present here, whereby any user on a network running any of these programs can
  107. be a victim. Take for instance traceroute, or ping both of which fall prey
  108. to this problem.
  109.  
  110. Aside from stock UN*X programs which ship with most vendor operating systems,
  111. there appears to be problems related to h_length in external software packages.
  112. Due to the flaw, FWTK (Firewall Toolkit) a freely available firewall kit
  113. appears vulnerable. The generic routine, conn_server(), which is utilizied
  114. by the proxy servers, appears to trust the data as well.
  115.  
  116. Vulnerable Systems
  117. ~~~~~~~~~~~~~~~~~~
  118.  
  119. At this point we would assume that most vendor systems who have incorporated
  120. BIND directly into their operating system are vulnerable. 
  121.  
  122. Solaris is not vulnerable according to Casper Dik <Casper.Dik@Holland.Sun.COM>
  123.  
  124. Fix Information
  125. ~~~~~~~~~~~~~~~
  126.  
  127. The maintainers of BIND, and CERT were notified of this problem several
  128. months previous to this posting.
  129.  
  130. We recommend upgrading to the latest release of BIND which solves this
  131. problem due to the incorporation of IPv6 address support.
  132.  
  133. The latest official release of BIND is availible at:
  134.  
  135. ftp.vix.com in the directory /pub/bind/release/4.9.5
  136.  
  137.  
  138.  
  139. We wish to acknowledge and thank Theo Deraadt, the maintainer of the OpenBSD
  140. operating system for his help in finding and analyzing this problem.  More 
  141. information on OpenBSD can be found at http://www.openbsd.org.
  142.  
  143. - Oliver Friedrichs <oliver@secnet.com>
  144.  
  145. -----BEGIN PGP PUBLIC KEY BLOCK-----
  146. Version: 2.6.3ia
  147.  
  148. mQCNAzJATn0AAAEEAJeGbZyoCw14fCoAMeBRKiZ3L6JMbd9f4BtwdtYTwD42/Uz1
  149. A/4UiRJzRLGhARpt1J06NVQEKXQDbejxGIGzAGTcyqUCKH6yNAncqoep3+PKIQJd
  150. Kd23buvbk7yUgyVlqQHDDsW0zMKdlSO7rYByT6zsW0Rv5JmHJh/bLKAOe7p9AAUR
  151. tCVPbGl2ZXIgRnJpZWRyaWNocyA8b2xpdmVyQHNlY25ldC5jb20+iQCVAwUQMkBO
  152. fR/bLKAOe7p9AQEBOAQAkTXiBzf4a31cYYDFmiLWgXq0amQ2lsamdrQohIMEDXe8
  153. 45SoGwBzXHVh+gnXCQF2zLxaucKLG3SXPIg+nJWhFczX2Fo97HqdtFmx0Y5IyMgU
  154. qRgK/j8KyJRdVliM1IkX8rf3Bn+ha3xn0yrWlTZMF9nL7iVPBsmgyMOuXwZ7ZB8=
  155. =xq4f
  156. -----END PGP PUBLIC KEY BLOCK-----
  157.  
  158.    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
  159.       Oliver Friedrichs   -   (403) 262-9211   -   Secure Networks Inc.
  160.          Suite 440, 703-6th Avenue S.W. Calgary, AB, Canada, T2P 0T9
  161.  
  162.  
  163.