Обсуждение: Re: [GENERAL] PostgreSQL 7.2.2: Security Release
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
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,
Pennsylvania19073
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, Pennsylvania19073
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
==========================================================================
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@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
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) >
*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 >
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 > > > >