Thread: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

@(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Sir Mordred The Traitor
Date:
//@(#) Mordred Labs advisory 0x0007

Release data: 26/08/02
Name: Remote DoS condition in PostgreSQL
Versions affected: all versions
Conditions: entry in a pg_hba.conf file that matches attacker's host.
Risk: average

---[ Description:

Upon connecting to a database, postmaster will fork a new process. 
After that, a child process will call a
src/backend/postmaster/postmaster.c:DoBackend() routine, 
which after processing a startup packet (see src/include/libpq/pqcomm.h), 
will invoke a src/backend/libpq/auth.c:ClientAuthentication() routine to
perform client authentication.
If there is an entry in pg_hba.conf file, that matches an attacker's host, 
an attacker could trigger
invocation of src/backend/libpq/auth.c:recv_and_check_password0(), which
fails to detect a DoS condition.

---[ Details:
Consider this snip of code from src/backend/libpq/auth.c:

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

Note, that the size of palloced memory is taken from the user's input,
which is stupid if you ask me.

--[ How to reproduce:

I dont want to provide any tools to illustrate this vulnerability.

--[ Solution

Disable network access for untrusted users.




________________________________________________________________________
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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
"Shridhar Daithankar"
Date:
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((len>LENMAX?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..


ByeShridhar

--
Wilcox's Law:    A pat on the back is only a few centimeters from a kick in the 
pants.



Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Tom Lane
Date:
Sir Mordred The Traitor <mordred@s-mail.com> 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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Lamar Owen
Date:
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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Sir Mordred The Traitor
Date:
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 <mordred@s-mail.com> 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 majordomo@postgresql.org)
>
>


________________________________________________________________________
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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Þórhallur Hálfdánarson
Date:
-*- Lamar Owen <lamar.owen@wgcr.org> [ 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
connectionsfrom that specific webserver (TCP port 5432 access not blocked as well as an pg_hba.conf entry).  Now, if a
userwith access to the webserver has privileges to open a socket connection, he could exploit this.
 


-- 
Regards,
Tolli
tolli@tol.li


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Sir Mordred The Traitor
Date:
>Hey, if I can connect to postmaster I can DoS it quite easily, but
flooding it
>with connection requests.....

Hm, that's true of course, but now i will do this with a couple of
connections.
Lets say, bot on a owned machine, connects to a database, 
send a crafted packet,
postgresql will allocate a huge amount of memory, and will be 
happy to read anything it recvs from my bot.



________________________________________________________________________
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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Chris Humphries
Date:
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
backto 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.conffile that matches attacker's host.> > Risk: average> > > --[ Solution> >> > Disable network access for
untrustedusers.> > TCP/IP access must be enabled as well.  TCP/IP accessibility is OFF by > default.> > I for one
thoughtthat 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> >
---------------------------(endof broadcast)---------------------------> TIP 3: if posting/reading through Usenet,
pleasesend an appropriate> subscribe-nomail command to majordomo@postgresql.org so that your> message can get through
tothe mailing list cleanly
 

-- 
Chris Humphries
Development InfoStructure
540.366.9809 


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Þórhallur Hálfdánarson
Date:
-*- Sir Mordred The Traitor <mordred@s-mail.com> [ 2002-08-26 15:32 ]:
> >Hey, if I can connect to postmaster I can DoS it quite easily, but
> flooding it
> >with connection requests.....
> 
> Hm, that's true of course, but now i will do this with a couple of
> connections.
> Lets say, bot on a owned machine, connects to a database, 
> send a crafted packet,
> postgresql will allocate a huge amount of memory, and will be 
> happy to read anything it recvs from my bot.

Speaking of which.

If I understand correctly, a new backend is forked and the connection dispatched to that specific backend, once access
hasbeen granted (with means of user/pass authentication, ident or whatever).
 

Is there any check for connection to the postmaster that have not been dispatched to a new backend after X bytes (or
seconds?),to free resources (would that make any sense? :)
 

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/authorizationprocess 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? :)
 


-- 
Regards,
Tolli
tolli@tol.li


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Bruce Momjian
Date:
Tom Lane wrote:
> Sir Mordred The Traitor <mordred@s-mail.com> 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...

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.

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.

There are a whole host of vulnerability scenarios that we have not
explored.  In fact, with 7.2.2, we got into the data-based crash vs.
query-based crash issue that we have not discussed before in detail. 

With this report, we have a non-authorized user causing possible memory
exhaustion for all applications on the server.  This is a greater
vulnerability than the random query argument because in such cases the
user is authorized to issue queries.

So, Sir-* and others, please understand that databases have their own
vulnerability envelope that is much more complex than a standard network
application like ftp.  There is almost an entirely new vocabulary for
describing such vulnerabilities which we have been crafting as we
discuss it.  This vocabulary includes:
connection-enabled hosts vs. any hostauthenticated vs. non-authenticated usersusers with data insertion accessusers
withquery access
 

I think the last group can not be protected from malevolent queries, but
the former can be tightened, and Sir-* is working on that.  Sir-*, when
describing vulnerabilities, especially in public forums, please try to
use this language so people are not overly agitated by your warnings.

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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Lamar Owen
Date:
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.  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.

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.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Bruce Momjian
Date:
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 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,
Pennsylvania19073
 


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: Lamar Owen [mailto:lamar.owen@wgcr.org]
> Sent: Monday, August 26, 2002 10:50 AM
> To: Bruce Momjian; Tom Lane
> Cc: Sir Mordred The Traitor; pgsql-hackers@postgresql.org
> 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.


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
ngpg@grymmjack.com
Date:
pgman@candle.pha.pa.us (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...


How To Make Things Appear More Dramatic

From
cbbrowne@cbbrowne.com
Date:
> 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.

Obviously people have forgotten past history.  The Symbolics guys had
_great_ techniques for this that were well documented:

It is considered artful to append many messages on a subject, leaving
only the most inflammatory lines from each, and reply to all in one
swift blow.  The choice of lines to support your argument can make or
break your case.
-- from the Symbolics Guidelines for Sending Mail
%
State opinions in the syntax of fact: "...as well as the bug in LMFS
where you have to expunge directories to get rid of files....."
-- from the Symbolics Guidelines for Sending Mail
%
People can be set wondering by loading obscure personal patchable
systems, and sending bug reports.  Who would not stop and wonder upon
seeing "Experimental TD80-TAPE 1.17, MegaDeath 2.5..."?  The same for
provocatively-named functions and variables in stack traces.
-- from the Symbolics Guidelines for Sending Mail
%
Know the list of "large, chronic problems".  If there is any problem
with the window system, blame it on the activity system.  Any lack of
user functionality should be attributed to the lack of a command
processor.  A suprisingly large number of people will believe that you
have thought in depth about the issue to which you are alluding when you
do.
-- from the Symbolics Guidelines for Sending Mail
%
Know how to blow any problem up into insolubility.  Know how to use the
phrase "The new ~A system" to insult its argument, e.g., "I guess this
destructuring LET thing is fixed in the new Lisp system", or better yet,
PROLOG.
-- from the Symbolics Guidelines for Sending Mail
%
Never hit someone head on, always sideswipe.  Never say, "Foo's last
patch was brain-damaged", but rather, "While fixing the miscellaneous
bugs in 243.xyz [foo's patch], I found...."
-- from the Symbolics Guidelines for Sending Mail
%
Idiosyncratic indentations, double-spacing, capitalization, etc., while
stamps of individuality, leave one an easy target for parody.
-- from the Symbolics Guidelines for Sending Mail
%
Strong language gets results.  "The  reloader is completely broken  in
242" will open  a lot more eyes than  "The reloader doesn't load files
with intermixed spaces, asterisks,  and <'s in   their names that  are
bigger than 64K".  You can always say the latter in a later paragraph.
-- from the Symbolics Guidelines for Sending Mail
%
Including a destination in the CC list that will cause the recipients'
mailer to blow out is a good way to stifle dissent.
-- from the Symbolics Guidelines for Sending Mail
%
When  replying, it  is  often possible  to cleverly edit  the original
message in such a way  as to subtly alter  its meaning or tone to your
advantage while  appearing that you are  taking pains  to preserve the
author's intent.   As a   bonus,   it will   seem that your   superior
intellect is cutting through all the excess verbiage to the very heart
of the matter.  -- from the Symbolics Guidelines for Sending Mail
%
Referring to undocumented  private communications allows one to  claim
virtually anything: "we discussed this idea in  our working group last
year, and concluded that it was totally brain-damaged".
-- from the Symbolics Guidelines for Sending Mail
%
Points  are awarded for   getting   the last   word in.   Drawing  the
conversation out so long  that the original  message disappears due to
being indented off the right hand edge of the screen is  one way to do
this.  Another is to imply that  anyone replying further is a hopeless
cretin and is wasting everyone's valuable time.
-- from the Symbolics Guidelines for Sending Mail
%
Keeping a secret "Hall Of Flame" file  of people's mail indiscretions,
or copying messages to  private mailing lists for subsequent derision,
is good  fun  and also  a worthwhile  investment  in case  you need to
blackmail  the senders later.   -- from  the Symbolics Guidelines  for
Sending Mail
%
Users should cultivate an ability to make the simplest molehill into a
mountain   by   finding   controversial interpretations   of innocuous
sounding statements that the sender never intended or imagined.
-- from the Symbolics Guidelines for Sending Mail
%
Obversely, a lot of  verbal mileage can  also be gotten by sending out
incomprehensible, cryptic,  confusing or unintelligible  messages, and
then iteratively  "correcting"  the "mistaken  interpretations" in the
replys.  -- from the Symbolics Guidelines for Sending Mail
%
Trivialize   a user's bug report  by  pointing out that   it was fixed
independently long ago in a system that hasn't been released yet.
-- from the Symbolics Guidelines for Sending Mail
%
Send  messages calling for fonts  not  available to the  recipient(s).
This can (in the case of Zmail) totally disable the user's machine and
mail system for up to a whole day in some circumstances.
-- from the Symbolics Guidelines for Sending Mail
--
(concatenate 'string "aa454" "@freenet.carleton.ca")
http://cbbrowne.com/info/emacs.html
Frisbeetarianism: The belief that when  you die, your  soul goes up on
the roof and gets stuck...




Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Lamar Owen
Date:
On Monday 26 August 2002 02:23 pm, Dann Corbit wrote:
> 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.

The historical style on this list has avoided histrionics -- although I have 
myself been guilty of the hyperbole problem.  Making a big stink in no wise 
guarantees it being heard, and may very well cause some to bristle, as Tom 
has done.  It just doesn't fit the style of this list, that's all.

> As long as the needed data is included (here is how to reproduce the
> problem...) I don't see any problem.

When you have to read and process nearly 1,000 e-mails a day (as I have had to 
do, although my average is a mere 400 or so per day), the subject line and 
the first screenful of the message will be looked at, and no more.  The 
substance needs to be early in the message, and the subject needs to be short 
and descriptive.  These are just simply traditions, protocols, and ettiquette 
for Internet mailing lists, as well as other fora such as Usenet.

If someone wants me to pay attention to a message, the subject needs to be on 
the point, and the point needs to be early in the message.  Otherwise I may 
simply be so rushed when it arrives in my mailboxen (more than one, as I have 
autorouting mail filters in place) that it gets ignored.  I know I am not 
alone in processing mail this way.

> > And dealing with a real name would be nice, IMHO.  Otherwise
> > we may end up

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

I'm sorry, but I have more respect for someone who isn't afraid to use their 
real name.  I've been on both sides of that fence.  Even in the security 
business, where people routinely use pseudonyms, I personally prefer to know 
their real name.  If I _know_ Aleph One is Elias Levy, then that's easy 
enough.  If the information is easily available, then that's enough.  

So, it makes a difference to me, like it, lump it, or think it's insane.

And, yes, I agree he IS providing a valuable service -- with that I have no 
complaints.  But there is a distinct civility and culture to this list, and 
I'd like to see it stay that way.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
"Dann Corbit"
Date:
> -----Original Message-----
> From: Lamar Owen [mailto:lamar.owen@wgcr.org]
> Sent: Monday, August 26, 2002 11:41 AM
> To: Dann Corbit; Bruce Momjian; Tom Lane
> Cc: Sir Mordred The Traitor; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007:
> Remove DoS in PostgreSQL
[snip]
> And, yes, I agree he IS providing a valuable service -- with
> that I have no
> complaints.  But there is a distinct civility and culture to
> this list, and
> I'd like to see it stay that way.

I want to make it clear that I think the best way to report a problem is
with formal, rigorous, complete structure.  That structure should be
known to the receiving body.  If there is a procedure or standard form
for producing the needed information, it is better to follow the
standard procedure.

On the other hand (and the point I had hoped to make) some people like
to take lined paper and write on it sideways [Bradbury's "Fahrenheight
451" quote].  Instead of complaining that they are writing sideways on
the page, extract the information of value.  If the can be convinced to
"stop writing in a perpendicular manner" so that the majority will be
more comfortable with it, so much the better.  But standardized or not,
it can still contain information of great value.


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Bruce Momjian
Date:
Lamar Owen wrote:
> And, yes, I agree he IS providing a valuable service -- with that I have no 
> complaints.  But there is a distinct civility and culture to this list, and 
> I'd like to see it stay that way.

Well, when someone is a "Sir", we do give them a little more latitude. 

(Oh, hold one, that isn't his real name.  I see now.)  ;-)

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


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Lamar Owen
Date:
On Monday 26 August 2002 02:51 pm, Dann Corbit wrote:
> I want to make it clear that I think the best way to report a problem is
> with formal, rigorous, complete structure.  That structure should be
> known to the receiving body.  If there is a procedure or standard form
> for producing the needed information, it is better to follow the
> standard procedure.

Ok, let's do that then.  SOP is to use the bug reporting form contained on the 
website, which posts a bug report to pgsql-bugs@postgresql.org, which is the 
canonical bugreport list.  That is if we want to get that formal.

> But standardized or not,
> it can still contain information of great value.

Yes, it can.  I can use steganography to issue an RPM release announcement, 
too.  But will it be effective? :-)

If it isn't read, it won't be acted upon.  His announcements have been a 
difficult read, that's all. The substance is OK; the presentation is lacking, 
IMHO.
-- 
Lamar Owen
WGCR Internet Radio
1 Peter 4:11


Re: @(#)Mordred Labs advisory 0x0007: Remove DoS in PostgreSQL

From
Tom Lane
Date:
Þórhallur Hálfdánarson <tolli@tol.li> 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