=?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 th
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 neede
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 on
> -Original Message-
> From: Lamar Owen [mailto:[EMAIL PROTECTED]]
> Sent: Monday, August 26, 2002 11:41 AM
> To: Dann Corbit; Bruce Momjian; Tom Lane
> Cc: Sir Mordred The Traitor; [EMAIL PROTECTED]
> Subject: Re: [HACKERS] @(#)Mordred Labs advisory 0x0007:
> Rem
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
>
[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
> -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
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'
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
Tom Lane wrote:
> 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. pall
-*- Sir Mordred The Traitor <[EMAIL PROTECTED]> [ 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 own
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 c
>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
-*- 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
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
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
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 robu
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
//@(#) 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 pr
19 matches
Mail list logo
