Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
=?iso-8859-1?Q?=DE=F3rhallur_H=E1lfd=E1narson?= [EMAIL PROTECTED] writes: And another (perhaps silly) thought: Currently, if the authentication process is exploited, it would kill the postmaster, resulting in a total crash of the whole database system. Would it be beneficial to split the connection handling/authorization process to a seperate process, and if that process dies, the postmaster would simply start a new one, there for not affecting any other backends that are running (for authorized users) ? Or am I way of track? :) No, just behind the times ;-). We did that in 7.2. regards, tom lane ---(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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
On 26 Aug 2002 at 14:46, Sir Mordred The Traitor wrote:
[snip]
static int recv_and_check_password0(Port *port) {
int32 len;
char *buf;
if (pq_getint(len, 4) == EOF)
return STATUS_EOF;
len -= 4;
buf = palloc(len); /* len is taken from a packet */
[snip]
So that should read,
buf=palloc((lenLENMAX?SAFELEN:len));
is what you want to say?
sounds good to me.. But if it is taken from the packet, won't that be tripped
to MTA size? Just a naïve question. Never saw much of postgres code myself..
Bye
Shridhar
--
Wilcox's Law: A pat on the back is only a few centimeters from a kick in the
pants.
---(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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Sir Mordred The Traitor [EMAIL PROTECTED] writes: Note, that the size of palloced memory is taken from the user's input, which is stupid if you ask me. Beyond causing an out of memory error during the handshake, I fail to see how there can be any problem. palloc is considerably more robust than malloc. I dont want to provide any tools to illustrate this vulnerability. Perhaps you haven't tried. It may indeed make sense to put a range check here, but I'm getting tired of hearing the words dos attack applied to conditions that cannot be exploited to cause any real problem. All you are accomplishing is to spread FUD among people who aren't sufficiently familiar with the code to evaluate the seriousness of problems... regards, tom lane ---(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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote: Conditions: entry in a pg_hba.conf file that matches attacker's host. Risk: average --[ Solution Disable network access for untrusted users. TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by default. I for one thought that it was normal operating procedure to only allow access to trusted machines; maybe I'm odd in that regard. Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it with connection requests. But, if we can thwart this, all the better. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
The point is really simple. Allocate a huge chunk of memory (no sense to cause out of memory error, as palloc will bail is a requested size 1 gb). The postgres will be ready to suck your input, via pg_getbytes(), now in a loop send junk to postgresql. Of course you can fork a number of processes to improve your effect. The issues is that postgres allocate a chunk of memory and reads data, using an user's input, which has not completed authentication. This is badly anyway. Of course i tried, and wrote proggy for that, but i can repeat, i dont want to provide it here. Sir Mordred The Traitor [EMAIL PROTECTED] writes: Note, that the size of palloced memory is taken from the user's input, which is stupid if you ask me. Beyond causing an out of memory error during the handshake, I fail to see how there can be any problem. palloc is considerably more robust than malloc. I dont want to provide any tools to illustrate this vulnerability. Perhaps you haven't tried. It may indeed make sense to put a range check here, but I'm getting tired of hearing the words dos attack applied to conditions that cannot be exploited to cause any real problem. All you are accomplishing is to spread FUD among people who aren't sufficiently familiar with the code to evaluate the seriousness of problems... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED]) This letter has been delivered unencrypted. We'd like to remind you that the full protection of e-mail correspondence is provided by S-mail encryption mechanisms if only both, Sender and Recipient use S-mail. Register at S-mail.com: http://www.s-mail.com/inf/en ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
-*- Lamar Owen [EMAIL PROTECTED] [ 2002-08-26 15:19 ]: TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by default. I for one thought that it was normal operating procedure to only allow access to trusted machines; maybe I'm odd in that regard. Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it with connection requests. But, if we can thwart this, all the better. Well, ISP's that offer webhosting and database connectivity might also be running a PostgreSQL server that only allows connections from that specific webserver (TCP port 5432 access not blocked as well as an pg_hba.conf entry). Now, if a user with access to the webserver has privileges to open a socket connection, he could exploit this. -- Regards, Tolli [EMAIL PROTECTED] ---(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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
so basically if you are an idiot admin, and leave the postgresql box open (explicitly opening stuff), and under certian conditions, you can get DoS'd? hrm, this may not be your biggest problem. maybe if the dba has a clue and only explicitly allows certian ips to even route to the box, and then certian users (1 or 2 or so) that is not available to the public (ie, internet), they would be better off. i would be that with the lazy/ignorant setup of the dba/admin, that a DoS of postgresql is not the biggest problem, sure one of their redhat boxes has gotten rooted already... there is nothing that is more important for security and databases than setting them up correctly, and their place on the network. the database is the crown jewel that should never been seen or touched except for when _absolutely_ needed, and that must be under heavy control. there is a bigger problem here than postgresql, it is the dumbass factor of people that try to run a db, and are vuln to anything... and then complain about it... i find this very annoying. know what you are doing, or stfu is my opinion -chris ps - note this was not directed at any one person, but to the mass of people that never should run a db, and go back to eating paint chips. - disclaimer: i do not speak on behalf of devis (devis.com). i speak on my own behalf. - /rant-mode Lamar Owen writes: On Monday 26 August 2002 10:46 am, Sir Mordred The Traitor wrote: Conditions: entry in a pg_hba.conf file that matches attacker's host. Risk: average --[ Solution Disable network access for untrusted users. TCP/IP access must be enabled as well. TCP/IP accessibility is OFF by default. I for one thought that it was normal operating procedure to only allow access to trusted machines; maybe I'm odd in that regard. Hey, if I can connect to postmaster I can DoS it quite easily, but flooding it with connection requests. But, if we can thwart this, all the better. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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 -- Chris Humphries Development InfoStructure 540.366.9809 ---(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] @(#)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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
Lamar Owen wrote: And dealing with a real name would be nice, IMHO. Otherwise we may end up with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) Reminds me of 'Uncle George' who did quite a bit for the Alpha port and then disappeared. Funny you mention that. Now knowing someone's name is troubling, but I am not sure why. -- 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 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] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL
-Original Message- From: Lamar Owen [mailto:[EMAIL PROTECTED]] Sent: Monday, August 26, 2002 10:50 AM To: Bruce Momjian; Tom Lane Cc: Sir Mordred The Traitor; [EMAIL PROTECTED] Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL On Monday 26 August 2002 12:59 pm, Bruce Momjian wrote: Tom Lane wrote: It may indeed make sense to put a range check here, but I'm getting tired of hearing the words dos attack applied to conditions that cannot be exploited to cause any real problem. All you are accomplishing is to spread FUD among people who aren't sufficiently familiar with the code to evaluate the seriousness of problems... It isn't fun to have our code nit-picked apart, and Sir-* is over-hyping the vulnerability, but it is a valid concern. The length should probably be clipped to a reasonable length and a comment put in the code describing why. The pseudo-security-alert format used isn't terribly palatable here, IMHO. On BugTraq it might fly -- but not here. An alarmist style when posting a serious error is a good idea. Hey guys, I found a possible problem... Does not seem to generate the needed level of excitement. DOS attacks means that business stops. I think that should generate a furrowed brow, to say the least. A simple 'Hey guys, I found a possible problem when.' without the big-sounding fluff would sit better with me, at least. The substance of the message is perhaps valuable -- but the wrapper distracts from the substance. As long as the needed data is included (here is how to reproduce the problem...) I don't see any problem. And dealing with a real name would be nice, IMHO. Otherwise we may end up with 'SMtT' as the nickname -- Hmmm, 'SMitTy' perhaps? :-) Reminds me of 'Uncle George' who did quite a bit for the Alpha port and then disappeared. If he wants to call himself 'Sir Modred' or 'Donald Duck' or 'Jack the Ripper' or whatever, I don't see how it matters. He is providing a valuable service by location of serious problems. These are the sort of thing that must be addressed. This is the *EXACT* sort of information that is needed to make PostgreSQL become as robust as Oracle, SQL*Server, DB/2, etc. Every free database engine project should be so lucky as to have a 'Sir Modred' IMO-YMMV. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
