TUCoPS :: Linux :: Apps N-Z

TUCoPS :: Linux :: Apps N-Z :: lnx5642.htm
PostgreSQL Buffer Overflow
20th Aug 2002 [SBWID-5642]
COMMAND

	
		PostgreSQL buffer overflow
	
	

SYSTEMS AFFECTED

	
		PostgreSQL <= 7.2 & 7.2.1
	
	

PROBLEM

	
		Sir Mordred The Traitor in Mordred Labs Advisory [0x0001] suggests :
		

		

		psql> select cash_words('-700000000000000000000000000000');

		pgReadData() -- backend closed the channel unexpectedly.

			.... ....

		The connection to the server was lost...

		

		

		Florian  Weimer  [Weimer@CERT.Uni-Stuttgart.DE]  of  the  University  of
		Stuttgart           [http://CERT.Uni-Stuttgart.DE/people/fw/] adds :
		

		PostgreSQL 7.2.1 has a buffer overflow bug in the date parser (which  is
		invoked each time a string is converted to  a  datetime  object).  If  a
		frontend does not perform proper  date  checking  and  rejects  overlong
		date strings, a buffer is overwritten by parser. The string has to  pass
		some checks of the parser, so it is not immediately  obvious  that  this
		can be exploited. Denial of service is possible, though,  especially  if
		the  frontend  does   not   automatically   reestablish   the   database
		connection. (All connections are affected, not  just  the  one  that  is
		issueing the query.)
		

		To my knowledge, the PostgreSQL developers do not  think  this  warrants
		an additional 7.2.x release. They expect that users  do  not  trust  the
		PostgreSQL parsers and write input validation checks. That gives me  the
		creeps---how can I trust a database which manipulates complex  in-memory
		and on-disk data structures to keep my data, if  its  developers  say  I
		shouldn't rely on a simple thing they wrote, such as a date parser?
		

		A different problem: "select cash_out(2);". Known for ages,  no  fix  in
		sight (seems to be a design problem which is not easy to resolve).
	
	

SOLUTION

	
		 Update (26 August 2002)

		 ======

		

		ftp://ftp.postgresql.org/pub/sources/v7.2.2