Re: char 0x00

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Brett Okken <brett(dot)okken(dot)os(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: char 0x00
Date: 2020-03-28 15:33:01
Message-ID: CADK3HHLT4mAq_09asP1r0E66+3cf8q-+V2X27Le0NPmWbC-hrg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

We don't have to make it consumable. If we can use his code and reproduce
it in the JDBC driver that is enough.

Dave Cramer

On Sat, 28 Mar 2020 at 11:31, Brett Okken <brett(dot)okken(dot)os(at)gmail(dot)com> wrote:

> Dave, any thoughts on best way to reproduce Vladimir’s described workflow
> in a way that is consumable by the postgresql team?
>
> On Thu, Mar 26, 2020 at 10:21 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> Brett Okken <brett(dot)okken(dot)os(at)gmail(dot)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
>>
>

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Jürgen Purtz 2020-03-29 09:29:50 Re: Add A Glossary
Previous Message Brett Okken 2020-03-28 15:30:51 Re: char 0x00