Thread: Re: [GENERAL] PostgreSQL 7.2.2: Security Release

Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Neil Conway
Date:
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



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Marc G. Fournier"
Date:
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? :(




Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Neil Conway
Date:
"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



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Marc G. Fournier"
Date:
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?




Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Neil Conway
Date:
"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



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Tom Lane
Date:
"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


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Lamar Owen
Date:
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


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Neil Conway
Date:
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



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Bruce Momjian
Date:
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,
Pennsylvania19073
 


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Vince Vielhaber
Date:
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
atPop4 Networking     http://www.camping-usa.com      http://www.cloudninegifts.com  http://www.meanstreamradio.com
 http://www.unknown-artists.com
 
==========================================================================





Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Lamar Owen
Date:
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


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Marc G. Fournier"
Date:
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




Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Gavin Sherry
Date:
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




Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
Bruce Momjian
Date:
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@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
 


Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Marc G. Fournier"
Date:
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@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)
>



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Christopher Kings-Lynne"
Date:
*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@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 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@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
>



Re: [GENERAL] PostgreSQL 7.2.2: Security Release

From
"Marc G. Fournier"
Date:
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@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 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@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
> >
>
>