Re: fix for palloc() of user-supplied length - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: fix for palloc() of user-supplied length
Date
Msg-id 200208292145.g7TLjvc23934@candle.pha.pa.us
Whole thread Raw
In response to Re: fix for palloc() of user-supplied length  (Neil Conway <neilc@samurai.com>)
Responses Re: fix for palloc() of user-supplied length
List pgsql-patches
I have applied the following modified version of your patch.  The
original version would not apply to CVS.

---------------------------------------------------------------------------

Neil Conway wrote:
> Serguei Mokhov <mokhov@cs.concordia.ca> writes:
> > +     if (len < 1 || len > 8192)
> > +     {
> > +         elog(LOG, "Password packet length too long: %d", len);
> >                                                   ^^^^^^^^
> > Shouldn't it be changed to 'too long || too long' then? ;)
>
> Woops, sorry for being careless. Changed the wording to refer to
> 'invalid' rather than 'too long' or 'too short'.
>
> > And also for the message to be more descriptive for the innocent, I'd included
> > the current boundaries in it (like: "expected: 1 <= len <= 8192")
>
> Also fixed, although I'm not sure it's worth worrying about.
>
> > (a question: isn't hardcoding an evil?)
>
> Yes, probably -- as the comment notes, it is just an arbitrary
> limitation. But given that (a) it is extremely unlikely to ever be
> encountered in a real-life situation (b) the limits it imposes are
> very lax (c) it is temporary code that will be ripped out shortly, I'm
> not too concerned...
>
> Thanks for taking a look at the code, BTW.
>
> Cheers,
>
> Neil
>
> --
> Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

[ Attachment, skipping... ]

>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org

--
  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, Pennsylvania 19073
Index: src/backend/libpq/auth.c
===================================================================
RCS file: /cvsroot/pgsql-server/src/backend/libpq/auth.c,v
retrieving revision 1.86
diff -c -c -r1.86 auth.c
*** src/backend/libpq/auth.c    29 Aug 2002 03:22:01 -0000    1.86
--- src/backend/libpq/auth.c    29 Aug 2002 21:40:40 -0000
***************
*** 709,714 ****
--- 709,727 ----
      if (pq_eof() == EOF || pq_getint(&len, 4) == EOF)
          return STATUS_EOF;        /* client didn't want to send password */

+     /*
+      * Since the remote client has not yet been authenticated, we need
+      * to be careful when using the data they send us. The 8K limit is
+      * arbitrary, and somewhat bogus: the intent is to ensure we don't
+      * allocate an enormous chunk of memory.
+      */
+     if (len < 1 || len > 8192)
+     {
+         elog(LOG, "Invalid password packet length: %d; "
+              "must satisfy 1 <= length <= 8192", len);
+         return STATUS_EOF;
+     }
+
      initStringInfo(&buf);
      if (pq_getstr(&buf) == EOF) /* receive password */
      {

pgsql-patches by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] worried about PGPASSWORD drop
Next
From: "Nigel J. Andrews"
Date:
Subject: Re: [GENERAL] worried about PGPASSWORD drop