Re: [HACKERS] a vulnerability in PostgreSQL

2002-06-12 Thread Tatsuo Ishii
> Do we need to do any more work to document this problem? Better documetation will be welcome. However which document? -- Tatsuo Ishii > --- > > Tatsuo Ishii wrote: > > > Oops. How about: > > > > > > foo'; DROP TABLE t1;

Re: [HACKERS] a vulnerability in PostgreSQL

2002-06-12 Thread Bruce Momjian
Do we need to do any more work to document this problem? --- Tatsuo Ishii wrote: > > Oops. How about: > > > > foo'; DROP TABLE t1; -- foo > > > > The last ' gets removed, leaving -- (81a2). > > > > So you get: > > select

Re: [HACKERS] a vulnerability in PostgreSQL

2002-06-01 Thread Bruce Momjian
Trond Eivind Glomsrød wrote: > Postgresql doesn't support upgrades[1], so if we're going to release > upgrades[2], we'd need the backported fixes for 6.5, 7.0 and 7.1 > > [1] Not the first time I mention this, is it? There is now /contrib/pg_upgrade. It has all the things I can think of for up

Re: [HACKERS] a vulnerability in PostgreSQL

2002-06-01 Thread Bruce Momjian
Tatsuo Ishii wrote: > >I hope you won't make this standard practice. Because there are quite > >significant differences that make upgrading from 7.1.x to 7.2 troublesome. > >I can't name them offhand but they've appeared on the list from time to time. > > I tend to agree above but am not sure m

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-03 Thread Tatsuo Ishii
> > Oops. How about: > > > > foo'; DROP TABLE t1; -- foo > > > > The last ' gets removed, leaving -- (81a2). > > > > So you get: > > select ... '(0x81a2)'; DROP TABLE t1; -- (0x81a2) > > This surely works:-< Ok, you gave me an enough example that shows even > 7.1.x and 7.0.x are not safe. > >

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-03 Thread Trond Eivind Glomsrød
Tom Lane <[EMAIL PROTECTED]> writes: > Tatsuo Ishii <[EMAIL PROTECTED]> writes: > > Here are the precise conditions to trigger the scenario: > > > (1) the backend is PostgreSQL 6.5.x > > (2) multibyte support is enabled (--enable-multibyte) > > (3) the database encoding is SQL_ASCII (other encod

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-03 Thread Lamar Owen
On Thursday 02 May 2002 11:43 pm, Lincoln Yeoh wrote: > Any idea which versions of Postgresql have been bundled with O/S CDs? For RedHat: 5.0 -> PG6.2.1 5.1 -> PG6.3.2 5.2 -> PG6.3.2 6.0 -> PG6.4.2 6.1 -> PG6.5.2 (I think -- this was my first RPMset in Red Hat Linux, but I'm

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-03 Thread Bradley Kieser
ngs from commercial companies.). Well, that's my hat in the ring. Hope that it helps someone out there or at least adds something to our pooled knowledge! Brad Kieser.net >>>>>>>>>>>>>>>>>> Original Message <<<<<<<&

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Lincoln Yeoh
I hope you won't make this standard practice. Because there are quite significant differences that make upgrading from 7.1.x to 7.2 troublesome. I can't name them offhand but they've appeared on the list from time to time. For 6.5.x to 7.1.x I believe there are smaller differences, even so ther

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Tom Lane
Tatsuo Ishii <[EMAIL PROTECTED]> writes: > Here are the precise conditions to trigger the scenario: > (1) the backend is PostgreSQL 6.5.x > (2) multibyte support is enabled (--enable-multibyte) > (3) the database encoding is SQL_ASCII (other encodings are not > affected by the bug). > (4) th

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Tatsuo Ishii
> Oops. How about: > > foo'; DROP TABLE t1; -- foo > > The last ' gets removed, leaving -- (81a2). > > So you get: > select ... '(0x81a2)'; DROP TABLE t1; -- (0x81a2) This surely works:-< Ok, you gave me an enough example that shows even 7.1.x and 7.0.x are not safe. Included are patches for

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Lincoln Yeoh
Oops. How about: foo'; DROP TABLE t1; -- foo The last ' gets removed, leaving -- (81a2). So you get: select ... '(0x81a2)'; DROP TABLE t1; -- (0x81a2) Would that work? Or do you need to put a semicolon after the --? Alternatively would select (0x81a2) be a syntax error? If it isn't then that

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Tatsuo Ishii
> Not tested: but how about the string being > foo'; DROP TABLE T1; foo > > Would the last ' be eaten up then resulting in no error? Even the last ' is eaten up, the remaining string is (81a2), which would cause parser errors since they are not valid SQL, I think. > Also normally a \ would be q

Re: [HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Lincoln Yeoh
Not tested: but how about the string being foo'; DROP TABLE T1; foo Would the last ' be eaten up then resulting in no error? Also normally a \ would be quoted by \\ right? Would a foo\ result in an unquoted \ ? An unquoted backslash may allow some possibilities. There could be other ways to ge

[HACKERS] a vulnerability in PostgreSQL

2002-05-02 Thread Tatsuo Ishii
There is a report from a debian user about a vulnerability in PostgreSQL pre 7.2. Here is a possible attack scenario which allows to execute ANY SQL in PostgreSQL. A web application accepts an input as a part of SELECT qualification clause. With the user input, the web server program would build