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@postgresql.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@candle.pha.pa.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@candle.pha.pa.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@samurai.com> || PGP Key ID: DB3C29FC
On 23 Aug 2002, Neil Conway wrote:
Bruce Momjian <pgman@candle.pha.pa.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@hub.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@samurai.com> || PGP Key ID: DB3C29FC
On 24 Aug 2002, Neil Conway wrote:
"Marc G. Fournier" <scrappy@hub.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@hub.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@samurai.com> || PGP Key ID: DB3C29FC
"Marc G. Fournier" <scrappy@hub.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@hub.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@samurai.com> || PGP Key ID: DB3C29FC
--
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, Pennsylvania 19073
On Saturday 24 August 2002 12:37 am, Tom Lane wrote:
"Marc G. Fournier" <scrappy@hub.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@candle.pha.pa.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@samurai.com> || PGP Key ID: DB3C29FC
Neil Conway wrote:
Bruce Momjian <pgman@candle.pha.pa.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@candle.pha.pa.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@hub.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@michvhf.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?
--
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, Pennsylvania 19073On 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?
Show quoted text
---------------------------------------------------------------------------
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?-- 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, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.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
Show quoted text
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.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 ReleaseOn 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 advantageof 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?
-- 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,Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.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 ...
Show quoted text
-----Original Message-----
From: pgsql-hackers-owner@postgresql.org
[mailto:pgsql-hackers-owner@postgresql.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 ReleaseOn 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 advantageof 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?
-- 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,Pennsylvania 19073
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
In article <20020824000845.Q1769-100000@mail1.hub.org>,
scrappy@hub.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