Re: Probably security hole in postgresql-7.4.1 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Probably security hole in postgresql-7.4.1
Date
Msg-id 14690.1084306935@sss.pgh.pa.us
Whole thread Raw
In response to Probably security hole in postgresql-7.4.1  (Ken Ashcraft <ken@coverity.com>)
Responses Re: Probably security hole in postgresql-7.4.1  (Bruce Momjian <pgman@candle.pha.pa.us>)
Re: Probably security hole in postgresql-7.4.1  ("Ken Ashcraft" <ken@coverity.com>)
List pgsql-hackers
Ken Ashcraft <ken@coverity.com> writes:
> I work at Coverity where we use static analysis to find bugs in
> software.  I ran a security checker over postgresql-7.4.1 and I think I
> found a security hole.
>
> In the code below, fld_size gets copied in from a user specified file. 
> It is passed as the 'needed' parameter to enlargeStringInfo().  If
> needed is a very large positive value, the addition 'needed += str->len
> + 1;' could cause an overflow, making needed a negative number. 

I've applied a patch that fixes this issue, as well as the related one
that enlargeStringInfo could go into an infinite loop.

Although the path of control you identify doesn't seem very threatening
(since one must already be superuser to execute COPY from a file), the
same sort of problem could be triggered by sending a malformed data
packet, thus opening up the problem to anyone who can get past the
initial postmaster authentication check.  So this is more severe than we
first thought.

If you are looking to improve your checker, you might want to look into
why it only found this path for bad data, and not the path leading from
the client connection socket.  Seems like it should've found that too.

Thanks for the report!
        regards, tom lane


pgsql-hackers by date:

Previous
From: Mike Mascari
Date:
Subject: Re: SPI and bytea columns
Next
From: Bruce Momjian
Date:
Subject: Re: Adding MERGE to the TODO list (resend with subject)