COMMAND

	fetchmail overflow when retrieving IMAP mails

SYSTEMS AFFECTED

	versions prior to 5.9.10

PROBLEM

	In Mandrake security advisory MDKSA-2002:036 a  problem  was  discovered
	with versions of  fetchmail  prior  to  5.9.10  that  was  triggered  by
	retreiving mail from an IMAP server. The fetchmail client will  allocate
	an array to store  the  sizes  of  the  messages  it  is  attempting  to
	retrieve. This array size is determined by the number  of  messages  the
	server is claiming to have, and fetchmail would  not  check  whether  or
	not the number of messages the server was claiming was  too  high.  This
	would allow a malicious server to make the fetchmail process write  data
	outside of the array bounds.
	

	

	 Update (04 june 2002)

	 =======

	

	Florian Weimer [Weimer@CERT.Uni-Stuttgart.DE] added:
	

	It  appears  that  this  vulnerability  is  caused  by   some   alloca()
	implementations which do not return zero if  the  caller  requests  more
	memory than which is available.
	

	Accordingly with Nate Eldredge [neldredge@hmc.edu], This is hard to  do.
	Since alloca memory is on the stack, you have to know where  the  bottom
	of the stack is. You can get the stack size from getrlimit(2),  but  now
	you need to know where the  top  is.  On  Linux  at  least,  this  is  a
	compile-time kernel constant whose value depends on such things  as  the
	amount of memory in the machine. I\'m not  aware  of  any  good  way  to
	query it.
	

	Furthermore, having to do a getrlimit(2) on each alloca  call  tends  to
	defeat the purpose of alloca, which is mainly to be very fast.  On  many
	systems it\'s a single instruction. But  if  you  throw  in  the  system
	call, then you might as well call `malloc\' instead.

SOLUTION

	Upgrade to 5.9.11