COMMAND

	libc & BIND buffer overflow is DNS resolver functions and others

SYSTEMS AFFECTED

	 Probably all libc\'s till recently (27 June 2002)

	 BIND 4.9.8 and earlier

	 

PROBLEM

	In Joost Pol  [joost@pine.nl]  of  pine  [http://www.pine.nl/]  advisory
	[#pine-cert-20020601 :
	

	There is a  remote  buffer  overflow  in  the  resolver  code  of  libc.
	Exploitability will vary on application-specific issues.
	

	This will allow an  attacker-controlled  DNS  server  to  reply  with  a
	carefully crafted message to  (for  example)  a  gethostbyname  request.
	This reply will trigger the buffer overflow.
	

	

	 Update (05 July 2002)

	 ======

	

	Florian         Weimer         of          Stuttgart          University
	[http://CERT.Uni-Stuttgart.DE/people/fw/] comments on :
	

	At the moment, we face three different DNS-related issues:
	 

	   (1) Misuse of dn_expand(), which does not return the number of

	       extracted bytes, but the number of bytes consumed from the input

	       buffer (can be less than the first byte count).

	

	   (2) Complete lack of bounds checking in a subroutine used by the

	       getnetby*() functions.

	  

	   (3) A sendmail 8.12 issue which involves DNS TXT records

	       (see http://www.kb.cert.org/vuls/id/814627).

	

	(3) is a completely separate issue and is not covered  further  in  this
	message. (It\'s not  a  problem  with  typical  sendmail  configurations
	anyway.)
	

	I think on Wednesday last week, PINE-CERT announced  (1),  hinting  that
	it is BSD-specific. The *BSD people rapidly provided  patches.  However,
	problem (1) is present in the resolver library shipped with  BIND  4.9.8
	and earlier, so it affects a wider  range  of  systems.  In  1999,  Olaf
	Kirch discovered this problem in the GNU libc code, and it was fixed  in
	GNU libc 2.1.3; current GNU libc is not  vulnerable  as  a  result  (see
	http://www.kb.cert.org/vuls/id/AAMN-5BMSW2). The resolver library  which
	is part of BIND 8 (and some versions of BIND 9)  contains  a  relict  of
	problem (1), so systems using this resolver are affected.
	

	Now to problem (2). Technically speaking, this  is  a  different  issue,
	not related to the peculiarities of the dn_expand()  return  value.  The
	OpenBSD developers  patched  it  on  said  Wednesday,  while  they  were
	addressing problem (1), and I don\'t know if it had been  on  the  radar
	screen of PINE-CERT at all. Problem (2) is present  in  the  BIND  4.9.8
	sources and earlier, it does *not* apply to BIND 8.3.2 and  earlier  (at
	least no such change is in BIND 8.3.3). *However*, code affected by  (2)
	has been copied to the resolv/nss_dns code  in  GNU  libc,  which  means
	that GNU libc is vulnerable to  this  particular  bug.  (This  has  been
	discovered by Andreas Schwab by SuSE Labs.)
	

	What about workarounds? ISC claims that BIND 9 can  filter  out  attacks
	for (1) because they involve syntactically invalid DNS answers.
	

	I\'m not sure if this  is  the  case  with  problem  (2):  most  likely,
	completely missing bounds checking is  problematic  for  *any*  kind  of
	answer, even a syntactically correct one. However,  on  GNU/Linux  there
	is a workaround, thanks to the Name Service Switch. If the  \"networks\"
	line in /etc/nsswitch.conf reads
	 

	   networks:       files

	

	(this is the default at least on Debian  GNU/Linux  and  Red  Hat  Linux
	7.1), you are on the safe  side.  DNS  queries  are  sent  only  if  the
	\"dns\" option is present. You can check whether your system  sends  DNS
	queries in response  tor  getnetby*()  function  calls  by  running  the
	following small C program and watching the network traffic:
	

	#include <netdb.h>

	

	int

	main (void)

	{

	  (void) getnetbyaddr(0, AF_INET);

	  return 0;

	}

	

	Note that not all systems  which  offer  the  Name  Service  Switch  are
	affected by (2). (getnetbyaddr() can be called by  tools  like  route(8)
	and netstat(8), in case you wonder.)

SOLUTION

	FreeBSD, NetBSD and OpenBSD CVS have been updated.
	

	New libc\'s will probably be released soon on all platforms.
	

	Get latest BIND.