Re: [HACKERS] Proposed GUC Variable
[EMAIL PROTECTED] (Tom Lane) wrote Ross J. Reedstrom [EMAIL PROTECTED] writes: I agree that a 'trimmed' query is likely to be useless, but the idea of printing the query on ERROR is a big win for me: Certainly. I think though that an on-or-off GUC option is sufficient. We don't need a length, and we definitely don't need code to strip out whitespace as Bruce was suggesting ... Just out of curiosity... how much harder would it be to have the GUC variable represent the truncation length? so setting it to zero would be equivalent to turning the feature off... I personally would have no use for this feature, but I am just curious. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
[EMAIL PROTECTED] (Bruce Momjian) wrote Sir-* does have a point. A valid host in pg_hba.conf can cause DOS by just connecting over and over, but allocating almost all of the memory on the machine would affect other applications running on the machine, even non-networked applications, as well as PostgreSQL, while a connection DOS effects only PostgreSQL. oh woe is he the man who does not use rlimits, or perhaps, concurrency limits? it seems this is nothing new, all network available services are subject to dos or ddos attacks... and if you dont setup limits on your machine, then other things can be affected... inetd, bind, sendmail, finger, insert favorite network accessible program here, etc... I do agree that pgsql should not just arbitrarily allocate memory like this, as defensive programming, but I cannot agree that this is a bug or problem in pgsql per se. As a side note, if someone wanted to shift the discussion to allowing concurrency limits in pgsql, how would/could this fit into the context of another thread where it was discussed to be able to always allow certain users to login... ---(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
[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 your mind when it comes to how you structure your queries. [example of SQL injection attack deleted] This is not the problem at hand. SQL injection attacks can be avoided easily. Bugs in the conversion of strings to internal PostgreSQL objects are a different matter, though, and usually, devastating effects cannot be avoided by (reasonably complex) checks in the frontend. yeah i wasnt aware that adding a if(strlen($input) SOME_REASONABLE_MAX) was complex. the sql injection attack was just an(other) example of why you do not simply forward user input to the backend. all i was trying to point out is that most of these buffer overflows in the backend can be avoided just as easily as the sql injection attack. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [SECURITY] DoS attack on backend possible
[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 way.
Why rewrite this kind of stuff when the vendor has already made
correct code available?
PreparedStatement stmt = connection.prepareStatement(
INSERT INTO db (name) VALUES (?));
stmt.setString(user'name);
stmt.execute();
cjs
Curt:
I am not doing it this way, I am trying to point out that doing it without
doing something (whether it be using preparedstatement or WHATEVER), is,
as you say, very very very bad (I am agreeing with you). I am further
saying that whatever it is you do, you should also be doing some other
simple validation, like the length of the inputs, because most inputs wont
be over 255 chars before being prepared. This is just an example, but you
should do whatever validation would apply to you (and this is probably true
coding for any user input whether it involves a db or not). I am just
saying this is good practice in my opinion and had these people that
brought up the issue in the first place were doing it, then pgsql's
shortcomings would not have been as severe a problem. Things I am not
saying are: its ok for pgsql to have this DoS problem; its the frontends
responsibility to maintain data integrity not the backend.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] @(#) Mordred Labs advisory 0x0001: Buffer overflow in
[EMAIL PROTECTED] (Greg Copeland) wrote Time and time again I've read what basically amounts to, ...if someone can crash it it's because someone is stupid enough to allow someone to be able to do it in the first place... Maybe you're right. After all, if core developers continue to turn a blind eye to such issues, they are in fact, the facilitators of allowing people to do it to begin with.=20 That is, they are the ones that allowing people to do it in the first place. In short, every time I see that response, I immediately think, ...now that's the pot calling the kettle black. At some point in time, you have to stand and say, the buck stops here. I agree here, but at the same time you cannot put 100% of the responsibility on the developers. If you are the dba/sysadmin/whatever/etc then it is your responsibility. It is up to you to know about potential problems and have workarounds or whatever it is you need to do. I think that is one of the things that seperates a good admin from a not-so- good one. Afterall, when your boss calls you into his office monday morning and asks for a really good explanation for why the db was cracked, I dont think he is going to accept the excuse this guy, you dont know him but his name is tom lane.. well anyway, he didnt fix this bug i knew about so i didnt do nothing about it because i shouldnt have to because that would be like the pot calling the kettle black That being said, I do agree the developers should give things like this more priority. But, its open source... so you either live with it or write your own patch. ---(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
[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 *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).
That's the idea. It's the job of the database to guarantee data
integrety.
Obviously, the PostgreSQL developers disagree. If I've got to do all
checking in the application anyway, I can almost use MySQL
instead. ;-)
perhaps I did not express myself very well.
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 your queries.
$input = user'name;
INSERT INTO db (name) VALUES ('$input');
will fail because the ' in the input needs to be escaped with a
backslash. at some point this has to happen, because
INSERT INTO db (name) VALUES ('user'name');
is not a valid query.
The other thing is i think you are stretching the db integrity
checking argument a little too far. Its the db's responsibility to make
sure only valid data is stored, but its not the db's responsibility to
directly interact with your end users -- this is the job of your
application and interface. If you insert a new record and there is a
constraint violation, how is your application supposed to know what
illegal value(s) is/are causing it? How are you supposed to convey the
proper information to your user to get the input you are looking for?
Besides all that, and i dont mean to insult you, but your just plain
stupid if you blindly pass user inputted data to your db. For that
matter, your stupid if you blindly accept user input in any programming
without checking it at some level.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] (Tom Lane) wrote * If a connection request has a username with a trailing '@' (and no embedded '@'), then the '@' is stripped and connection proceeds. * Otherwise, '@dbname' is appended to the given username and connection proceeds. snip It might be worth recalling the reason that we are going through this pushup in the first place: Marc wants to be able to assign the same username to two different users who want to access two different databases. If he would be happy with the answer give them two different usernames, we'd not be having this discussion at all. Do you think he will be happy with the answer you can give them the same username as long as it ends in '@'? I think it's highly unlikely that he'll be satisfied with that --- he wants to *not* have constraints on the names he gives out for local users. What about usernames that have trailing or embedded @'s? I mean you are eseentially making the @ a magic character. I admit I havent looked at the source, but doesnt this method effectively put a constraint on the use of @? What if an isp, that could use this feature, already has usernames with @'s in them (say a customers email address, etc)? Will they need to assign all new usernames to make this thing function? What if you want to give one person (one username) access to 2 db's? Does that mean, under the current scheme, that the two accounts you create can have the same username but have different passwords? What if you want to erase the one account (do you have to remember to erase all n accounts you created with the same username, or all n except the ones that were never mean to be the same person but share the same username)? Normally a user has a unique name. Does anyone see a problem if/when the whole db access thing becomes part of the privileges system? If you implement the multiple users same username, then you'll have to reassign all but one of the users to new usernames. ---(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] Open 7.3 items
[EMAIL PROTECTED] (Bruce Momjian) wrote I know the trailing @ is ugly, but it prevents surpises when connecting to the database. if you would make the magic character a variable then perhaps you could prevent the ugly... if/when you turn off the feature, you could set the PGSQL_STUPID_MAGIC_CHARACTER to '', then you would be appending an empty string instead of a @, when you want to turn it back on, set the variable back to '@'... and if you change the character, well dont.. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] OOP real life example (was Re: Why is MySQL more
Summary: 1. The current implementation is broken. 2. We have no proper description of how a fixed implementation should work. 3. It's hard to fix the current implementation without such a description. 4. Thus, we are in other messages here trying to work out the model and come up with such a description. 5. The people working this out at the moment appear to be me, Greg Copeland and Hannu Krosing. cjs I've been following the thread on and off, but maybe we should come up with a list of specifically what is broken... I have used the oo feature in the past and the only thing I dont care for about it is the lack of documentation/examples/etc of how it really works and the fact that constraints/indicies/etc are not inherited by child tables. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open 7.3 items
OK, the vote is not shifting from '.' to ''. Is that how we want to go? I like the pg_user enhancement. Marc, comments? This was your baby. Would it be hard to setup an internal PG variable for the actual character to be used? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Open 7.3 items
[EMAIL PROTECTED] (Bruce Momjian) wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I don't know where else to go with the patch at this point. I think increasing the number of 'global' users is polluting the namespace too much, Why? If the installation needs N global users, then it needs N global users; who are you to make that value judgment for them? In practice I think an installation that's using this feature is going to have a pretty small number of global users, and so the issue of collisions with local usernames isn't really as big as it's been painted in this thread. We could ignore that issue (except for documenting it) and have a perfectly serviceable feature. The original idea was that Marc wanted people who could create their own users for their own databases. If we make the creation of global users too easy, all of a sudden people don't have control over their db usernames because they have to avoid all the global user names already defined. By adding multiple global users, it is diluting the usefulness of the feature. Maybe I am missing something here but shouldnt db access really be part of the privileges system? If all we are talking about is a quick hack until this can be implemented correctly, what is the concern with having so much functionality in the hack? Why does it matter what the actual usernames can or cant be? For example you could just make everyone with a username NN@dbname (where N's are int) local accounts and then leave everything else alone. The only issue I could see with something like this would be that someone trying to use this hack wont be able to give their users names like pudgy@dbname, but who cares? I mean if you are giving access to a bunch of developers, how is it going to affect them if you tell them to login with 123456@yourdb instead of jsmith@yourdb? If they cant remember it or something maybe they can write it down? I dunno... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
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]
