From: Tom Lane <tgl@sss.pgh.pa.us>
To: Brett Okken <brett.okken.os@gmail.com>
Cc: pgsql-docs@lists.postgresql.org, Dave Cramer <davecramer@gmail.com>
Subject: Re: char 0x00
Date: Thu, 26 Mar 2020 11:21:52 -0400
Message-ID: <14011.1585236112@sss.pgh.pa.us> (raw)
In-Reply-To: <CANBJVOH+SL8d7D4buSOv9=H18KLCQf2r1GC7bfUnwC4NGgF6_Q@mail.gmail.com>
References: <CANBJVOH31rJxU=6wYULRyRVg6QfbgWRrFPrxUw1Ss20CR+rcBQ@mail.gmail.com>
<11841.1585232526@sss.pgh.pa.us>
<CANBJVOH+SL8d7D4buSOv9=H18KLCQf2r1GC7bfUnwC4NGgF6_Q@mail.gmail.com>
Brett Okken <brett.okken.os@gmail.com> writes:
> Using a client and server encoding of SQL_ASCII makes it possible to get
> 0x00 into a text value column when using a bind variable.
Having looked at the code again, I flat out don't believe you.
textin is certainly not going to read past a nul character,
and textrecv goes through pg_client_to_server (via pq_getmsgtext),
which AFAICS is careful in all code paths to reject nuls.
If I'm missing something, I'd really like to see a concrete example,
because this would be a bug, and it'd suggest that somebody's managed
to reopen CVE-2006-2313. If we're missing nul rejection in some code
path, then we're probably not doing encoding validation at all.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: tgl@sss.pgh.pa.us, brett.okken.os@gmail.com, davecramer@gmail.com
Subject: Re: char 0x00
In-Reply-To: <14011.1585236112@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox