TUCoPS :: Unix :: General :: unix5377.htm

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