Re: Cryptic error message in low-memory conditions

On Sat, Aug 27, 2011 at 3:30 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Daniel Farina <daniel(at)heroku(dot)com> writes:
>> On Sat, Aug 27, 2011 at 1:51 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> A more long-range point about it is that the next time we make a
>>> protocol version bump that affects the format of error messages,
>>> the problem comes right back.  It'd be better if the message somehow
>>> indicated that the server hadn't made any attempt to match the client
>>> protocol version.  I guess if we went up to 3.0 protocol, we could
>>> include a SQLSTATE value in the message and libpq could test that before
>>> making assumptions.
>
>> Hmm.  What do you think about the way ssh handles support and
>> negotiation of cipher methods between client and server: in that case,
>> I believe both client and server advertise what ciphers they are
>> willing to accept.
>
> The difficulty here is that, having failed to fork off a subprocess from
> the postmaster, we really can't do much of anything beyond blasting out
> a predetermined failure message.  We can *not* have the postmaster wait
> to see what protocol the client asked for, or we risk denial-of-service
> problems from malfunctioning or malicious clients.  So there's basically
> no solution to be found by altering what it is that the client sends.

Hmm. Well, for this requirement I don't think it's necessary to have
the postmaster wait, luckily: the missing information on the client
side is "what protocols does this postmaster support", and it's
sniffing that out of the format a received message. Instead, the
postmaster could send something as simple as a quite small static
string burned in at compile-time that advertises to the receiving
libpq what is supported, that way it doesn't have to guess. Other
than a tiny amount of outbound traffic per bogus connection attempt
(which I think is spent anyway to say "authentication denied" or in
some cases "out of memory" for example) I think this avoids a problem
with malicious clients.

Such a versions-supported string probably has a smaller complexity
that is vulnerable to change vs. the error protocol, and is explicit:
libpq guessworking the supported messages on the server based on
traffic sniffing seems pretty tortured.

SSL might throw a small wrench into everything, though: does one want
to send the supported protocol information when the channel is
susceptible to MITM attacks, and *then* move to a secure channel?
This seems like a pretty slim vulnerability (the ability for an
attacker to poke at the protocol versions supported string, which
presumably would give them all sorts of other nasty power already) as
long as all other communications are SSLified. One could probably get
around this by sending the version information twice, once before and
once after SSL negotiation so the client has an opportunity to spot
icky things going on.

(Embellishment: if one has policy in pg_hba.conf as to what protocols
are supported it may need to be a dynamic string influenced by the
conf on startup or whatever, but I think this is a comparatively small
detail.)
--
fdr