Re: syntax error causes crafted data to be executed in shell

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Thomer M(dot) Gil" <postgresql(at)thomer(dot)com>, pgsql-bugs(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: syntax error causes crafted data to be executed in shell
Date: 2004-12-18 05:40:15
Message-ID: 28174.1103348415@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> So if a backslash command fails we discard the rest of the line?

Well, the point is that right now we *don't*. But I'm thinking we
should.

> How did user data ever get to psql in this way?

As I understand the scenario, it's that a 7.3-or-later pg_dump
could produce

COPY foo(a, b, c) FROM stdin;
col1 \N `touch gotcha`
\.

If you tried to load this dump file into a pre-7.3 server then the
server would barf on the COPY column list, which we didn't have pre-7.3,
and so it would not send the protocol command to psql to switch into
COPY IN mode. Therefore psql would read the next line as normal input
and would think that \N was a backslash command and `touch gotcha`
was a backticked argument to same.

(Thomer was waving his hands about "missing FROM" but I think that's a
thoroughly garbled report of the issue, because AFAIR no version of
pg_dump has ever emitted COPY commands without a "FROM stdin" clause.)

What this says to me is that we should be really, really cautious about
changing the format of the COPY commands emitted by pg_dump ever again.
For safety's sake they've got to be both forward and backward
compatible.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-12-18 06:00:05 Re: solaris 10 with gcc 3.3.2
Previous Message Tom Lane 2004-12-18 05:00:43 Re: posgresql 8.0 RC1 missing schemas