Tom Lane wrote:
> 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.
Should we be thinking about a 7.4.3? I think we are waiting for
pg_autovacuum fixes though.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073