Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 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 the database (check constraint). Ciao Alvar -- ** ODEM ist für den poldi Award nominiert! http://www.poldiaward.de/ ** http://www.poldiaward.de/index.php?display=detailcat=audiitem=24 ** http://odem.org/ ** Mehr Projekte: http://alvar.a-blast.org/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 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[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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, ... ; But this requires to be able to send arbitrary SQL commands; just feeding a specially crafted date string usually does not. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 be as postgres or some other seemingly harmless user, it's still possible that complete destruction of any and all databases which are hosted and accessible by this user can be utterly destroyed or miscellaneously corrupted. Buffer over runs should be treated with the up most urgency and respect. IMO, any known buffer overrun is worthy of an emergency fix and corresponding advisory. Greg Copeland On Sun, 2002-08-11 at 12:09, Tom Lane wrote: 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 would *not* cause the problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 exploit this to run arbitrary code. -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 already in trouble. I don't understand why extremely strict syntax checks are necessary. The database has to parse it again anyway, and if you can't rely on the database to get this simple parsing right, will it store your data? Such a reasoning doesn't seem to be too far-fetched to me I would probably impose a length limit in the frontend that uses the database, but the PostgreSQL documentation does not state that this is a requirement (because the parsers in the backend are so fragile). -- Florian Weimer[EMAIL PROTECTED] University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 an attempt to validate a user supplied date is already in trouble. I don't understand why extremely strict syntax checks are necessary. The database has to parse it again anyway, and if you can't rely on the database to get this simple parsing right, will it store your data? Such a reasoning doesn't seem to be too far-fetched to me Why attempt to validate the user data at all if you're going to do a bad job of it? Moreover, 'rely on the database to get this ... right': what kind of security principle is that? For someone interested in security, you've just broken the most important principle. 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. The reason that no one is jumping up and down making releases and giving you a medal is that (1) it is still questionable as to whether or not this bug exists in 7.2.1 (2) it does not appear to be exploitable (3) it could only be used to cause a denial of service by an authorised user (4) it is common practise for database application developers to validate user input and if they don't they have bigger problems than a potential DoS on their hands. Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
-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 [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 already in trouble. I don't understand why extremely strict syntax checks are necessary. The database has to parse it again anyway, and if you can't rely on the database to get this simple parsing right, will it store your data? Such a reasoning doesn't seem to be too far-fetched to me Why attempt to validate the user data at all if you're going to do a bad job of it? Moreover, 'rely on the database to get this ... right': what kind of security principle is that? For someone interested in security, you've just broken the most important principle. If I write code in a Microsoft product such as VB it will happily accept timestamps such as '2001-12-23 22.15.01' which is a perfectly valid date in some parts of the world. PostgreSQL will barf on the .'s - is it expected then that I write my own validation/parsing code to replace Microsoft's in this and every other area that may need checking just because PostgreSQL doesn't understand a particular format? I would rather let PostgreSQL alone know about it's oddities and just throw me an error I can deal with in such cases. Regards, Dave. PS (Gavin). Thanks for the CREATE OR REPLACE's you recently submitted! ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 running on a linux box and talking to Oracle running on a Solaris box, executes the following: create table foo(i integer primary key, bar blob); ... then later does ... update foo set bar=empty_blob() where i = some key value The Oracle server on Solaris crashes. *the whole thing* BANG! Shot-to-the-head-dead. Not the user's client - the server. This means that any user with the right to update a single table with a blob can crash Oracle at will. What does this say about Oracle's overall reliability? As Gavin says all software has bugs. Most of PG's bugs are far less spectacular than the Oracle bug I mention here. Overall I rate PG and Oracle as being about equivalent in terms of bugs. -- Don Baccus Portland, OR http://donb.photo.net, http://birdnotes.net, http://openacs.org ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
[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. Anyone who is using that regular expression in an attempt to validate a user supplied date is already in trouble. I don't understand why extremely strict syntax checks are necessary. The database has to parse it again anyway, and if you can't rely on the database to get this simple parsing right, will it store your data? Such a reasoning doesn't seem to be too far-fetched to me I believe this is often referred to as the layered onion approach of security, besides that what constitutes extremely strict syntax checking is somewhat subjective. 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. I think there needs to be some level of checking before the input is blindly passed to the backend for parsing. Typically the input for an individual field wouldnt be more than ~255 characters, unless you are dealing with TEXT or lo's. I dont consider adding a length check to the usual \' check to be extreme... but perhaps just as necssary? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 triggered by mere data, an attacker does not have to be able to send specific SQL statements to the server. -- Florian Weimer[EMAIL PROTECTED] 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
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [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 triggered by mere data, an attacker does not have to be able to send specific SQL statements to the server. -- Florian Weimer[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 would *not* cause the problem. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 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[EMAIL PROTECTED] 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
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [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 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[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [EMAIL PROTECTED])
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [SECURITY] DoS attack on backend possible (was: Re:
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 [EMAIL PROTECTED] writes: Neil Conway [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
