[EMAIL PROTECTED] writes:
if you are going to be passing any user input to the database, you
must/should validate in some manner before blindly passing it to the db.
The db can and should guarantee data integrity, but the database cannot
read your mind when it comes to how you structure
[EMAIL PROTECTED] (Florian Weimer) wrote
[EMAIL PROTECTED] writes:
if you are going to be passing any user input to the database, you
must/should validate in some manner before blindly passing it to the db.
The db can and should guarantee data integrity, but the database cannot
read
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad way.
Why rewrite this kind of stuff when the
[EMAIL PROTECTED] (Curt Sampson) wrote in
On Mon, 19 Aug 2002 [EMAIL PROTECTED] wrote:
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash.
It will fail because you're doing this a very, very, very bad
with Perl and *using placeholders and bind values*, the application
developer has not to worry about this. So, usually I don't check the
values in my applications (e.g. if only values between 1 and 5 are
allowed and under normal circumstances only these are possible), it's the
task of
Zeugswetter Andreas SB SD [EMAIL PROTECTED] writes:
Yes, but what is currently missing is a protocol to the backend
where a statement is prepared with placeholders and then executed
(multiple times) with given values. Then there is no doubt what is a
value, and what a part of the SQL.
This
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
then crashing the backend is going to be the least of your worries.
with Perl and *using placeholders and bind values*, the
Hi Florian,
You guys *definitely* write scarey code.
:-(
Regards and best wishes,
Justin Clift
Florian Weimer wrote:
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
Justin Clift [EMAIL PROTECTED] writes:
You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
That's scary. You don't trust your database that it processes a
simple text
On Mon, 2002-08-19 at 13:14, Florian Weimer wrote:
Justin Clift [EMAIL PROTECTED] writes:
You guys *definitely* write scarey code.
Yes, indeed. My code has a lot of unnecessary and error-prone input
validation checks because I don't trust the PostgreSQL parser.
Bah.. Check the datatype
Florian Weimer [EMAIL PROTECTED] writes:
That's the idea. It's the job of the database to guarantee data
integrety.
Obviously, the PostgreSQL developers disagree.
Look: it's an acknowledged bug and it's fixed in current sources.
The disagreement is over whether this single bug is sufficient
Tom Lane [EMAIL PROTECTED] writes:
Saying or implying that the developers don't care about data integrity
does not enhance your credibility.
Sorry, my fault. Indeed, I didn't check carefully whether the people
who go a bit too far in downplaying the problem at hand are in fact
PostgreSQL
[EMAIL PROTECTED] (Florian Weimer) wrote
Alvar Freude [EMAIL PROTECTED] writes:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in
input then crashing the backend is going to be the least of your
worries.
with Perl and
Hi,
-- [EMAIL PROTECTED] wrote:
What about checking the input for backslash, quote,
and double quote (\')? If you are not taking care of those in input
then crashing the backend is going to be the least of your worries.
with Perl and *using placeholders and bind values*, the
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
Tom Lane [EMAIL PROTECTED] writes:
Justin Clift [EMAIL PROTECTED] 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
Mike Mascari [EMAIL PROTECTED] 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,
Well, if it's a buffer overrun, there is certainly potential for risks
well beyond that of simply crashing the be. It's certainly possible
that a simple bug in one cgi script or web site could allow someone to
execute code on the database host because of this bug. Assuming they
are running the
Greg Copeland [EMAIL PROTECTED] writes:
Well, if it's a buffer overrun, there is certainly potential for risks
well beyond that of simply crashing the be.
It's a buffer overrun, but the data has to pass through the date/time
parser in the backend, so it's not entirely obvious how you can
Gavin Sherry [EMAIL PROTECTED] writes:
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.
Anyone who is using that regular expression in an attempt to validate a
user supplied date is
On Mon, 12 Aug 2002, Florian Weimer wrote:
Gavin Sherry [EMAIL PROTECTED] writes:
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.
Anyone who is using that regular expression in
-Original Message-
From: Gavin Sherry [mailto:[EMAIL PROTECTED]]
Sent: 12 August 2002 15:15
To: Florian Weimer
Cc: [EMAIL PROTECTED]
Subject: Re: [HACKERS] [SECURITY] DoS attack on backend
possible (was: Re:
On Mon, 12 Aug 2002, Florian Weimer wrote:
Gavin Sherry
Gavin Sherry wrote:
As to your other point -- that this bug in the data/time code actually
*reflects* the quality and reliability of the database itself -- you've
really gone too far. The best software has bugs.
For example, in the current version of Oracle 9i, if a client (say
SQL*Plus) is
[EMAIL PROTECTED] (Florian Weimer) wrote in
[EMAIL PROTECTED]:">news:[EMAIL PROTECTED]:
Gavin Sherry [EMAIL PROTECTED] writes:
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.
Justin Clift [EMAIL PROTECTED] 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
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
Justin Clift [EMAIL PROTECTED] 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
Justin Clift [EMAIL PROTECTED] 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
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
Justin Clift [EMAIL PROTECTED] 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
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
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
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.
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.
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
35 matches
Mail list logo
