PostgreSQL 7.2.2: Security Release

Due to recent security vulnerabilities reported on BugTraq, concerning
several buffer overruns found in PostgreSQL, the PostgreSQL Global
Development Team today released v7.2.2 of PostgreSQL that fixes these
vulnerabilities.

The following buffer overruns have been identified and addressed:

... in handling long datetime input
... in repeat()
... in lpad() and rpad() with multibyte
... in SET TIME ZONE and TZ env var

Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1, requiring no
dump-n-reload of the database, it should be noted that these
vulnerabilities are only critical on "open" or "shared" systems, as they
require the ability to be able to connect to the database before they can
be exploited.

The latest release is available at:

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

As well as at appropriate mirror sites.

Please report any bugs/problems with this release to:

pgsql-bugs(at)postgresql(dot)org

Marc G. Fournier
Co-ordinator
PostgreSQL Global Development Group

Marc G. Fournier wrote:
> Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1, requiring no
> dump-n-reload of the database, it should be noted that these
> vulnerabilities are only critical on "open" or "shared" systems, as they
> require the ability to be able to connect to the database before they can
> be exploited.

Excellent idea you pointed this out.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Marc G. Fournier wrote:
> > Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1, requiring no
> > dump-n-reload of the database, it should be noted that these
> > vulnerabilities are only critical on "open" or "shared" systems, as they
> > require the ability to be able to connect to the database before they can
> > be exploited.
>
> Excellent idea you pointed this out.

... except that it's not correct. The datetime overrun does not
require the ability to connect to the database.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

On 23 Aug 2002, Neil Conway wrote:

> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > Marc G. Fournier wrote:
> > > Although v7.2.2 is a purely plug-n-play upgrade from v7.2.1, requiring no
> > > dump-n-reload of the database, it should be noted that these
> > > vulnerabilities are only critical on "open" or "shared" systems, as they
> > > require the ability to be able to connect to the database before they can
> > > be exploited.
> >
> > Excellent idea you pointed this out.
>
> ... except that it's not correct. The datetime overrun does not
> require the ability to connect to the database.

