pgsql-server/src include/utils/timestamp.h bac ...

thomas@postgresql.org (Thomas Lockhart) writes:

Log message:
Add guard code to protect from buffer overruns on long date/time input
strings. Should go back in and look at doing this a bit more elegantly
and (hopefully) cheaper. Probably not too bad anyway, but it seems a
shame to scan the strings twice: once for length for this buffer overrun
protection, and once to parse the line.

Are these changes available for 7.2, too? There is at least a DoS
potential lurking here. :-(

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> writes:

thomas@postgresql.org (Thomas Lockhart) writes:

Log message:
Add guard code to protect from buffer overruns on long date/time input
strings. Should go back in and look at doing this a bit more elegantly
and (hopefully) cheaper. Probably not too bad anyway, but it seems a
shame to scan the strings twice: once for length for this buffer overrun
protection, and once to parse the line.

Are these changes available for 7.2, too? There is at least a DoS
potential lurking here. :-(

Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code Thomas wrote earlier in the 7.3
development cycle -- i.e. there's no bug present in 7.2, or earlier CVS
code when compiled without --enable-integer-datetimes.

Cheers,

Neil

--
Neil Conway <neilconway@rogers.com>
PGP Key ID: DB3C29FC

...

Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code Thomas wrote earlier in the 7.3
development cycle -- i.e. there's no bug present in 7.2, or earlier CVS
code when compiled without --enable-integer-datetimes.

Actually, it is probably an issue for the earlier stuff too, but the
integer value reading seems to have different sensitivities to really
long strings which is the symptom that was noticed just recently.

The same technique for guarding would work fine for 7.2 also.

- Thomas

Neil Conway <nconway@klamath.dyndns.org> writes:

Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code

No, it's possible to crash the backend in 7.2, too.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> writes:

Neil Conway <nconway@klamath.dyndns.org> writes:

Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code

No, it's possible to crash the backend in 7.2, too.

And 7.2.1, of course.

Let me ask again: Do you plan to address this in an update for 7.2.1?

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Hi Florian,

Is it possible to crash a 7.2.1 backend without having an entry in the
pg_hba.conf file?

i.e. Is every PostgreSQL 7.2.1 installation around vulnerable to a
remote DoS (or worse) from any user anywhere, at this moment in time?

Regards and best wishes,

Justin Clift

Florian Weimer wrote:

Florian Weimer <Weimer@CERT.Uni-Stuttgart.DE> writes:

Neil Conway <nconway@klamath.dyndns.org> writes:

Thomas can correct me if I'm mistaken, but I believe these changes apply
to the new integer datetime code

No, it's possible to crash the backend in 7.2, too.

And 7.2.1, of course.

Let me ask again: Do you plan to address this in an update for 7.2.1?

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift <justin@postgresql.org> writes:

Is it possible to crash a 7.2.1 backend without having an entry in the
pg_hba.conf file?

No, but think of web applications and things like that. The web
frontend might pass in a date string which crashes the server backend.
Since the crash can be triggered by mere data, an attacker does not
have to be able to send specific SQL statements to the server.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Hi Florian,

Am I understanding this right:

- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?
So, a web application layer can request a date from a user, do standard
integrity checks (like looking for weird characters and formatting
hacks) on the date given, then use the date as part of a SQL query, and
PostgreSQL will die?

?

Regards and best wishes,

Justin Clift

Florian Weimer wrote:

Justin Clift <justin@postgresql.org> writes:

Is it possible to crash a 7.2.1 backend without having an entry in the
pg_hba.conf file?

No, but think of web applications and things like that. The web
frontend might pass in a date string which crashes the server backend.
Since the crash can be triggered by mere data, an attacker does not
have to be able to send specific SQL statements to the server.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift <justin@postgresql.org> writes:

Am I understanding this right:
- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?

AFAIK it's a buffer overrun issue, so anything that looks like a
reasonable date would *not* cause the problem.

regards, tom lane

Justin Clift <justin@postgresql.org> writes:

- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?
So, a web application layer can request a date from a user, do standard
integrity checks (like looking for weird characters and formatting
hacks) on the date given, then use the date as part of a SQL query, and
PostgreSQL will die?

It depends on the checking. If you just check that the date consists
of digits (and a few additional characters), it's possible to crash
the server.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Hi Florian,

Very hard call.

If this was even a "fringe case" whereby even only a few places that are
doing "the right thing" would be compromisable, then we should probably
go for a 7.2.2. Even if it's only 7.2.1 with this one bug fix.

However, it sounds like this bug is really only going to affect those
places which aren't correctly implementing *proper*, *decent* input
validation, and are then passing this not-properly-checked value
straight into a SQL string for execution by the server.

Doing that (not input checking properly) is a brain damaged concept all
by itself. :(

Is this scenario of not properly checking the input the only way
PostgreSQL could be crashed by this bug In Real Life?

Having said this, is this what 7.2.2 here would require doing:

- Create an archive of 7.2.1+bugfix, and call it 7.2.2, gzip, md5, etc,
as appropriate, put on site
- Update CVS appropriately
- Create a new press release for 7.2.2, spread that appropriately too
- Add an entry to the main website

I reckon the only reason for making a 7.2.2 for this would be to help
ensure newbie (or very tired) coders don't get their servers taken out
by clueful malicious types.

Regards and best wishes,

Justin Clift

Florian Weimer wrote:

Justin Clift <justin@postgresql.org> writes:

- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?
So, a web application layer can request a date from a user, do standard
integrity checks (like looking for weird characters and formatting
hacks) on the date given, then use the date as part of a SQL query, and
PostgreSQL will die?

It depends on the checking. If you just check that the date consists
of digits (and a few additional characters), it's possible to crash
the server.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Justin Clift <justin@postgresql.org> writes:

Am I understanding this right:
- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?

AFAIK it's a buffer overrun issue, so anything that looks like a
reasonable date would *not* cause the problem.

Still, I believe this should require a 7.2.2 release. Imagine a university
database server for a course for example - the students would just crash it
all the time.

Chris

Hi Chris,

Christopher Kings-Lynne wrote:

<snip>

Still, I believe this should require a 7.2.2 release. Imagine a university
database server for a course for example - the students would just crash it
all the time.

Hey yep, good point.

Is this the only way that we know of non postgresql-superusers to be
able to take out the server other than by extremely non-optimal,
resource wasting queries?

If we release a 7.2.2 because of this, can we be pretty sure we have a
"no known vulnerabilities" release, or are there other small holes which
should be fixed too?

:-)

Regards and best wishes,

Justin Clift

Chris

--
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi

Hey yep, good point.

Is this the only way that we know of non postgresql-superusers to be
able to take out the server other than by extremely non-optimal,
resource wasting queries?

If we release a 7.2.2 because of this, can we be pretty sure we have a
"no known vulnerabilities" release, or are there other small holes which
should be fixed too?

What about that "select cash_out(2) crashes because of opaque" entry in the
TODO? That really needs to be fixed.

I was talking to a CS lecturer about switching to postgres from oracle when
7.3 comes out and all he said was "how easily is it hacked?". He says their
systems are the most constantly bombarded in universities. What could I
say? That any unprivileged user can just go 'select cash_out(2)' to DOS the
backend?

Chris

On Mon, 12 Aug 2002, Justin Clift wrote:

Hi Chris,

Christopher Kings-Lynne wrote:

<snip>

Still, I believe this should require a 7.2.2 release. Imagine a university
database server for a course for example - the students would just crash it
all the time.

Hey yep, good point.

Is this the only way that we know of non postgresql-superusers to be
able to take out the server other than by extremely non-optimal,
resource wasting queries?

Check the TODO:

You are now connected as new user s.
template1=> select cash_out(2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q
[swm@laptop a]$ bin/psql template1
psql: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.3987"?
[swm@laptop a]$

---

Gavin

Yea, I added that TODO entry, and I am embarrased that a single cash_out
call could crash the backend. I thought about not making this public
knowledge, but making it public hasn't marshalled any forces to fix it
so maybe I was wrong to put it on TODO.

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

Gavin Sherry wrote:

On Mon, 12 Aug 2002, Justin Clift wrote:

Hi Chris,

Christopher Kings-Lynne wrote:

<snip>

Still, I believe this should require a 7.2.2 release. Imagine a university
database server for a course for example - the students would just crash it
all the time.

Hey yep, good point.

Is this the only way that we know of non postgresql-superusers to be
able to take out the server other than by extremely non-optimal,
resource wasting queries?

Check the TODO:

You are now connected as new user s.
template1=> select cash_out(2);
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
!> \q
[swm@laptop a]$ bin/psql template1
psql: could not connect to server: Connection refused
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.3987"?
[swm@laptop a]$

---

Gavin

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

-- 
  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

Christopher Kings-Lynne wrote:

Hey yep, good point.

Is this the only way that we know of non postgresql-superusers to be
able to take out the server other than by extremely non-optimal,
resource wasting queries?

If we release a 7.2.2 because of this, can we be pretty sure we have a
"no known vulnerabilities" release, or are there other small holes which
should be fixed too?

What about that "select cash_out(2) crashes because of opaque" entry in the
TODO? That really needs to be fixed.

I was talking to a CS lecturer about switching to postgres from oracle when
7.3 comes out and all he said was "how easily is it hacked?". He says their
systems are the most constantly bombarded in universities. What could I
say? That any unprivileged user can just go 'select cash_out(2)' to DOS the
backend?

If he's using Oracle already, he ought to check out:

http://www.cert.org/advisories/CA-2002-08.html

I'd still think it would be a good policy to make a security release.
However, without user resource limits in PostgreSQL, anyone can make a
machine useless with a query like:

SELECT *
FROM pg_class a, pg_class b, pg_class c, pg_class d, pg_class e, ... ;

Mike Mascari
mascarm@mascari.com

Tom Lane <tgl@sss.pgh.pa.us> writes:

Justin Clift <justin@postgresql.org> writes:

Am I understanding this right:
- A PostgreSQL 7.2.1 server can be crashed if it gets passed certain
date values which would be accepted by standard "front end" parsing?

AFAIK it's a buffer overrun issue, so anything that looks like a
reasonable date would *not* cause the problem.

Yes, but if you just check that the date given by the user matches the
regular expression "[0-9]+-[0-9]+-[0-9]+", it's still possible to
crash the backend.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Mike Mascari <mascarm@mascari.com> writes:

I'd still think it would be a good policy to make a security release.
However, without user resource limits in PostgreSQL, anyone can make a
machine useless with a query like:

SELECT *
FROM pg_class a, pg_class b, pg_class c, pg_class d, pg_class e, ... ;

But this requires to be able to send arbitrary SQL commands; just
feeding a specially crafted date string usually does not.

--
Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898