Ack ... obviously I missed something, but, if you can't get a connection
to the database, how exactly is this one triggered? :(

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:

> On 23 Aug 2002, Neil Conway wrote:
> > The datetime overrun does not require the ability to connect to
> > the database.
>
> Ack ... obviously I missed something, but, if you can't get a
> connection to the database, how exactly is this one triggered? :(

If the application is accepting datetime input from the user ('what's
your birthday?', for example), and isn't doing some non-obvious input
validation on it (namely, checking that the input string isn't too
long), you can crash the backend. Gavin says executing arbitrary code
using the hole would be extremely difficult, but it's at least
conceivable.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

On 24 Aug 2002, Neil Conway wrote:

> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
>
> > On 23 Aug 2002, Neil Conway wrote:
> > > The datetime overrun does not require the ability to connect to
> > > the database.
> >
> > Ack ... obviously I missed something, but, if you can't get a
> > connection to the database, how exactly is this one triggered? :(
>
> If the application is accepting datetime input from the user ('what's
> your birthday?', for example), and isn't doing some non-obvious input
> validation on it (namely, checking that the input string isn't too
> long), you can crash the backend. Gavin says executing arbitrary code
> using the hole would be extremely difficult, but it's at least
> conceivable.

Right, but you have to get a connection to the backend in order to crash
it ... no?

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> On 24 Aug 2002, Neil Conway wrote:
> > If the application is accepting datetime input from the user ('what's
> > your birthday?', for example), and isn't doing some non-obvious input
> > validation on it (namely, checking that the input string isn't too
> > long), you can crash the backend. Gavin says executing arbitrary code
> > using the hole would be extremely difficult, but it's at least
> > conceivable.
>
> Right, but you have to get a connection to the backend in order to crash
> it ... no?

You need to be using an application accepts datetime input from the
user, and at some point inserts it into the database. For example, if
you wrote a webapp that accepted datetime input of some kind (to use
my previous example, the user's birthday), any user of the webapp
could enter bogus data that would crash the backend.

In this case, the user does not make a connection to the backend (the
web app does), and does not have the ability to execute arbitrary SQL
(i.e. it's not a "shared" or "open" system) -- but a security problem
still exists.

This is in contrast to the other security holes (repeat(), lpad(),
rpad(), SET TIME ZONE, and TZ env var), in which the probability of
someone without SQL access being able to exercise the bug is
negligible.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

"Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> Right, but you have to get a connection to the backend in order to crash
> it ... no?

The point was that it might be possible to exploit this with only
indirect access to the database, such as entering "date" information
into a webform that would hand off the value to the database with
little or no checking. Most of the risks we've been discussing require
the ability to issue chosen SQL commands, but this one only requires
the ability to determine a data value that's used in a SQL command.
Big difference.

regards, tom lane

The issue is data-provoked crashes vs. query-invoked crashes. Marc's
point, and I think it was clear enough, is that you can't just poke at
the TCP port and hope to do anything bad, which was the thrust of the
argument, I think.

---------------------------------------------------------------------------

Neil Conway wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > On 24 Aug 2002, Neil Conway wrote:
> > > If the application is accepting datetime input from the user ('what's
> > > your birthday?', for example), and isn't doing some non-obvious input
> > > validation on it (namely, checking that the input string isn't too
> > > long), you can crash the backend. Gavin says executing arbitrary code
> > > using the hole would be extremely difficult, but it's at least
> > > conceivable.
> >
> > Right, but you have to get a connection to the backend in order to crash
> > it ... no?
>
> You need to be using an application accepts datetime input from the
> user, and at some point inserts it into the database. For example, if
> you wrote a webapp that accepted datetime input of some kind (to use
> my previous example, the user's birthday), any user of the webapp
> could enter bogus data that would crash the backend.
>
> In this case, the user does not make a connection to the backend (the
> web app does), and does not have the ability to execute arbitrary SQL
> (i.e. it's not a "shared" or "open" system) -- but a security problem
> still exists.
>
> This is in contrast to the other security holes (repeat(), lpad(),
> rpad(), SET TIME ZONE, and TZ env var), in which the probability of
> someone without SQL access being able to exercise the bug is
> negligible.
>
> Cheers,
>
> Neil
>
>
> --
> Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Saturday 24 August 2002 12:37 am, Tom Lane wrote:
> "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> > Right, but you have to get a connection to the backend in order to crash
> > it ... no?

> The point was that it might be possible to exploit this with only
> indirect access to the database, such as entering "date" information

And this is the reason I was in favor of 7.2.2.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> point, and I think it was clear enough, is that you can't just poke at
> the TCP port and hope to do anything bad, which was the thrust of the
> argument, I think.

The point I objected to is the suggestion that only those running
"shared" or "open" systems are vulnerable to the security
problem. That is simply incorrect.

Cheers,

Neil

--
Neil Conway <neilc(at)samurai(dot)com> || PGP Key ID: DB3C29FC

Neil Conway wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> > point, and I think it was clear enough, is that you can't just poke at
> > the TCP port and hope to do anything bad, which was the thrust of the
> > argument, I think.
>
> The point I objected to is the suggestion that only those running
> "shared" or "open" systems are vulnerable to the security
> problem. That is simply incorrect.

Yes, I remember now. It is a bad data vunerability vs. a bad query
vulnerability.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sat, 24 Aug 2002, Marc G. Fournier wrote:

> On 24 Aug 2002, Neil Conway wrote:
>
> > "Marc G. Fournier" <scrappy(at)hub(dot)org> writes:
> >
> > > On 23 Aug 2002, Neil Conway wrote:
> > > > The datetime overrun does not require the ability to connect to
> > > > the database.
> > >
> > > Ack ... obviously I missed something, but, if you can't get a
> > > connection to the database, how exactly is this one triggered? :(
> >
> > If the application is accepting datetime input from the user ('what's
> > your birthday?', for example), and isn't doing some non-obvious input
> > validation on it (namely, checking that the input string isn't too
> > long), you can crash the backend. Gavin says executing arbitrary code
> > using the hole would be extremely difficult, but it's at least
> > conceivable.
>
> Right, but you have to get a connection to the backend in order to crash
> it ... no?

And what are the odds your application is going to bomb due to a buffer
overflow before it even gets to the database. I can see maybe with php,
but a web form should always be length limited.

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev(at)michvhf(dot)com http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
http://www.camping-usa.com http://www.cloudninegifts.com
http://www.meanstreamradio.com http://www.unknown-artists.com
==========================================================================

On Saturday 24 August 2002 10:51 am, Vince Vielhaber wrote:
> And what are the odds your application is going to bomb due to a buffer
> overflow before it even gets to the database. I can see maybe with php,
> but a web form should always be length limited.

IIRC, web forms are limited to 32k in an input field of any kind. TEXTAREA
is, I believe, the limit.

There are other limits -- but a web browser may not be the source of the POST
formdata.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

On Sat, 24 Aug 2002, Bruce Momjian wrote:

>
> The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> point, and I think it was clear enough, is that you can't just poke at
> the TCP port and hope to do anything bad, which was the thrust of the
> argument, I think.

Correct

On Sat, 24 Aug 2002, Bruce Momjian wrote:

>
> The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> point, and I think it was clear enough, is that you can't just poke at
> the TCP port and hope to do anything bad, which was the thrust of the
> argument, I think.

Bruce,

I am convinced that someone with enough time on their hands and some code
pointed to by Florian Weimer could exploit the datetime overrun issue by
crafting a datetime string in such a way as to overrun the buffer and
smash the stack.

In applications which pass date/time data directly to the database without
any validation (is this datetime string greater than 52 bytes? does it
look like a date/time string?) then a malicious user without direct
database access could crash the database by taking advantage of the short
comings in Postgres and the application.

As such, I would recommend all people who offer direct access to the
database and/or have applications which user date/time data
types/functionality to upgrade to 7.2.2.

Gavin

OK, I understand your point. What do we need to do now that the
announcement has already been made?

---------------------------------------------------------------------------

Gavin Sherry wrote:
> On Sat, 24 Aug 2002, Bruce Momjian wrote:
>
> >
> > The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> > point, and I think it was clear enough, is that you can't just poke at
> > the TCP port and hope to do anything bad, which was the thrust of the
> > argument, I think.
>
> Bruce,
>
> I am convinced that someone with enough time on their hands and some code
> pointed to by Florian Weimer could exploit the datetime overrun issue by
> crafting a datetime string in such a way as to overrun the buffer and
> smash the stack.
>
> In applications which pass date/time data directly to the database without
> any validation (is this datetime string greater than 52 bytes? does it
> look like a date/time string?) then a malicious user without direct
> database access could crash the database by taking advantage of the short
> comings in Postgres and the application.
>
> As such, I would recommend all people who offer direct access to the
> database and/or have applications which user date/time data
> types/functionality to upgrade to 7.2.2.
>
> Gavin
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

On Sun, 25 Aug 2002, Bruce Momjian wrote:

>
> OK, I understand your point. What do we need to do now that the
> announcement has already been made?

I'm still slightly confused here ... from what Neil/Gavin have stated so
far, all it sounds like is that if I pass a wrong date/time string, it
will crash the backend ... or is this what I'm missing?

>
> ---------------------------------------------------------------------------
>
> Gavin Sherry wrote:
> > On Sat, 24 Aug 2002, Bruce Momjian wrote:
> >
> > >
> > > The issue is data-provoked crashes vs. query-invoked crashes. Marc's
> > > point, and I think it was clear enough, is that you can't just poke at
> > > the TCP port and hope to do anything bad, which was the thrust of the
> > > argument, I think.
> >
> > Bruce,
> >
> > I am convinced that someone with enough time on their hands and some code
> > pointed to by Florian Weimer could exploit the datetime overrun issue by
> > crafting a datetime string in such a way as to overrun the buffer and
> > smash the stack.
> >
> > In applications which pass date/time data directly to the database without
> > any validation (is this datetime string greater than 52 bytes? does it
> > look like a date/time string?) then a malicious user without direct
> > database access could crash the database by taking advantage of the short
> > comings in Postgres and the application.
> >
> > As such, I would recommend all people who offer direct access to the
> > database and/or have applications which user date/time data
> > types/functionality to upgrade to 7.2.2.
> >
> > Gavin
> >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 5: Have you checked our extensive FAQ?
> >
> > http://www.postgresql.org/users-lounge/docs/faq.html
> >
>
> --
> Bruce Momjian | http://candle.pha.pa.us
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> + If your life is a hard drive, | 13 Roberts Road
> + Christ can be your backup. | Newtown Square, Pennsylvania 19073
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

*sigh* Someone's marked postgres 7.2.1 as forbidden in FreeBSD ports:

FORBIDDEN= "buffer overruns acknowledged by authors--see
<URL:http://www3.us.postgresql.org/news.html>"

Somewhat of an overreaction...I'm hassling the maintainer at the moment...

Chris

> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Marc G. Fournier
> Sent: Monday, 26 August 2002 10:17 AM
> To: Bruce Momjian
> Cc: Gavin Sherry; Neil Conway; PostgreSQL Hackers
> Subject: Re: [HACKERS] [GENERAL] PostgreSQL 7.2.2: Security Release
>
>
> On Sun, 25 Aug 2002, Bruce Momjian wrote:
>
> >
> > OK, I understand your point. What do we need to do now that the
> > announcement has already been made?
>
> I'm still slightly confused here ... from what Neil/Gavin have stated so
> far, all it sounds like is that if I pass a wrong date/time string, it
> will crash the backend ... or is this what I'm missing?
>
>
> >
> >
> ------------------------------------------------------------------
> ---------
> >
> > Gavin Sherry wrote:
> > > On Sat, 24 Aug 2002, Bruce Momjian wrote:
> > >
> > > >
> > > > The issue is data-provoked crashes vs. query-invoked
> crashes. Marc's
> > > > point, and I think it was clear enough, is that you can't
> just poke at
> > > > the TCP port and hope to do anything bad, which was the
> thrust of the
> > > > argument, I think.
> > >
> > > Bruce,
> > >
> > > I am convinced that someone with enough time on their hands
> and some code
> > > pointed to by Florian Weimer could exploit the datetime
> overrun issue by
> > > crafting a datetime string in such a way as to overrun the buffer and
> > > smash the stack.
> > >
> > > In applications which pass date/time data directly to the
> database without
> > > any validation (is this datetime string greater than 52 bytes? does it
> > > look like a date/time string?) then a malicious user without direct
> > > database access could crash the database by taking advantage
> of the short
> > > comings in Postgres and the application.
> > >
> > > As such, I would recommend all people who offer direct access to the
> > > database and/or have applications which user date/time data
> > > types/functionality to upgrade to 7.2.2.
> > >
> > > Gavin
> > >
> > >
> > >
> > > ---------------------------(end of
> broadcast)---------------------------
> > > TIP 5: Have you checked our extensive FAQ?
> > >
> > > http://www.postgresql.org/users-lounge/docs/faq.html
> > >
> >
> > --
> > Bruce Momjian | http://candle.pha.pa.us
> > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > + If your life is a hard drive, | 13 Roberts Road
> > + Christ can be your backup. | Newtown Square,
> Pennsylvania 19073
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 2: you can get off all lists at once with the unregister command
> > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> >
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

On Mon, 26 Aug 2002, Christopher Kings-Lynne wrote:

> *sigh* Someone's marked postgres 7.2.1 as forbidden in FreeBSD ports:
>
> FORBIDDEN= "buffer overruns acknowledged by authors--see
> <URL:http://www3.us.postgresql.org/news.html>"
>
> Somewhat of an overreaction...I'm hassling the maintainer at the moment...

already fixed ...

> > -----Original Message-----
> > From: pgsql-hackers-owner(at)postgresql(dot)org
> > [mailto:pgsql-hackers-owner(at)postgresql(dot)org]On Behalf Of Marc G. Fournier
> > Sent: Monday, 26 August 2002 10:17 AM
> > To: Bruce Momjian
> > Cc: Gavin Sherry; Neil Conway; PostgreSQL Hackers
> > Subject: Re: [HACKERS] [GENERAL] PostgreSQL 7.2.2: Security Release
> >
> >
> > On Sun, 25 Aug 2002, Bruce Momjian wrote:
> >
> > >
> > > OK, I understand your point. What do we need to do now that the
> > > announcement has already been made?
> >
> > I'm still slightly confused here ... from what Neil/Gavin have stated so
> > far, all it sounds like is that if I pass a wrong date/time string, it
> > will crash the backend ... or is this what I'm missing?
> >
> >
> > >
> > >
> > ------------------------------------------------------------------
> > ---------
> > >
> > > Gavin Sherry wrote:
> > > > On Sat, 24 Aug 2002, Bruce Momjian wrote:
> > > >
> > > > >
> > > > > The issue is data-provoked crashes vs. query-invoked
> > crashes. Marc's
> > > > > point, and I think it was clear enough, is that you can't
> > just poke at
> > > > > the TCP port and hope to do anything bad, which was the
> > thrust of the
> > > > > argument, I think.
> > > >
> > > > Bruce,
> > > >
> > > > I am convinced that someone with enough time on their hands
> > and some code
> > > > pointed to by Florian Weimer could exploit the datetime
> > overrun issue by
> > > > crafting a datetime string in such a way as to overrun the buffer and
> > > > smash the stack.
> > > >
> > > > In applications which pass date/time data directly to the
> > database without
> > > > any validation (is this datetime string greater than 52 bytes? does it
> > > > look like a date/time string?) then a malicious user without direct
> > > > database access could crash the database by taking advantage
> > of the short
> > > > comings in Postgres and the application.
> > > >
> > > > As such, I would recommend all people who offer direct access to the
> > > > database and/or have applications which user date/time data
> > > > types/functionality to upgrade to 7.2.2.
> > > >
> > > > Gavin
> > > >
> > > >
> > > >
> > > > ---------------------------(end of
> > broadcast)---------------------------
> > > > TIP 5: Have you checked our extensive FAQ?
> > > >
> > > > http://www.postgresql.org/users-lounge/docs/faq.html
> > > >
> > >
> > > --
> > > Bruce Momjian | http://candle.pha.pa.us
> > > pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
> > > + If your life is a hard drive, | 13 Roberts Road
> > > + Christ can be your backup. | Newtown Square,
> > Pennsylvania 19073
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 2: you can get off all lists at once with the unregister command
> > > (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
> > >
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> >
>
>

In article <20020824000845(dot)Q1769-100000(at)mail1(dot)hub(dot)org>,
scrappy(at)hub(dot)org ("Marc G. Fournier") wrote:

> Due to recent security vulnerabilities reported on BugTraq, concerning
> several buffer overruns found in PostgreSQL, the PostgreSQL Global
> Development Team today released v7.2.2 of PostgreSQL that fixes these
> vulnerabilities.

might i recommend posting this to announce, as well? i never saw it show
up there, and i certainly know some people who only read the announce
list.

if it was there, then the subsidiary problem is that announce is not
working on the news server...

FYI.

-tfo